Understanding OAuth 2.0 and OpenID Connect

Authentication and authorization are hard. OAuth 2.0 simplifies delegated access.

OAuth handles authorization (granting access via tokens), while OpenID Connect (OIDC) provides an identity layer, returning an ID Token so the client knows *who* authenticated.

OAuth 2.0 is an authorization framework, not an authentication protocol. It allows a user (Resource Owner) to grant a third-party application (Client) limited access to their resources stored on a Resource Server without sharing passwords. The Authorization Server issues access tokens (opaque or JWT) after a successful grant.

Grant Types

• Authorization Code: Most secure, used by server-side apps. Involves a front-channel redirect and a back-channel token exchange.
• Client Credentials: Machine-to-machine communication where client ID and secret directly request a token.
• Implicit (deprecated): Tokens returned directly in the redirect; avoided due to security flaws.
• PKCE-enhanced Authorization Code: Mandatory for single-page and mobile apps; adds a code challenge to prevent interception attacks.

OIDC is a thin identity layer on top of OAuth 2.0. It introduces the ID Token, a JWT that contains claims about the authenticated user (sub, name, email, etc.). The Client verifies the ID Token’s signature and validates the issuer (iss) and audience (aud). OIDC also standardizes a UserInfo endpoint for fetching additional profile data.

Key Flows

• Authorization Code Flow with OIDC: Client receives both an access token and an ID token after the code exchange.
• Hybrid Flow: Allows tokens to be returned from the front-channel and the ID token from the back-channel, useful for certain native apps.

• Always use PKCE, even for confidential clients.
• Validate state parameters to prevent CSRF.
• Store tokens securely; never put refresh tokens in the browser.
• Use short-lived access tokens and refresh token rotation.
• Implement dynamic client registration with strict validation.

• “OAuth handles authentication” – it doesn’t; without OIDC you have no standard way to get user identity.
• “JWTs are encrypted” – they are base64-encoded and signed, not encrypted (unless you use JWE).
• “Implicit flow is fine for SPAs” – it’s deprecated; always use Authorization Code + PKCE.

Mastering OAuth 2.0 and OIDC is essential for modern web and mobile apps. Start by implementing a simple server-side flow with a library like Passport.js or Spring Security. Then layer on OIDC to add identity. The specifications are complex, but the security payoff—delegated access and single sign-on across applications—is immense.