Notifications
Clear all
Topic starter
04/06/2026 6:50 pm
TL;DR: Google’s exact-match redirect URI requirement creates operational risk for multi-tenant SaaS apps, where customer-specific domains, migrations, and manual console updates can trigger login failures or misconfigurations, according to WorkOS. Exact matching reduces one attack surface, but it shifts the burden to disciplined URI lifecycle management and safe proxy patterns.
NHIMG editorial — based on content published by WorkOS: Google OAuth's strict redirect URI matching, a guide for multi-tenant apps
Questions worth separating out
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.
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.
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.
Practitioner guidance
- 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.
What's in the full article
WorkOS's full article covers the operational detail this post intentionally leaves for the source:
- Exact redirect registration workflow for Google Cloud Console across tenant domains
- Migration sequence for keeping old and new callbacks live during customer cutover
- Proxy pattern trade-offs, including state handling and open redirect risk
- Practical checklist for monitoring redirect_uri_mismatch errors at scale
👉 Read WorkOS's guide to strict Google OAuth redirect URI handling for multi-tenant apps →
Google OAuth redirect URIs in SaaS: are your controls keeping up?
Explore further
04/06/2026 7:05 pm
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.
A few things that frame the scale:
- 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.
A question worth separating out:
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.
👉 Read our full editorial: Google OAuth redirect URI strictness in multi-tenant apps
