Identity, OAuth, and Enterprise Authentication — Recollection Notes¶

1. Core Separation (Most Important)¶

Identity systems have two independent concerns:

Authentication
How a user proves who they are
Password, OTP, MFA, passkeys, certificates, etc.
Always an auth server concern
Token Issuance & Delivery
How an authenticated result becomes a token
OAuth / OIDC is one standardized way
Tokens are the real contract

OAuth is NOT authentication.
OAuth is a protocol to obtain tokens after authentication.

2. The Invariant (Never Changes)¶

Regardless of flow:

There must be exactly ONE central authority that issues tokens
under consistent policy rules.

Same user database
Same token issuer
Same claims & scope rules
Same signing keys

How the user authenticated does NOT matter to downstream services.

3. Three Legitimate Enterprise Patterns¶

Case 1 — Password → Session → OAuth (Classic Enterprise)¶

User authenticates on Auth Server UI
Local session (cookie) created
OAuth Authorization Code (+ PKCE) issues tokens

✔ Fully enterprise-standard
✔ Strong security boundary
✔ Common for internal apps

Case 2 — OTP / MFA → Session → OAuth (Modern Enterprise)¶

Passwordless or MFA-first authentication
Still handled entirely by Auth Server UI
OAuth only runs AFTER authentication

✔ More secure than passwords
✔ Used by banks, governments, regulated orgs
✔ OAuth still only handles token issuance

Case 3 — OTP → Token Directly (First-Party Shortcut)¶

Client POSTs OTP
Auth server validates OTP
Token returned directly (no redirect, no OAuth flow)

✔ OAuth protocol NOT used
✔ Still an Identity Provider
⚠️ Only acceptable for first-party, controlled clients
⚠️ Must reuse the SAME token issuance engine

This is common in consumer mobile apps.

4. Why OAuth Exists (And Why It’s Ceremony Sometimes)¶

OAuth solves: - Delegation (“App A accesses API B on my behalf”) - Third-party clients - Untrusted environments (browser, SPA) - Standardized contracts (scopes, claims) - Long-term extensibility

OAuth is NOT required when: - All clients are first-party - No delegation exists - UX speed matters more than standardization

5. Enterprise vs Consumer Tradeoff¶

Aspect	Enterprise	Consumer
Auth location	Auth server UI only	Often native
MFA	Mandatory	Optional
OAuth	Always	Sometimes
UX priority	Lower	Very high
Security posture	Strict	Pragmatic

6. How Standard IdPs (Keycloak / IdentityServer) Handle This¶

Support multiple authentication methods
Password, OTP, MFA, passkeys, certs
All methods converge to one token engine
OAuth is:
Exposed for browsers & third parties
Hidden or bypassed for first-party mobile apps
Custom grants / direct access supported

OAuth is one token acquisition protocol, not the identity system itself.

7. Resume-Defense One-Liners¶

Use these in interviews:

“OAuth is about token delegation, not user authentication.”
“Authentication methods vary; token issuance must not.”
“Enterprise systems centralize authentication and use OAuth only to transport the result.”
“Direct OTP-to-token flows are valid for first-party apps but not for third-party delegation.”
“The real contract is the token issuer, not the login UX.”