How Single Sign-On (SSO), OAuth 2.0, and OpenID Connect Work
From the browser redirect dance and Proof Key for Code Exchange (PKCE) to JWT signature verification, SAML assertions, and identity provider federation
“How does 'Sign in with Google' or corporate SSO let you access third-party websites without ever revealing your actual password to those sites?”
Before federated identity, every website demanded its own password or asked for your primary email credentials. Single Sign-On, OAuth 2.0, and OpenID Connect solved this by replacing shared passwords with cryptographically signed tokens, using the browser as an untrusted messenger in a multi-party redirect dance involving authorization codes, PKCE challenges, and JSON Web Tokens.
- Why is sharing your password with a third-party app an architectural catastrophe?
- What is the crucial difference between Authorization (OAuth 2.0) and Authentication (OpenID Connect)?
- How does the Authorization Code flow use your browser as an untrusted messenger without exposing secret tokens?
- How does Proof Key for Code Exchange (PKCE) prevent mobile apps from stealing authorization codes?
- What mathematical cryptographic structure exists inside a JSON Web Token (JWT) id_token?
- How does a website verify a JWT signature using an Identity Provider's public JWKS endpoint?
To build a complete first-principles mental model of this mechanism, we recommend starting with these foundational explainers:
In the early 2000s, if a new photo-printing website wanted to let you print photos from your Yahoo or Google account, or if a social networking site wanted to find your friends from your email contacts, it presented you with an unsettling form: “Enter your full Google email address and your Google password here so we can log in and check your contacts.”
Millions of users complied. They handed their primary master passwords to obscure third-party startups.
The consequences were catastrophic:
- The third-party website held your plaintext password, allowing it to read your private emails, delete your files, or impersonate you across the web.
- The third-party website stored your password in an unhashed database; when that startup was breached, your master email account was compromised.
- You could not grant partial access: you could not say "You can read my address book, but you cannot read my emails." It was all or nothing.
- If you wanted to revoke the app’s access, your only recourse was to change your master Google password, which broke every other service you used!
Today, that anti-pattern is extinct. When an app wants to connect to your Google, GitHub, or Apple account, or when your company uses an enterprise portal like Okta or Microsoft Entra ID to sign you into fifty different software tools with a single click, you never enter your password into the third-party app.
Instead, a synchronized, cryptographic choreography unfolds behind the scenes: Single Sign-On (SSO) powered by OAuth 2.0 and OpenID Connect (OIDC).
Your browser executes a multi-party redirect dance, temporary cryptographic challenges protect untrusted mobile apps, and servers issue tamper-proof digital passports called JSON Web Tokens (JWTs).
Here is how modern federated identity securely authenticates the internet.
1. Authentication vs. Authorization: The Fundamental Confusion
Before examining the protocol machinery, one must clarify the distinction between two words that software engineers frequently conflate: Authentication and Authorization.
+----------------------------------------------------------------------------------------------------+
| AUTHENTICATION (AuthN) vs. AUTHORIZATION (AuthZ) |
+----------------------------------------------------------------------------------------------------+
| |
| AUTHENTICATION (AuthN): "WHO ARE YOU?" |
| - Verifying the identity of an entity. |
| - Proof that the human sitting at the keyboard is indeed Alice. |
| - Analog: Presenting your government passport at an international border checkpoint. |
| - The Governing Standard: OPENID CONNECT (OIDC) / SAML 2.0 |
| |
| AUTHORIZATION (AuthZ): "WHAT ARE YOU ALLOWED TO DO?" |
| - Granting specific, scoped permissions to access resources. |
| - Deciding whether a third-party application has permission to read Alice's Google Drive files. |
| - Analog: Handing a valet parking attendant a physical valet key that starts the engine but |
| cannot unlock the glove compartment or the trunk. |
| - The Governing Standard: OAUTH 2.0 (RFC 6749) |
| |
+----------------------------------------------------------------------------------------------------+
OAuth 2.0 was originally created strictly as an authorization protocol. It was never designed to tell an app who you are; it was designed to issue a scoped valet key (an Access Token) allowing an app to fetch specific files on your behalf.
Because developers desperately wanted a standardized way to log users in ("Sign in with X"), they hacked OAuth 2.0 for years to simulate identity, leading to widespread security vulnerabilities.
To solve this properly, the OpenID Foundation built OpenID Connect (OIDC) as a formal identity layer resting directly on top of OAuth 2.0.
2. The Four Roles of OAuth 2.0
RFC 6749 defines four distinct entities that participate in an identity and access negotiation:
+----------------------------------------------------------------------------------------------------+
| THE FOUR ACTORS OF OAUTH 2.0 |
+----------------------------------------------------------------------------------------------------+
| |
| 1. RESOURCE OWNER (The User) |
| The human being who owns the data (e.g., Alice, who owns her Google Drive photos). |
| |
| 2. CLIENT (The Relying Application) |
| The third-party website or mobile app wanting access (e.g., PrintMyPhotos.com). |
| |
| 3. AUTHORIZATION SERVER (The Identity Provider / IdP) |
| The trusted server holding user credentials (e.g., accounts.google.com). |
| Authenticates the user, collects consent, and mints cryptographic tokens. |
| |
| 4. RESOURCE SERVER (The API) |
| The server hosting the user's protected assets (e.g., www.googleapis.com/drive/v3/files). |
| Accepts and validates access tokens before serving data. |
| |
+----------------------------------------------------------------------------------------------------+
The fundamental security rule of OAuth is:
All password entry and multi-factor authentication (passkeys, SMS, authenticator apps) occur exclusively inside the secure, isolated domain of the Authorization Server.
3. The Authorization Code Flow: The Browser Redirect Dance
How can an app receive permission to access your account without seeing your password?
The industry standard pattern for web applications is the Authorization Code Grant Flow.
It splits communication into two distinct network channels:
- The Front-Channel (Untrusted): Uses the user’s web browser via HTTP 302 redirects and query parameters. Because query parameters appear in browser history, server access logs, and can be intercepted by rogue browser extensions, high-value secret tokens must never travel over the front-channel!
- The Back-Channel (Highly Secure): A direct, server-to-server HTTPS connection between the Client backend and the Authorization Server, invisible to the user's browser.
+----------------------------------------------------------------------------------------------------+
| THE AUTHORIZATION CODE REDIRECT DANCE |
+----------------------------------------------------------------------------------------------------+
| |
| Browser (User-Agent) Client Backend (App) Authorization Server (Google IdP) |
| | | | |
| |-- 1. Clicks "Login" -------->| | |
| | |-- 2. HTTP 302 Redirect to IdP ----->| |
| | (client_id, scope, redirect_uri) | |
| | | |
| |<-- 3. Presents Login Page & Consent Screen ------------------------| |
| | (User enters password, verifies Passkey/2FA, clicks "Allow") | |
| | | |
| |<-- 4. HTTP 302 Redirect back to Client with AUTHORIZATION CODE ----| |
| | Location: https://app.com/callback?code=AUTH_CODE_xyz&state=abc | |
| | | |
| |-- 5. Browser follows redirect to Client Callback URL ------------->| |
| | | |
| | |-- 6. DIRECT BACK-CHANNEL POST ----->| |
| | | (auth_code + client_secret) | |
| | | | |
| | | *** IdP verifies secret & code ***| |
| | | | |
| | |<- 7. Returns Tokens (HTTPS Body) ---| |
| | | (access_token + id_token) | |
| | | | |
| |<-- 8. Sets Session Cookie <--| | |
| | "You are logged in!" | | |
| |
+----------------------------------------------------------------------------------------------------+
{`
User (Browser) Client Web Server Google Auth Server (IdP) Google Drive API
| | | |
|-- 1. Click "Sign in" ------->| | |
| |-- 2. 302 Redirect to IdP ---->| |
| | (scope, client_id, state) | |
| | | |
|<- 3. Show Google Login Screen ===============================| |
|-- 4. User Enters Password / Passkey ------------------------>| |
|-- 5. User Consents to Scope ("Read Drive Files") ----------->| |
| | | |
|<- 6. 302 Redirect with Temporary Authorization Code ---------| |
| (code=AUTH_CODE_4917) | | |
| | | |
|-- 7. GET /callback?code=4917>| | |
| |-- 8. Back-channel POST Code ->| |
| | (code + client_secret) | |
| | | |
| |<- 9. Returns Access Token & --| |
| | ID Token (JWT) | |
| | | |
| |-- 10. GET /files (Bearer Token) ------------------------->|
| | | |-- 11. Validates Token
| |<- 12. Returns User Photos --------------------------------| Returns JSON Data
| | | |
|<- 13. Render Dashboard ------| | |
`}
Client redirects user's browser to the IdP with requested scopes, client ID, and an anti-CSRF state token.
User logs into Google using their passkey or 2FA; Google verifies identity without sharing credentials with the client.
Google redirects back to the client's redirect URI carrying an ephemeral, single-use Authorization Code (valid for ~60s).
Client server makes a direct HTTPS call to Google, exchanging the code and its private client secret for final access and ID tokens.
Client presents the cryptographically signed Bearer Access Token to the API resource server to fetch user data.
Notice why this architecture is brilliant: The Authorization Code that travels through the user's browser is completely useless by itself! If an attacker or a malicious browser extension intercepts the code, they cannot use it. Why? Because exchanging the code for an actual Access Token requires the Client Secret—a private password known only to the Client backend server and the IdP, which is never exposed to the browser.
4. PKCE: Protecting Native Mobile Apps and SPAs
The classic Authorization Code flow worked flawlessly for traditional server-rendered websites. But in the 2010s, two architectural revolutions occurred:
- Single-Page Applications (SPAs): Web apps written in React, Vue, or Angular running entirely inside the user's browser.
- Native Mobile Apps: iOS and Android apps running on mobile operating systems.
Neither SPAs nor mobile apps can keep a secret! If you hardcode a client_secret inside a React JavaScript bundle or an Android .apk file, any attacker can decompile the app, extract the secret in five seconds, and impersonate the application. They are Public Clients.
Furthermore, on mobile operating systems, apps register custom URI schemes (e.g., myapp://oauth-callback) to receive the authorization code. A malicious rogue app installed on the same phone could register that identical URI scheme, intercept the authorization code when the browser redirects, and steal the user's account!
To solve this, the IETF created RFC 7636: Proof Key for Code Exchange (PKCE) (pronounced "pixie").
+----------------------------------------------------------------------------------------------------+
| PROOF KEY FOR CODE EXCHANGE (PKCE) ARCHITECTURE |
+----------------------------------------------------------------------------------------------------+
| |
| 1. CODE VERIFIER GENERATION |
| Mobile App generates a cryptographically random, unguessable string: |
| Code Verifier = "dBjftJeZ4CVP-mB92K27uhbUJU1p1r_wW1gFWFOEjXk" (43 to 128 characters) |
| |
| 2. CODE CHALLENGE DERIVATION |
| Mobile App computes the SHA-256 hash of the verifier, and base64url encodes it: |
| Code Challenge = Base64URL( SHA-256( Code Verifier ) ) |
| |
| 3. THE REQUEST (Front-Channel) |
| App opens browser: https://auth.google.com/authorize? |
| client_id=my_mobile_app |
| &code_challenge=E9Melhoa2OwvFrGMTJguCH5rtx64 |
| &code_challenge_method=S256 |
| Google saves the Code Challenge in memory. |
| |
| 4. THE INTERCEPTION (Rogue App steals the code) |
| Google issues auth code via redirect: myapp://callback?code=AUTH_CODE_xyz |
| Suppose a rogue hacker app intercepts this code! Can the hacker steal the token? |
| |
| 5. THE TOKEN EXCHANGE (Back-Channel Proof) |
| To swap the code for a token, the caller MUST present the original CODE VERIFIER: |
| POST /token |
| code=AUTH_CODE_xyz |
| &code_verifier=dBjftJeZ4CVP-mB92K27uhbUJU1p1r_wW1gFWFOEjXk |
| |
| Google takes the verifier, hashes it: SHA-256(verifier). |
| Does it match the Code Challenge saved in Step 3? |
| - MATCH! ===> Issue Access Token. |
| - NO MATCH! ===> REJECT! |
| |
| The rogue app NEVER possessed the original random verifier (which remained stored in the |
| legitimate app's private memory sandbox). The stolen code is totally worthless! |
| |
+----------------------------------------------------------------------------------------------------+
PKCE uses one-way cryptographic hashing to mathematically bind the initial authorization request to the final token exchange. Today, the OAuth security working group mandates PKCE for all applications—both public mobile apps and confidential backend servers.
5. OpenID Connect (OIDC) & The Anatomy of a JWT
OAuth 2.0 returns an Access Token: an opaque string of characters (e.g., ya29.a0AfH6SM...).
The access token tells the API: "The bearer of this token is allowed to execute HTTP GET on /drive/v3/files."
Crucially, the access token does not tell the client website who you are. It does not contain your name, your email address, or an expiration timestamp that the client can verify without querying Google's servers.
OpenID Connect (OIDC) extends OAuth 2.0 by returning an additional, dedicated identity artifact: the ID Token.
The ID Token is formatted as a JSON Web Token (JWT) (RFC 7519), pronounced "jot".
+----------------------------------------------------------------------------------------------------+
| THE THREE SEGMENTS OF A JSON WEB TOKEN (JWT) |
+----------------------------------------------------------------------------------------------------+
| |
| A JWT is a single string composed of three Base64URL-encoded parts, separated by periods (.): |
| |
| eyJhbGciOiJSUzI1NiIsImtpZCI6IjFhMmIifQ . eyJzdWIiOiIxMjM0NTYiLCJlbWFpbCI6ImFsaWNlQGV4YW1wbGUuY29tIn0 . dBjftJeZ4CVP-mB...|
| [------- 1. HEADER (Red) -------] [---------- 2. PAYLOAD (Green) ----------] [----- 3. SIGNATURE (Blue) -----] |
| |
+----------------------------------------------------------------------------------------------------+
When decoded from Base64URL, the internal structure is pure JSON:
Part 1: The Header
Specifies the cryptographic algorithm and key identifier used to sign the token:
{
"alg": "RS256",
"typ": "JWT",
"kid": "k9f2b847a1"
}
alg: "RS256": RSA Signature with SHA-256 hash.kid: Key ID, indicating which specific public key from the IdP's certificate list signed this token.
Part 2: The Payload (The Claims)
Contains the actual identity assertions attested by the Identity Provider:
{
"iss": "https://accounts.google.com",
"sub": "108294719283749102938",
"aud": "my-photo-print-app-client-id.apps.googleusercontent.com",
"email": "alice@gmail.com",
"email_verified": true,
"name": "Alice Smith",
"iat": 1712839200,
"exp": 1712842800,
"nonce": "n-0S6_WzA2Mj"
}
Every field has a precise security meaning:
iss(Issuer): Must match the exact URL of the Identity Provider.sub(Subject): A unique, permanent, non-reassignable identifier for the user. (Even if Alice changes her email address, hersubnever changes!).aud(Audience): Must match the Client ID of the receiving app. If HackerApp tries to take an ID token issued for them and send it to PhotoPrintApp, PhotoPrintApp checksaud, sees HackerApp's ID, and immediately rejects the token!exp(Expiration): Unix timestamp after which the token is invalid (typically 1 hour).nonce: Cryptographic random string matching the initial authorization request, preventing replay attacks.
Part 3: The Signature
The signature is generated by the Identity Provider using its private key:
6. Stateless Verification via JWKS
How does the receiving website verify that the ID Token was actually created by Google and was not forged by a hacker?
The client website does not need to make a network API call to Google every time a user loads a page! This is the superpower of asymmetric cryptography: stateless verification.
+----------------------------------------------------------------------------------------------------+
| HOW STATELESS JWKS VERIFICATION WORKS |
+----------------------------------------------------------------------------------------------------+
| |
| 1. DISCOVERY ENDPOINT |
| Client website checks Google's OpenID configuration (cached for 24 hours): |
| GET https://accounts.google.com/.well-known/openid-configuration |
| Returns: { "jwks_uri": "https://www.googleapis.com/oauth2/v3/certs" } |
| |
| 2. FETCHING THE JSON WEB KEY SET (JWKS) |
| Client fetches the public keys: |
| GET https://www.googleapis.com/oauth2/v3/certs |
| Returns an array of RSA public keys: |
| { |
| "keys": [ |
| { |
| "kid": "k9f2b847a1", |
| "kty": "RSA", |
| "n": "u1P8vR9qZ...", // Modulus |
| "e": "AQAB" // Public Exponent (65537) |
| } |
| ] |
| } |
| |
| 3. LOCAL MATHEMATICAL VERIFICATION |
| The client matches the token's header `kid` ("k9f2b847a1") to the fetched public key. |
| The client runs: |
| |
| RSA_Verify( PublicKey, Header + "." + Payload, Signature ) |
| |
| If the math checks out: The client is 100% mathematically certain that Google (and only |
| Google) generated this token, and that not a single character in the payload was modified! |
| |
+----------------------------------------------------------------------------------------------------+
Because verification requires only the IdP's public key, a backend server can verify hundreds of thousands of user requests per second locally in RAM without putting any load on Google's infrastructure!
7. Enterprise SSO: SAML 2.0 vs. Modern OIDC
In corporate enterprise environments (banks, hospitals, Fortune 500 companies), Single Sign-On historically relied on SAML 2.0 (Security Assertion Markup Language), developed by OASIS in 2005.
+----------------------------------------------------------------------------------------------------+
| SAML 2.0 vs. OPENID CONNECT (OIDC) |
+----------------------------------------------------------------------------------------------------+
| Feature | SAML 2.0 | OpenID Connect (OIDC) |
+------------------------+-----------------------------------+---------------------------------------+
| Data Encoding | Heavy, verbose XML | Lightweight JSON / REST |
| Cryptography | XML Digital Signatures (XML-DSig) | JSON Web Signature (JWS / RS256) |
| Transport Channel | HTTP POST Binding (Base64 in HTML)| HTTP Redirect + Header Bearer Tokens |
| Mobile / API Friendly | Extremely difficult to use | Native mobile and SPA support |
| Primary Domain | Legacy Enterprise (Okta, Ping) | Modern Web, Mobile, Cloud native |
+----------------------------------------------------------------------------------------------------+
While SAML 2.0 remains deeply entrenched in legacy enterprise infrastructure, its reliance on XML Digital Signatures has made it notorious for critical security vulnerabilities: XML canonicalization bugs, XML External Entity (XXE) injection attacks, and signature-wrapping exploits where an attacker modifies the XML assertion while preserving a valid signature block.
Modern enterprise identity providers (Okta, Microsoft Entra ID, Ping Identity) are rapidly transitioning new enterprise integrations to OpenID Connect due to its simpler JSON syntax and robust JWT security guarantees.
8. Common Misconceptions & Real-World Failure Modes
Misconception 1: "If I Sign in with Google, Google Can Track Everything I Do on That App"
When you use Google SSO to log into a site (e.g., Spotify):
- Google knows that you logged into Spotify, and the exact timestamp of your login.
- However, Google cannot see what you do inside Spotify. Google does not know what songs you listen to, what playlists you create, or how long you use the app. The access token granted to Spotify is a one-way ticket: Spotify uses it to verify your identity; it does not report your app telemetry back to Google.
Misconception 2: "Revoking an App's Access Immediately Kills Active Sessions"
A major architectural dilemma of stateless JWT tokens is revocation latency.
When an app verifies a JWT locally using a JWKS public key, it does not contact the IdP. If you go into your Google account settings and click "Revoke access to PhotoPrintApp," PhotoPrintApp's backend has no immediate way of knowing you revoked access until the currently issued JWT reaches its expiration timestamp (exp), which is typically 60 minutes.
To bridge this gap, modern identity architectures use:
- Short-Lived Access Tokens (5 to 15 minutes).
- Long-Lived Refresh Tokens: Stored securely on the server and exchanged every 10 minutes. When a refresh token exchange occurs, the IdP checks its revocation database and blocks further token issuance immediately.
- Continuous Access Evaluation (CAE) / Backchannel Logout (RFC 8693): The IdP actively pushes a webhook event to registered clients when a user changes their password or reports a lost device.
Critical Failure Mode: Missing the state Parameter (OAuth CSRF)
If an app initiates an OAuth flow without generating and validating a cryptographically random state parameter, it is vulnerable to OAuth Login CSRF:
- An attacker initiates an OAuth login with their own Google account on a target website, intercepts the authorization code before their browser finishes, and stops.
- The attacker tricks a victim into clicking a link that injects the attacker's authorization code into the victim's browser session.
- The victim's browser sends the attacker's code to the website. The website logs the victim into the attacker's account!
- The victim innocently enters their credit card or uploads personal tax documents, which are now permanently stored in the attacker's account!
The state parameter solves this by serving as an unguessable CSRF token tied to the user's browser session cookie, ensuring that the browser receiving the callback is the exact same browser that initiated the login.
Summary: The Web's Cryptographic Passport
Single Sign-On and OAuth 2.0 solved the foundational trust crisis of the digital age: how to share resources and prove identity across independent companies without sharing secret credentials.
+----------------------------------------------------------------------------------------------------+
| THE FOUNDATIONAL PILLARS OF MODERN FEDERATED IDENTITY |
+----------------------------------------------------------------------------------------------------+
| |
| 1. ASYMMETRIC REDIRECTION |
| Browsers act as untrusted conduits, passing short-lived codes rather than permanent secrets. |
| |
| 2. CRYPTOGRAPHIC PKCE BINDING |
| SHA-256 challenges ensure that native mobile apps cannot have their authorization hijacked. |
| |
| 3. STATELESS JWT VERIFICATION |
| Base64-encoded, digitally signed identity tokens eliminate database bottlenecks across APIs. |
| |
| 4. THE VALET PRINCIPLE |
| Scoped access tokens give apps minimum necessary permissions without master password access. |
| |
+----------------------------------------------------------------------------------------------------+
Every time you click a single button to sign into an app with Google, GitHub, or Apple, you are not skipping security—you are activating one of the most elegant distributed cryptographic protocols ever conceived: turning web redirects, asymmetric public keys, and JSON web tokens into an invisible, secure passport for the global internet.
Where to Go From Here
Follow downstream mechanisms, contrasting architectures, or applications of these principles.
How OTP and Two-Factor Authentication Actually Work
Deep-dive following foundational explainer How OTP and Two-Factor Authentication Actually Work
Why SMS OTPs Sometimes Arrive Late or Fail Entirely
Deep-dive following foundational explainer Why SMS OTPs Sometimes Arrive Late or Fail Entirely
Verified Specifications & Architectural References
This explainer is grounded in primary-source engineering specifications, regulatory circulars, and standard documentation.
The OAuth 2.0 Authorization Framework (RFC 6749)
The definitive internet standard defining the four OAuth roles, authorization grants, token types, and the authorization code redirection flow.
Proof Key for Code Exchange by OAuth Public Clients (RFC 7636)
Specifies the PKCE extension mitigating authorization code interception attacks on public clients and native mobile apps.
OpenID Connect Core 1.0 incorporating errata set 2
The standard defining the identity layer on top of OAuth 2.0, standardizing the id_token, UserInfo endpoint, and standard claims.
JSON Web Token (JWT) (RFC 7519)
The format specification defining compact, URL-safe means of representing claims to be transferred between two parties as JSON objects.