Centralized Authentication: One Door, Many Rooms

Google changed their OAuth flow.

I had to update three apps. Three separate login implementations. Three codebases that started identical but diverged just enough to make the update painful.

My fault. I'd copy-pasted the login logic instead of centralizing it.

When I added password reset, I updated App A. Forgot App B. App C got a different version because I'd "fixed" something in between. None of them worked the same way.

Every auth change meant three updates. Three test suites. Three deployments. Three chances to screw it up.

I built centralized auth to stop the duplication. One system handles login. Apps redirect there, get proof, create their own sessions.

Here's how it works.

How It Works

Three pieces:

• Apps: Your products (dashboard, marketing site, mobile app)
• Central Auth: The only system that handles login
• Identity Providers: The actual authentication (passwords, Google, Apple)

Apps don't authenticate. They verify proof from Central Auth.

That separation is critical.

The Flow (OAuth-Style Authorization Code + Exchange)

This is the same shape as the OAuth authorization code flow.

Important: Each app (app1.com, app2.com, app3.com) goes through this flow independently when a user visits. They all redirect to the same auth service, but each manages its own session.

Step 1: App needs a user

User visits AppA. AppA checks for a local session.

• If session exists: continue
• If session is missing: redirect to Central Auth

Step 2: Central Auth authenticates

Central Auth runs the login experience and verifies identity.

Step 3: Central Auth returns a short-lived code

Central Auth redirects back to AppA with a short-lived, one-time authorization code.

This is the point: the browser gets a code, not a long-lived token.

Step 4: App exchanges code server-to-server

AppA sends the code to Central Auth directly and exchanges it for a session.

• Central Auth validates: issued-for-app, not-expired, not-used
• AppA creates: a local session (typically an HTTP-only cookie)

When the user later visits AppB, the same flow happens again. AppB redirects to Central Auth, gets its own code, and creates its own session.

Key insights:

• Redirects are for codes, not tokens
• Apps verify proof; they don't perform identity checks
• The exchange is what makes trust auditable
• Each app authenticates independently through the same service

Interactive Example: Code Exchange

Walk the flow step-by-step: redirect, code issuance, and a server-to-server exchange. The goal is to make it obvious what is browser-visible vs server-only.

Interactive Example: Token-in-URL vs Code Exchange

See how tokens leak when they travel through redirects, then compare it to a code exchange that keeps long-lived secrets off the URL.

Why the Code Exchange Exists

If you pass tokens through redirects, you end up leaking them through logs, browser history, referrers, screenshots, proxies, and analytics.

The exchange pattern fixes that by keeping long-lived secrets off the URL path entirely.

Clear Boundaries (Who Owns What)

Central Auth owns

• Login UI and authentication methods
• Issuing codes
• Validating exchanges

Apps own

• Redirecting to auth when needed
• Exchanging codes
• Local sessions and authorization checks
• Session lifecycle (including logout)

Identity providers own

• Proving identity (password/OAuth/email)

Decision Framework

Use centralized auth when:

• You have multiple apps and want one consistent login
• You need one place to enforce policy (MFA, device trust, session limits)
• You want one audit trail for login events

Avoid it (or keep it simple) when:

• You have one app and no real duplication cost
• You can’t afford a strong availability posture for auth yet

Mistakes I Made

Putting tokens in URLs: They leak everywhere. Browser history, logs, screenshots. Use codes instead.

Not validating redirects: I trusted the redirect parameter. Built an attack vector by accident.

Tight coupling: Apps knew too much about auth internals. Changed auth once, broke three apps.

Ignoring logout: Didn't think through logout until production. Each app needs independent session control.

Logging Out: Each App Manages Its Own Session

Since each app authenticates independently and manages its own session, logout is also independent:

What happens when a user logs out of App A:

1. App A clears its session cookie
2. User is logged out of App A only
3. App B, App C remain unaffected

When the user visits App B later:

• App B checks for its own session
• No session exists → redirects to Central Auth
• User authenticates again through Central Auth
• App B creates its own new session

This is the expected behavior. Each app at each domain (app1.com, app2.com, app3.com) has full control over its session lifecycle.

Note: If you want "log out everywhere" behavior (Single Sign-On), you need to add session tracking at the Central Auth level—that's a different pattern beyond basic centralized auth.

Next: Security Pitfalls

Centralized auth removes duplication, but it also creates sharp edges that attackers love.

If you're building this pattern, read the follow-up: Auth redirect attacks: the mistakes that get codes and sessions stolen

Key Takeaways

• Centralized auth is a trust boundary, not a shared login page
• Use authorization code + exchange to keep secrets out of URLs
• Central Auth does identity; apps do sessions and authorization