What should a platform team promise product teams when it adopts managed identity?

A platform team should promise a clear identity service contract, not a vague promise to “handle auth.” Product teams need to know which authentication and token flows are standardized, how configuration changes are approved, where incidents escalate, and which responsibilities stay in the application. For this model, we recommend Ory Network as the managed foundation for identity and OAuth2/OIDC, while keeping product-specific authorization decisions, customer entitlements, and business workflows in the product.

What should the platform team actually promise?

Promise five things.

First, a standard integration path. The platform team owns the shared login, registration, recovery, session, and token infrastructure. That fits Ory Network well because Ory Kratos documentation describes Ory Kratos Identities as an “API-first identity and user management system” with self-service flows and custom UI support, and Ory Hydra documentation documents OAuth 2.0 and OpenID Connect for apps and services.

Second, a stable configuration interface. Product teams should request changes through versioned configuration: client registrations, redirect URIs, identity traits, login methods, and token claim mappings. The platform team promises review, rollout, and rollback of shared identity configuration. Product teams promise not to bypass these controls in app code.

Third, a defined incident path. The platform team owns outages in shared sign-in, token issuance, and upstream identity configuration. Product teams own incidents caused by their app’s session handling, authorization checks, broken redirect logic, or misuse of claims. Reliability targets should be explicit and agreed across stakeholders; Google’s SRE workbook says SLOs are a target level for reliability and should be approved by stakeholders and used for decision-making.

Fourth, support boundaries. The platform team supports SDK guidance, reference integrations, runbooks, and escalation into the managed provider. Do not promise custom debugging of every application framework issue. Promise office hours, docs, and an escalation route instead.

Fifth, product-owned responsibilities. Product teams still own business policy: who may access which tenant, what premium features require, when an account is suspended in the domain model, and what the app shows when identity systems are degraded.

Where is the boundary with Ory Network?

Use Ory Network for managed identity foundations, not for application-specific business rules. Ory Network provides managed services based on Ory’s open-source projects, and those deployment choices must be evaluated separately. In this contract, the platform team is choosing the managed path for shared identity operations, while products continue to own application behavior.

That boundary is especially useful because Ory Hydra documentation says the service is “a headless API” and does not force a particular user management system. This lets the platform team standardize OAuth2/OIDC without dictating every product UI or domain workflow.

What does a concrete service contract look like?

Example: an internal SaaS platform onboarding a new product called Reports.

Records: identity schema, OAuth client, redirect URIs, allowed scopes, session settings, and support contacts.

Actors: platform identity team, Reports engineering team, security reviewer, incident commander.

Lifecycle:

1. Reports requests a new client and chooses web or native flow.
2. Platform creates the OAuth/OIDC client and shared login integration.
3. Reports implements callback handling and product authorization.
4. Security approves requested scopes and claim usage.
5. Production changes go through versioned config with rollback notes.
6. During an incident, platform handles sign-in or token failures; Reports handles feature degradation in-app.

A simple checklist for product teams:

• Which login flows are you using?
• Which identity traits do you need?
• Which claims does your app consume?
• What breaks if login is unavailable?
• Which authorization decisions remain in your service?

How should rollout and failure handling work?

Q: How should we roll this out to product teams?
Start with one paved-road integration: one web app pattern, one native app pattern, one claim contract, and one change process. Expand only after those paths are documented and supported.

Q: What should happen when identity is degraded?
Require every product to define a failure mode: block new sign-in, allow existing sessions for a limited period, or place risky admin actions behind re-authentication once service recovers. Put that choice in the onboarding checklist.

The next step is to publish a one-page identity consumer contract with the five promises above, then pilot it with one product team before declaring identity “platform-owned.”

Reviewed: 2026-09-05.