Understanding OAuth and OpenID Connect

Delegated Authentication

OAuth 2.0 and OpenID Connect (OIDC) solve a fundamental problem: how can a third-party application access your data on another service without you ever sharing your password with that third party? When you click 'Sign in with Google', you are never typing your Google password into the third-party website. Instead, Google itself handles the authentication and issues a cryptographic token proving your identity to the requesting application.

The flow works in precise steps. The third-party app redirects your browser to Google's authorization server. You authenticate directly with Google. Google asks if you consent to share specific information (like your email) with the requesting app. Upon consent, Google redirects you back to the app with a short-lived authorization code. The app exchanges this code (plus its own secret credentials) directly with Google's server to receive an access token and optionally an ID token containing your verified identity claims.

The ID token in OpenID Connect is a JSON Web Token (JWT) signed by Google's private key. Any application can verify the token's authenticity using Google's published public key, confirming that the identity claims have not been tampered with. The token includes an expiration timestamp, a nonce preventing replay attacks, and the specific audience (application) it was issued for, ensuring it cannot be reused by a different application.

Everyday Example

Imagine you want to enter a private club, but instead of giving the bouncer your home address and ID card (your password), you call a trusted friend (Google) who is already inside the club. Your friend walks to the door, vouches for you personally, and hands the bouncer a signed guest pass with your name on it. The bouncer lets you in based entirely on your friend's reputation, and you never had to reveal any personal information to the club directly.

The Deep Mathematics

The JWT ID token structure is Header.Payload.Signature where Signature = ECDSA-Sign(sk_issuer, SHA-256(Base64URL(Header) || '.' || Base64URL(Payload))). Verification computes ECDSA-Verify(pk_issuer, SHA-256(Header.Payload), Signature). The 'nonce' claim provides replay resistance, the 'aud' claim restricts token scope to a single relying party, and the 'exp' claim enforces temporal validity. The PKCE (Proof Key for Code Exchange) extension adds S256 challenge where code_challenge = BASE64URL(SHA-256(code_verifier)), preventing authorization code interception attacks.