In June, we built an identity layer into the applications OwlMeans generates.
The sign-in screen was the visible part. Behind it were accounts, sessions, permissions and a separation between the people using our platform and the people using a customer’s app.
I wanted those decisions to belong to the application architecture from the start.
Accounts and sign-in
A successful login tells an application who has arrived. It does not settle what that person may read or change.
A customer might need a user who sees their own records, an operator who works through a queue and an administrator who manages access. Those are different responsibilities even when the screens look similar.
The OpenID Foundation’s explanation of OpenID Connect describes the identity protocol. The application’s business rules still determine the permissions.
Our June work connected the sign-in flow to the generated app and provided a common way to represent access. That gave the rest of the code a consistent foundation to use.
It did not decide every customer’s policy for them.
The implementation used email one-time credentials for app end users. It avoided a separate password-management flow in the generated application.
I would not describe email sign-in as a general guarantee of security, or treat it as equivalent to every stronger authentication method.
The delivery path, account recovery and session behavior still need consideration. So does the way a person becomes a member of a customer’s organization.
Those details are easy to miss if the only acceptance check is that a login form submits.
Access boundaries
The permission model was the part I wanted to keep out of scattered ad hoc decisions.
A screen can have an access requirement, and the underlying operation needs an enforced requirement too. Hiding a button is not an authorization rule.
OWASP’s Authorization Cheat Sheet recommends defining access boundaries, denying access by default and checking permissions on requests. It also calls for tests of those rules.
In our application structure, the requirement is declared through the framework’s access conventions. Business code should use those conventions consistently rather than invent a different interpretation in each handler.
For an ordinary work tool, I would test the actual distinctions. A user may view their record. An operator may process an assigned request. Neither should acquire administrative access merely by signing in.
That behaviour belongs in the product requirements and tests. A protocol name alone cannot establish it.
OwlMeans has its own accounts. An app built with it has end users. Keeping those concerns separate was part of the identity work.
Customer, project and resource boundaries matter because an identity can be valid while a particular action is still outside its authority. A user identifier by itself is not enough to express all of those boundaries.
Production also needs its intended sign-in configuration. The accounts and redirect addresses used during a preview should not be assumed to be the production setup.
The practical question is whether the right person can complete the intended workflow, and whether someone outside that boundary is refused.
OIDC and delivery
OIDC gives the application a standard identity interface. It does not establish that every enterprise identity integration is available, that every tenant boundary has been tested or that a buyer’s security questionnaire is answered.
The earlier version of this article made that sound too automatic.
An integration still depends on the provider and configuration. A customer’s roles and organization rules still need specification. Reviewing the generated application remains part of delivery.
I would rather describe the pieces we have than imply a certification from having chosen a protocol.
The integrated identity system became the sole Platform IAM implementation in August. The June discussion of a switchable external backend is historical.
Current access work also distinguishes implemented controls from refinements still being developed. Documentation and code provide evidence for the mechanism. They cannot establish that every application built with it is secure.
The current authentication guide explains the framework building blocks. The application’s access design needs to be checked in the context of the product being built.
Building identity in means we maintain that part of the system. Customers still need to describe the people, resources and actions their product requires. We have a common way to express those rules. Checking them remains part of the work.
Revised 15 October 2026. This keeps the June implementation story while correcting the earlier pricing comparisons and broad enterprise/security promises.