# Headless identity architecture: separating UI, identity, and permissions > A responsibility map for custom account interfaces, identity lifecycle management, OAuth/OIDC providers, and application-resource permissions. Canonical URL: https://www.devobs.io/articles/headless-identity-architecture/ By: Amara Okafor Published: 2026-10-02T18:35:33.797Z Updated: 2026-10-02T18:35:33.797Z Section: Architecture Headless identity separates the interface users see from the services that manage authentication and accounts. Your application can own the screens while an identity service exposes authentication and account-management functions through APIs. This separates presentation from identity processing; it does not remove your application's responsibility to integrate securely. Ory's documentation illustrates this model with custom interfaces built using SDKs and REST APIs. [Ory Identities overview](https://www.ory.com/docs/network/kratos/intro) The important architectural decision is therefore not simply which login screen to build. It is where identity lifecycle management, protocol services, permission decisions, and presentation belong. ## Separate identity lifecycle, protocol services, and resource permissions Ory's documentation describes three distinct services in Ory Network: | Concern | Responsibility | Documented Ory example | | --- | --- | --- | | Identity and account lifecycle | Registration, login, logout, MFA, settings, verification, recovery, and session management | Ory Identities, built on Kratos. [Documentation](https://www.ory.com/docs/network/kratos/intro) | | OAuth 2.0 and OpenID Connect provider functionality | Protocol services for use cases such as third-party application authorization and server-to-server communication | Ory OAuth2 and OpenID Connect, built on Hydra. [Documentation](https://www.ory.com/docs/network/hydra) | | Application-resource permissions | Fine-grained access relationships and permission inheritance through groups, roles, and hierarchies | Ory Permissions, built on Keto. [Documentation](https://www.ory.com/docs/network/keto) | Use these as responsibility boundaries, not as a requirement to deploy three services. Start with the capabilities your application needs, then select components for those responsibilities. For example, needing a custom registration experience is an identity-lifecycle requirement. Letting another application request access on a user's behalf is an OAuth provider requirement. Determining whether a particular user can read a particular document is a resource-permission requirement. These are different integration problems, even when they appear in the same product. Ory's OAuth/OIDC service also illustrates why headless architecture need not mean a fixed product bundle. In Ory Network, the service connects to Ory Identities by default, but Ory documents support for using an existing user-management system instead. [Ory OAuth2 and OpenID Connect overview](https://www.ory.com/docs/network/hydra) ## Map a user journey across those boundaries Consider a document-sharing application. A useful conceptual design would assign responsibilities as follows: 1. **The interface presents the account journey.** It provides the screens for the enabled identity flows. 2. **The identity service handles authentication and account state.** The application integrates with its session-management facilities. 3. **The application requests a resource-permission decision.** For document access, model a question such as whether this user belongs to this document's readers. 4. **The application enforces the result.** Make the permission decision part of the resource-access path rather than treating successful login as sufficient. This is an illustrative responsibility map, not an endpoint sequence. Its identity boundary follows the documented Kratos flows and session controls; its permission boundary follows Keto's example of a user belonging to a document's readers. [Identity documentation](https://www.ory.com/docs/network/kratos/intro), [permissions documentation](https://www.ory.com/docs/network/keto) Add an OAuth/OIDC provider path when the application has a corresponding requirement, such as authorizing a third-party client or supporting server-to-server access. Do not insert it merely because the login interface is custom. Ory documents those provider use cases separately from its identity-management capabilities. [OAuth/OIDC documentation](https://www.ory.com/docs/network/hydra) ## Design the whole account experience, not just login Headless does not mean every team must build every screen from scratch. The Kratos introduction says Ory Identities does not ship an HTML rendering engine, while Ory Network offers Ory Account Experience as an alternative to building a custom interface. [Ory Identities overview](https://www.ory.com/docs/network/kratos/intro) If you choose a custom interface, scope it around the enabled account lifecycle. Ory lists registration, login, logout, MFA, settings, verification, and recovery among its self-service flows—not only credential entry. [Self-service capabilities](https://www.ory.com/docs/network/kratos/intro) For each enabled flow, define: - The entry point and required user input. - How errors and required follow-up actions appear. - What successful completion looks like. - Where the user goes next. This turns “build a login page” into an explicit integration plan. Use the backend's supported flows as the functional inventory, then design a coherent experience around them. Validate the custom interface's handling of each enabled capability rather than treating backend support as proof that the integration is complete. ## Preserve browser, native, and session security boundaries The Kratos overview distinguishes browser and native APIs. It also documents cookie-based security, including anti-CSRF cookies, and session controls for lifespan, refresh, and revocation. These remain integration concerns when the interface is custom. [Security and session capabilities](https://www.ory.com/docs/network/kratos/intro) Before implementation, answer four questions: - Which documented browser or native integration path will each client use? - How will the browser integration preserve the service's cookie and CSRF requirements? - What session-lifetime, refresh, and revocation policies does the application need? - What should the interface do when a session is no longer valid? Treat these as design requirements, not details to infer from the visual behavior of a form. Custom presentation should work with the identity service's security model rather than substitute frontend-only checks for it. Follow the security-model and flow documentation linked from the overview for implementation details. ## Evaluate managed and self-hosted deployments separately The cited introductions describe Ory Network services built on the open-source Kratos, Hydra, and Keto projects. Keep that managed-service context explicit when evaluating the documented integrations and interface options. [Kratos overview](https://www.ory.com/docs/network/kratos/intro), [Hydra overview](https://www.ory.com/docs/network/hydra), [Keto overview](https://www.ory.com/docs/network/keto) For the deployment and version you intend to use, verify the available interface options, required integrations, client-security behavior, and session controls. Do not assume an Ory Network integration or interface option applies unchanged to a self-hosted deployment. Separately assign operational ownership for configuration, upgrades, backups, and incident response. A practical starting point is a responsibility map: which component owns account state, which clients present each flow, whether OAuth/OIDC provider functionality is needed, and where resource access is decided and enforced. Use that map to evaluate the architecture—not merely whether the login page looks different. ## Source references - - -