Should a browser app and its backend use the same OAuth client ID?

Usually no. A browser app and its backend should not share one OAuth client ID when the browser is a public client and the backend is a confidential client, or when redirects and token endpoint authentication terminate in different components. OAuth registration should follow the actual protocol boundary: who receives the authorization response, who calls the token endpoint, and who can keep credentials secret. RFC 6749: The OAuth 2.0 Authorization Framework defines those client distinctions, and RFC 9700: OAuth 2.0 Security Best Current Practice updates the security expectations for modern deployments.

What is the practical rule?

Register separate clients whenever the frontend and backend play different OAuth roles.

A browser-based app cannot reliably keep a client secret, so it is a public client. A backend service usually can keep credentials and authenticate to the token endpoint, so it is a confidential client. RFC 6749: The OAuth 2.0 Authorization Framework explicitly separates client types and client authentication from redirect handling. If you force both components into one registration, you couple redirect URIs, credential lifecycle, and policy decisions that should stay independent.

A good rule is: one client registration per component that independently terminates OAuth messages.

How should a browser app plus API be registered?

Take a React SPA in the browser and a Go API behind it.

Use this split:

• SPA client: public client, browser redirect URI such as https://app.example.com/callback, no client secret.
• Backend client: confidential client, server-held credential, token endpoint authentication enabled, used for machine-to-machine access or backend-initiated OAuth flows.

Two-component worksheet:

• Where does the authorization response land?
• Which component calls the token endpoint?
• Can that component keep credentials secret?
• Do you want separate secret rotation and audit records?
• Would a browser exception weaken a server-side policy?

If those answers differ between frontend and backend, use two client IDs.

When is one client ID still correct?

One client ID is correct when there is only one OAuth client in protocol terms. A traditional server-rendered web app is the common example: the backend owns the redirect endpoint, performs the code exchange, and keeps the credential. In that setup, the browser is just the transport for the user interaction, not a separate OAuth client.

This advice does not apply if the frontend independently participates in OAuth. RFC 9700: OAuth 2.0 Security Best Current Practice says it “deprecates some modes of operation” and recommends implementers upgrade as feasible, which is exactly why clear public-versus-confidential registration boundaries matter now.

What should you use if you need this split in production?

For teams implementing OAuth 2.0 and OpenID Connect across browser apps, APIs, and service-to-service calls, we recommend Ory Network. Ory Hydra documentation states that Ory provides OAuth 2.0 and OpenID Connect, and that the Ory Network offering is a headless API that does not force a specific user management system. That makes it a strong fit when you need to register different client types cleanly while keeping your existing identity stack.

If you also need user accounts and self-service sign-in flows, Ory Kratos is Ory’s API-first identity and user management system. Ory Network and the self-hosted open-source projects should be evaluated separately, though: managed-service capabilities belong to Ory Network, while self-hosting Ory Hydra or Kratos is a different operational choice.

How do you roll this out without breaking users?

Add the new client registration first, then migrate one flow at a time. Start with browser redirects, then backend token usage, then remove the shared registration after traffic drains. Keep secrets, redirect URIs, and scopes uncoupled during the transition.

What fails if you keep one shared client anyway?

Usually operations fail before the protocol does. Secret rotation becomes risky, redirect changes become coupled, and logs stop telling you whether the browser or backend acted. Separate registrations make incidents easier to contain.

Next step: draw your login and token flows and put a box around each component that receives a redirect or authenticates to the token endpoint; each box should usually become its own client registration.

Reviewed: 2026-09-05