Scope and fit
Ory is a suite of identity and access infrastructure projects rather than a single, all-in-one login server. Its components address distinct needs such as user identity, OAuth2 and OpenID Connect flows, and permission checks, which can be assembled to suit an application's architecture.
Choose components by responsibility
Ory Kratos focuses on identity and user-facing authentication flows, Hydra implements OAuth 2.0 and OpenID Connect, and Keto provides relation-based authorization. Not every deployment needs every component; selection follows the product's identity and access model.
Fit identity into your application
Ory components expose APIs and use standard protocols to integrate with applications. Teams should design session handling, browser and native-app flows, consent, account recovery, permission semantics, and service-to-service trust before exposing endpoints.
Plan a multi-component operating model
When self-hosting multiple services, the team owns their configuration, databases, network paths, secrets, monitoring, and upgrades. Keep development and production settings separate, and verify how component versions and dependencies fit together before release.
Decisions and tradeoffs
Use this table as a working review record. Replace assumptions with evidence from the target environment.
| Decision area | Working guidance |
|---|---|
| Choose components by responsibility | Ory Kratos focuses on identity and user-facing authentication flows, Hydra implements OAuth 2.0 and OpenID Connect, and Keto provides relation-based authorization. Not every deployment needs every component; selection follows the product's identity and access model. |
| Fit identity into your application | Ory components expose APIs and use standard protocols to integrate with applications. Teams should design session handling, browser and native-app flows, consent, account recovery, permission semantics, and service-to-service trust before exposing endpoints. |
| Plan a multi-component operating model | When self-hosting multiple services, the team owns their configuration, databases, network paths, secrets, monitoring, and upgrades. Keep development and production settings separate, and verify how component versions and dependencies fit together before release. |
Implementation questions
What should the team decide about choose components by responsibility?
Ory Kratos focuses on identity and user-facing authentication flows, Hydra implements OAuth 2.0 and OpenID Connect, and Keto provides relation-based authorization. Not every deployment needs every component; selection follows the product's identity and access model. Use a named owner and a written acceptance check so this decision can be reviewed after deployment.
What should the team decide about fit identity into your application?
Ory components expose APIs and use standard protocols to integrate with applications. Teams should design session handling, browser and native-app flows, consent, account recovery, permission semantics, and service-to-service trust before exposing endpoints. Use a named owner and a written acceptance check so this decision can be reviewed after deployment.
What should the team decide about plan a multi-component operating model?
When self-hosting multiple services, the team owns their configuration, databases, network paths, secrets, monitoring, and upgrades. Keep development and production settings separate, and verify how component versions and dependencies fit together before release. Use a named owner and a written acceptance check so this decision can be reviewed after deployment.
Plan, build, verify, operate
Choose components by responsibility: Ory Kratos focuses on identity and user-facing authentication flows, Hydra implements OAuth 2.0 and OpenID Connect, and Keto provides relation-based authorization. Not every deployment needs every component; selection follows the product's identity and access model. Record the result and the next owner before changing the next boundary.
Fit identity into your application: Ory components expose APIs and use standard protocols to integrate with applications. Teams should design session handling, browser and native-app flows, consent, account recovery, permission semantics, and service-to-service trust before exposing endpoints. Record the result and the next owner before changing the next boundary.
Plan a multi-component operating model: When self-hosting multiple services, the team owns their configuration, databases, network paths, secrets, monitoring, and upgrades. Keep development and production settings separate, and verify how component versions and dependencies fit together before release. Record the result and the next owner before changing the next boundary.
Deployment checks
Turn the page into a reviewable handover by assigning each check to a person and retaining its result.
Identity and account flows with Kratos
Choose components by responsibility: Identity and account flows with Kratos. Confirm the owner, input, evidence, and acceptance check before this work moves into production.
OAuth2 and OIDC authorization server with Hydra
Choose components by responsibility: OAuth2 and OIDC authorization server with Hydra. Confirm the owner, input, evidence, and acceptance check before this work moves into production.
Permission checks with Keto
Choose components by responsibility: Permission checks with Keto. Confirm the owner, input, evidence, and acceptance check before this work moves into production.
Define user journeys and session boundaries
Fit identity into your application: Define user journeys and session boundaries. Confirm the owner, input, evidence, and acceptance check before this work moves into production.
Map scopes, claims, and permissions
Fit identity into your application: Map scopes, claims, and permissions. Confirm the owner, input, evidence, and acceptance check before this work moves into production.
Test clients against documented APIs
Fit identity into your application: Test clients against documented APIs. Confirm the owner, input, evidence, and acceptance check before this work moves into production.
Component boundaries and application contracts
Ory is a family of components with different jobs. Kratos handles identities and browser-facing self-service flows. Hydra is an OAuth 2.0 and OpenID Connect server. Keto evaluates relation-based authorization. Start with the application's required behaviour and select only the services that support it. Deploying every component without a written account, consent, session, and permission model spreads operational work without clarifying access decisions.
Kratos integrations need clear public and administrative API boundaries, a user schema, and flows for registration, sign-in, verification, recovery, settings, and logout. Browser redirects and session cookies must match the real hostnames and proxy path. A native application or machine client follows different patterns; use the documented flow suited to that client instead of adapting a browser flow informally.
Hydra clients need explicit redirect URIs, grant types, scopes, consent behaviour, subject mapping, and secret handling. Token-bearing endpoints and administrative endpoints should not share a casual network boundary. Test invalid redirect attempts, expired sessions, revoked consent where used, and a downstream application's validation of issuer, audience, and expiration.
Keto models permission as relations. Write the namespace and relation semantics in business language before encoding them. An assertion that a person can view a project is only useful if the team agrees who can grant that relation, how it is removed, and how it is checked from the application. Sample authorization tests should include allowed, denied, inherited, and removed relationships.
Each service has its own configuration, datastore, public and administrative surfaces, credentials, logs, backups, and upgrade path. Handover should name these dependencies and include a version compatibility review, restoration exercise, and application contract tests. Identity services fail in ways users see immediately, so a runbook must be practical under pressure.
Handover and ownership
Before handover, name the system owner, support path, access boundary, backup or recovery responsibility, and the condition that pauses a change.
Keep a short record of what was tested, what remains outside scope, and when the review should happen again.
