Notifications
Clear all
Topic starter
01/07/2026 2:07 am
TL;DR: React Router v7 framework mode moves OAuth redirect, code exchange, and session creation fully server-side, reducing client-side token handling and state errors while supporting Google, GitHub, Microsoft, and enterprise SSO, according to WorkOS. The real governance lesson is that auth flows are only as safe as their server-side boundaries, redirect validation, and secret handling.
NHIMG editorial — based on content published by WorkOS: Social login in React Router v7: Google, GitHub, and Microsoft
Questions worth separating out
Q: How should security teams implement social login without exposing OAuth secrets?
A: Keep the authorization redirect, state validation, code exchange, and session creation on the server.
Q: Why do exact redirect URIs matter so much in OAuth flows?
A: OAuth providers validate callback URLs strictly, and even small mismatches can break the flow or create confusing failures.
Q: What do teams get wrong about using email as the identity key?
A: Email is a mutable attribute, not a stable identity anchor.
Practitioner guidance
- Keep OAuth code exchange server-side Place the authorization redirect and token exchange inside loaders, and do not expose client secrets or access tokens to browser code.
- Validate state before exchanging any code Store a random state value in a short-lived cookie during sign-in and reject the callback unless the returned state matches exactly.
- Register exact redirect URIs per provider Configure the full callback URL, including protocol, domain, and path, in each provider console.
What's in the full article
WorkOS's full blog post covers the implementation detail this post intentionally leaves for the source:
- The complete Google, GitHub, Microsoft, and enterprise SSO code paths for React Router v7 framework mode
- The exact loader and action patterns WorkOS uses for sign-in, callback handling, and sign-out
- The AuthKit installer output and dashboard configuration steps for enabling providers
- The provider-specific scope and email-sync handling details that matter once you move past the architecture stage
👉 Read WorkOS's guide to social login in React Router v7 →
React Router v7 social login: what server-side auth changes?
Explore further
01/07/2026 2:30 am
Server-side login is a governance boundary, not just an implementation preference. The article shows why OAuth belongs in loaders and actions when the application owns the authentication flow. That matters because browser-exposed tokens, client-side secret handling, and callback ambiguity all create governance failures that IAM teams cannot see after the fact. The practitioner conclusion is simple: if the browser is part of the trust boundary, the identity model is already weaker than it looks.
A few things that frame the scale:
- 96% of organisations store secrets outside of secrets managers in vulnerable locations including code, config files, and CI/CD tools, according to Ultimate Guide to NHIs.
- 71% of NHIs are not rotated within recommended time frames, increasing the risk of compromise over time, according to Ultimate Guide to NHIs.
A question worth separating out:
Q: When should organisations add enterprise SSO instead of relying on social login?
A: Add enterprise SSO when access must be centrally governed by IT, tied to corporate policy, and revoked as part of employee offboarding. Social login is suitable for self-serve access, but it does not provide the same lifecycle control or organisation-wide policy enforcement as enterprise identity.
👉 Read our full editorial: Social login in React Router v7 shifts auth fully server-side
