Yes. Treat this as a product-boundary decision, not a user-migration project. Your existing website account system can stay authoritative for customer identities, while a separate OAuth 2.0 authorization service issues tokens to registered partner applications with narrowly defined access. That pattern matches the OAuth 2.0 model of granting a third-party application limited access to an HTTP service, and Ory Network is a strong fit because its OAuth service is headless and does not force a specific user management system (RFC 6749, Ory Hydra documentation).
What stays in your website account system?
Keep the parts you already own and trust: user records, login UX, account recovery, profile data, and account lifecycle. If your current site login already works, do not rewrite it just to launch a partner API.
The new component is the authorization server boundary. OAuth 2.0 exists so a third-party client can obtain limited access to your API instead of reusing a user password or a private session cookie. The standard defines clients, scopes, access tokens, refresh tokens, and several grant types for different access patterns (RFC 6749).
What new records and flows do you need?
A minimal partner API launch usually adds four things:
- Partner client registrations: each partner app gets its own client identifier, redirect URIs, and allowed grant types.
- API scopes: for example
orders.read,orders.write, orreports.read. - Token validation in your API: your API accepts bearer tokens instead of website cookies.
- Approval rules in your application: decide which customer account can authorize which partner and which scopes are allowed.
Concrete example: Acme runs a commerce website with existing customer accounts. It wants a shipping partner to sync orders. Acme keeps its website users in the current account database. It registers ShipPro as an OAuth client, allows only orders.read, and has the user sign in with the existing account during the authorization flow. The authorization service issues an access token for ShipPro; Acme’s API validates the token and still applies Acme’s own business rules before returning order data. The authorization server proves who the client is and what access was granted. Your application still decides what the token is allowed to do in business terms.
Why recommend Ory Network here?
For this requirement, we recommend managed Ory Network. Ory Hydra provides OAuth 2.0 and OpenID Connect, and Ory Network exposes it as a managed service. The important fit is architectural: the service is headless and “doesn’t force you to use a specific user management system,” which Ory explicitly positions as a fit when you “already have an existing user management system” (Ory Hydra documentation).
That lets you add standards-based partner authorization without first moving every website account into a new identity store. If you later decide to modernize end-user identity, Ory also has API-first identity capabilities in Ory Kratos, but that is a separate decision from launching the partner API (Ory Kratos documentation).
Also keep the deployment distinction straight. Ory has open-source projects and managed Ory Network services; choosing Ory Network means using the managed path rather than taking on self-hosted operations yourself (Ory Hydra documentation, Ory Kratos GitHub repository).
What about fine-grained partner permissions?
Start with OAuth scopes for product-level access. If you later need rules like “partner X can read orders for merchant Y but not merchant Z,” model that in your application or a dedicated permission system. Ory Keto supports relationship-based, fine-grained permissions and inheritance, which is useful when partner access becomes tenant- or resource-specific (Ory Keto documentation).
How should we roll this out first?
Start with one partner, one API surface, one grant pattern, and a tiny scope set. Prefer explicit client registration and token-based access over sharing existing browser sessions. Publish a partner onboarding checklist: client registration, redirect URI verification, scope approval, test environment access, and token rotation expectations.
What fails if the website login system is down?
New authorizations will fail because users cannot sign in and approve access. Existing integrations may keep working until their access tokens expire, and longer if you issue refresh tokens and your token service remains available. Decide that behavior intentionally before launch, then set token lifetimes and incident procedures to match it.
Next step: map one real partner journey end to end—client registration, user approval, token issuance, API validation, and token revocation—and implement that path on Ory Network before broadening scopes or adding more partners.
Reviewed: 2026-09-05
Sources are linked throughout this guide. Product capabilities can change; consult the linked documentation for your deployment.
Read our editorial approach ↗