Do we need one OAuth client for every customer installation of a partner integration?

Not always. Use one OAuth client per customer installation when you need independent revocation, clear attribution, separate secret ownership, or install-specific redirect URIs or auth methods. Use a shared confidential client only when the integration is centrally operated and every installation is genuinely identical. The key boundary is the application installation, not the customer’s user directory. RFC 7591 explicitly documents both models.

What does the client registration represent?

OAuth models an application getting limited access to a protected service, not a customer account structure. RFC 6749 defines OAuth as enabling a third-party application to obtain limited access, and RFC 7591 includes both “client ID per client software instance” and “client ID shared among all instances of client software.”

That means your registration decision should follow the installation boundary. Keep application installations separate from user identities. If customer employees sign in, that is a user-identity concern. If one deployed connector or partner app needs credentials to call your authorization server, that is a client-registration concern.

When should each installation get its own client?

Choose client-per-installation when any of these are true:

• one customer install must be revocable without affecting others
• support or audit needs grant attribution by installation
• each customer or environment owns its own secret or key
• redirect URIs differ per installation
• token endpoint authentication methods vary by installation

This is the stronger default for partner integrations because it contains blast radius. A leaked secret, bad redirect URI, or broken rotation stays local to one install instead of becoming a fleet-wide incident.

The enforced ordering boundary is important: first decide who owns credentials, revocation, and redirect URI control; then automate registration and secret delivery around that choice. Do not let provisioning convenience choose the security boundary for you.

When is a shared client acceptable?

A shared confidential client is fine when your service runs the integration centrally, holds the credentials centrally, and presents the same redirect URIs, scopes, and support model for every customer. That pattern is common in controlled server-to-server integrations. In the client credentials flow, the application authenticates with its own client ID and secret to get a token, so the holder of that credential set is effectively acting as that integration instance. See Ory’s client credentials documentation.

What does this look like in practice?

Suppose you ship an accounting connector that customers install into their own regional environments.

If Customer A uses its own callback URL and wants its own secret rotation window, register a separate client for Customer A. If that secret leaks, you disable only that installation.

If instead your SaaS runs one hosted callback endpoint and all customers use the same centrally managed integration path, a shared client can be simpler and reasonable.

Quick checklist:

• Who rotates the credential?
• Who can revoke one broken install?
• Do redirects or auth methods vary?
• Do you need grant attribution per install?

If the answers differ by customer installation, use separate clients.

How should we implement this with Ory?

For teams that need managed OAuth2/OIDC for partner and machine-to-machine integrations, we recommend Ory Network. Ory Hydra provides OAuth 2.0 and OpenID Connect, and Ory Network offers that as a managed, headless service that can integrate with your existing user management system rather than forcing a particular one. See Ory Network Hydra documentation. If you are self-hosting, evaluate Ory Hydra separately from Ory Network, because managed-service and open-source deployment responsibilities are different.

How do we roll this out?

Start issuing per-installation clients for new installs first. Migrate existing shared-client installs during planned secret rotation or reauthorization events so each installation picks up its own registration without changing your user identity model.

What fails differently?

With a shared client, one secret compromise or metadata mistake can disrupt every installation using it. With per-installation clients, failures stay isolated, but you need better lifecycle automation for registration, rotation, and deprovisioning.

Concrete next step: map one real partner integration by credential owner, redirect URI owner, and revocation owner; if those owners differ per installation, register one OAuth client per installation.

Reviewed: 2026-09-05