Google OAuth redirect URI strictness in multi-tenant apps

At a glance

What this is: Google OAuth requires exact redirect URI matching, and the article shows how that becomes an operational and security problem for multi-tenant apps with customer-specific domains.

Why it matters: IAM and identity architects need to treat redirect URIs as governed identity infrastructure, because mismanaged callback registration can break sign-in flows, complicate migrations, and widen OAuth attack exposure across NHI and human login paths.

By the numbers:

• 100.

👉 Read WorkOS's guide to strict Google OAuth redirect URI handling for multi-tenant apps

Context

Google OAuth redirect URI handling is a governance problem as much as a configuration problem. The provider requires exact character-for-character matching on the scheme, host, port, and path, which means teams cannot rely on wildcard assumptions when they support customer-owned domains or frequent tenant migrations.

For multi-tenant SaaS, redirect URIs become part of the identity lifecycle for every tenant. That makes the operational questions familiar to IAM teams: when is the new callback registered, how long does the old one remain valid, and how do you prevent sign-in interruption while the change is in flight?

The security trade-off is real. Exact matching narrows code-interception risk, but it also pushes complexity into provisioning, change control, and migration discipline. That is the point at which OAuth callback management stops being a developer convenience and becomes identity governance.

Key questions

Q: What breaks when Google OAuth redirect URIs are not registered exactly?

A: Login flows fail with redirect_uri_mismatch errors because Google requires the authorization request callback to match the registered value character for character. That includes scheme, host, port, and path. In multi-tenant environments, this usually shows up during customer onboarding or domain migration, when the callback has changed but the console registration has not caught up.

Q: Why do custom domains make OAuth callback governance harder?

A: Custom domains multiply the number of callback values that must be registered, tracked, and retired. Each tenant becomes a lifecycle item, not just a configuration entry. The more domains you support, the greater the risk of stale registrations, migration failures, and manual drift between your application topology and the approved redirect set.

Q: How do teams know whether redirect URI management is under control?

A: A healthy programme can answer three questions quickly: which URIs are active, which tenant owns each one, and when each old callback will be removed. If those answers live in team memory or ticket history instead of a governed inventory, the process is already too brittle for scale.

Q: Who is accountable when a redirect URI migration breaks sign-in?

A: Accountability sits with the team that owns both application authentication and tenant migration sequencing, because the failure is a governance gap, not a user problem. If the new callback was not registered before cutover or the old one was removed too early, the change control process failed to protect the identity flow.

Technical breakdown

Exact-match redirect URI validation

Google checks the redirect URI in the authorization request against the registered list using exact string comparison. That includes the scheme, host, port, and path, so trailing slashes, case changes, and path normalization differences all matter. In practice, this removes ambiguity for the authorization server but creates a brittle boundary for applications that generate callback URLs dynamically or operate across multiple customer domains. The constraint is deliberate because loose matching can be exploited to redirect auth codes to attacker-controlled endpoints.

Practical implication: treat redirect URIs as fixed configuration values and validate them before every cutover.

Redirect URI migration and cutover risk

When a tenant changes domains, both the old and new redirect URIs must be valid during the transition window. If the new URI is not registered before DNS or application cutover, users hit redirect_uri_mismatch errors and the login flow breaks. If the old URI is removed too early, in-flight sessions fail. This is the same control problem as any staged identity migration: the identity boundary has to remain stable until all dependent sessions and registrations have moved cleanly.

Practical implication: run old and new callback registrations in parallel until session state and DNS propagation are confirmed.

Scaling OAuth callback governance across tenants

At scale, the main challenge is not the validation rule itself but the lifecycle overhead of managing many tenant-specific URIs. Google’s client-level limit, manual console administration, and lack of a comparable configuration API force teams to choose between per-customer clients, a central proxy pattern, or a tightly controlled registration workflow. Each model changes the blast radius of a mistake. A shared proxy reduces registration sprawl but concentrates trust in one callback path; per-customer clients isolate tenants but increase provisioning overhead.

Practical implication: choose one governed registration model and document the fallback path before you approach scale limits.

Breaches seen in the wild

• Salesloft OAuth token breach — hackers stole OAuth tokens to access Salesforce data via Salesloft.
• Dropbox Sign breach — compromised Dropbox Sign service account exposed API keys and OAuth tokens.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Exact redirect matching is a security control, not a convenience feature. The article shows why Google refuses wildcard flexibility: loose callback rules create room for code interception and tenant confusion. That design is defensible, but it means the operational burden shifts entirely to the application owner. The implication for practitioners is that OAuth redirect governance must be treated as part of identity control design, not just app setup.

Redirect URI migration is a lifecycle control problem hiding inside an authentication flow. The failure mode is not merely a broken sign-in. It is a cutover that can outpace registration, leaving old and new callback endpoints out of sync with tenant DNS and session state. This is classic lifecycle drift, and it belongs in change management, not ad hoc developer handling.

Central callback proxies and per-tenant OAuth clients are governance choices with different blast radii. A single proxy simplifies registration but concentrates trust and raises the stakes of a routing error. Per-customer clients reduce cross-tenant impact but multiply provisioning and offboarding overhead. The right model depends on whether the organisation wants to optimise for operational simplicity, tenant isolation, or migration control.

Redirect URI sprawl is a signal that identity governance is leaking into application logic. Once teams are manually tracking dozens or hundreds of callback strings, they are effectively running an identity inventory without controls for ownership, retirement, or review. That pattern is a strong indicator that OAuth administration needs to move into governed infrastructure processes.

Callback registration drift: The deeper issue is that the registered redirect URI often outlives the domain change process that created it, which makes identity boundaries stale even when authentication still works. Practitioners should read that as a lifecycle failure mode: the approved callback set no longer matches the real application topology.

From our research:

• 92% of organisations expose NHIs to third parties, raising concerns about supply chain security, according to Ultimate Guide to NHIs.
• Only 5.7% of organisations have full visibility into their service accounts, which is why callback ownership and retirement need an inventory discipline, not ad hoc tracking.
• Redirect governance and NHI visibility both point to the same next step, as covered in the Ultimate Guide to NHIs.

What this signals

Redirect URI control is becoming a governance signal for IAM maturity. Teams that still manage callbacks manually will struggle as tenant counts rise, because lifecycle timing and ownership become harder than the authentication itself. The practical test is whether your organisation can prove who registered each URI, who approved it, and when it will be retired.

The broader pattern is familiar across NHI and human identity programmes. When identity boundaries are embedded in application code or deployment tickets, governance loses its audit trail. Organisations that want safer OAuth operations need a named owner, a clean inventory, and a migration process that is visible before cutover begins.

URI lifecycle debt: each additional callback entry increases the chance that authentication will succeed against a stale or unintended trust boundary. That is a forward-looking risk for any SaaS environment supporting customer-owned domains, especially where sign-in reliability is part of the product contract.

For practitioners

• Canonicalise redirect URI construction Treat the callback string as a constant and verify that the scheme, host, port, and path match the registered value exactly in every environment.
• Register new URIs before cutover Add the replacement callback to Google Cloud Console before DNS changes or tenant migration begins, then keep both URIs active through the transition.
• Retire old URIs with a documented delay Do not remove the previous callback until in-flight sessions have cleared and the new flow has been validated end to end.
• Monitor redirect_uri_mismatch errors Alert on mismatch errors in OAuth logs so registration gaps surface as operational issues instead of support tickets.
• Choose a scale model before the limit hits If tenant-specific domains are approaching the 100 URI ceiling, decide whether to split clients or centralise through a controlled proxy path.

Key takeaways

• Google’s exact-match redirect URI model reduces one class of OAuth abuse, but it shifts the operational burden to the application owner.
• Multi-tenant domain changes create a lifecycle risk: if the new callback is not registered in time, sign-in breaks and stale URIs linger.
• Teams need governed URI inventory, parallel cutover, and clear retirement rules if they want OAuth to scale safely across customers.

Key terms

• Redirect URI: The redirect URI is the callback address an OAuth provider sends a user back to after authentication. In practice, it is part of the trust boundary for the login flow. If the registered value and the runtime value differ, the provider rejects the request and the sign-in fails.
• Redirect URI drift: Redirect URI drift happens when the approved callback list no longer matches the application’s real routing, tenant domains, or migration state. It is a governance problem, not just a configuration mistake, because stale entries can outlive the business change that created them and confuse authentication cutovers.
• OAuth callback proxy: An OAuth callback proxy is a controlled intermediary that receives a single registered redirect and forwards the user internally to the correct tenant destination. It reduces registration sprawl, but it concentrates trust in one path and requires careful handling of state, routing, and open redirect protection.

Deepen your knowledge

Google OAuth redirect URI governance for multi-tenant apps is a practical topic in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you manage customer domains, callback cutovers, or OAuth registration at scale, it is worth exploring.

This post draws on content published by WorkOS: Google OAuth's strict redirect URI matching, a guide for multi-tenant apps. Read the original.