DocTreeDocTree

A learning path ready to make your own.

JWT vs OAuth2 vs OpenID Connect: Simple Explanation for Developers

TL;DR JWT — a compact, URL-safe token format for encoding claims (signed via JWS, optionally encrypted via JWE). OAuth 2.0 — an authorization framework for delegated access (how a client gets permission to access resources). OpenID Connect (OIDC) — an identity layer on top of OAuth 2.0 that supports authentication and returns an ID Token (usually a JWT). They complement each other: OAuth2 handles authorization, OIDC adds authentication/ID tokens, and JWT is a common token format used by both. Background & purpose Standards: JWT (RFC 7519), OAuth 2.0 (RFC 6749), OIDC (built on OAuth2, published 2014). Different questions: "Who is the user?" = OIDC (authentication). "Can this client do X?" = OAuth2 (authorization). "How to encode tokens/claims?" = JWT (format). Core concepts & actors Resource Owner — user or entity owning resources. Client — app requesting access. Authorization Server — issues tokens and handles auth/consent. Resource Server (API) — validates access tokens and serves resources. Key terms: access token, refresh token, ID token (OIDC), scope, grant/flow, JWK (public keys). JWT — quick deep dive Structure: three parts Base64URL(header).Base64URL(payload).Base64URL(signature). Typical claims: iss, sub, aud, exp, iat, nbf, jti. Signing/encryption: JWS (signed) — HS256 (symmetric), RS256/ES256 (asymmetric, recommended across distributed services). JWE — encrypted JWTs. Pros: self-contained, enables local verification (no network call). Cons: harder to revoke if long-lived, larger payloads, common validation bugs (missing aud/iss checks). OAuth 2.0 — quick deep dive Purpose: delegated authorization (client acts on behalf of user). Main endpoints: authorization endpoint, token endpoint, optional revocation & introspection. Primary grants: Authorization Code (with PKCE), Client Credentials, Device Code, Refresh Token (avoid implicit and resource owner password flows). PKCE: essential for public clients (protects code exchange). Tokens: access_token (opaque or JWT), refresh_token (usually opaque). Typical Authorization Code flow (simplified): redirect → user auth/consent → code → exchange code(+verifier) for tokens. OpenID Connect (OIDC) — quick deep dive Adds ID Token (JWT) with identity claims and a nonce to mitigate replay. Discovery via /.well-known/openid-configuration and key distribution via jwks_uri. UserInfo endpoint returns additional profile claims using the access_token. Validation: verify signature (use JWKs), check iss, aud, exp, iat, and validate nonce. When to use what (decision guide) Authenticate users / SSO: use OIDC (scope=openid). Delegate API access: use OAuth 2.0. Choose token format: JWT for stateless local validation; opaque tokens when you need immediate revocation and central control. Common flows & recommendations Web app (server-side): Authorization Code + PKCE (or standard code flow for confidential clients) + OIDC for identity. Single-page app (SPA): Authorization Code + PKCE; avoid implicit. Use short-lived tokens and safe storage (prefer HttpOnly cookies or backend refresh). Mobile apps: Authorization Code + PKCE with system browser. Machine-to-machine: Client Credentials grant. Security best practices Use TLS everywhere. Prefer short-lived access tokens and refresh tokens with careful handling. Use PKCE for public clients and asymmetric signing (RS256/ES256) where possible. Always validate signature, iss, aud, exp, and for OIDC validate nonce. Store tokens safely in browsers — avoid localStorage for refresh tokens; use Secure, HttpOnly, SameSite cookies or backend storage. Implement revocation endpoints, key rotation (JWKs), and consider introspection if you need central revocation. Watch out for common pitfalls: accepting alg=none, missing aud/iss checks, improper HS256 usage when secret is shared. Deployment patterns Self-contained JWTs: low latency, local validation, but revocation is harder. Opaque tokens + introspection: server-side control and instant revocation, at the cost of an extra network call. Hybrid: JWTs for performance with optional introspection for revocation checks. API Gateway: centralize validation and policy enforcement, forward identity to backends. Libraries & providers (examples) Libraries: Node (passport.js, openid-client), Python (authlib, PyJWT), Java (Spring Security OAuth, Nimbus), Go (go-oidc). Identity providers: Auth0, Okta, AWS Cognito, Azure AD, Google Identity, Keycloak. Current trends & future directions OAuth 2.1 consolidating best practices (PKCE for all, implicit removed). DPoP, mTLS and Token Binding for stronger token binding and replay protections. Continuous Access Evaluation (near-real-time revocation) and more token exchange/federation patterns. Quick FAQs Is JWT an authentication protocol? No — JWT is a format. OIDC is the authentication layer/protocol. Can I validate JWTs locally? Yes, if you validate signature, iss, aud and expiration and manage key rotation. Where to store tokens in browsers? Avoid localStorage for refresh tokens; prefer HttpOnly secure cookies or backend-managed tokens to reduce XSS risk. Which signing algorithm? Prefer asymmetric (RS256/ES256) for distributed verification; avoid shared secrets where possible. Conclusion — simple rules Use OAuth 2.0 for delegated authorization; use OIDC when you need authentication/identity. Treat JWT as a useful format, not a security silver bullet—validate claims, use short lifetimes, and rotate keys. For SPAs/mobile: Authorization Code + PKCE. Choose between opaque tokens (revocable) and JWTs (stateless) depending on your revocation and latency needs. Cheat sheet of recommended flows Authorization Code + PKCE — web, mobile, SPA (recommended). Client Credentials — machine-to-machine. Device Code — input-constrained devices. Refresh Token — renew access tokens (keep secure). Implicit — deprecated; avoid. If you want, I can provide a step-by-step Authorization Code + PKCE example, an Express JWT validation middleware, or a checklist for evaluating identity providers.
Open full tree
JWT vs OAuth2 vs OpenID Connect:Simple Explanation for DevelopersFundamentals of AuthenticationIntroduction to JWTOverview of OAuth2Understanding OpenID ConnectComparative Analysis of ProtocolsPractical Implementations

Let the lesson walk with you.

Podcast

JWT vs OAuth2 vs OpenID Connect: Simple Explanation for Developers podcast

0:00-3:13

Follow the trail that experts already trust.

Resources

Turn quick sparks into lasting recall.

Flashcards

JWT vs OAuth2 vs OpenID Connect: Simple Explanation for Developers flashcards

17 cards

Question

Click to flip
Answer

Prove the idea before it slips away.

Quizzes

JWT vs OAuth2 vs OpenID Connect: Simple Explanation for Developers quiz

12 questions

What is JWT (JSON Web Token)?

Read deeper, connect wider, own the subject.

Deep Article

JWT vs OAuth2 vs OpenID Connect: Simple Explanation for Developers

TL;DR

  • JWT (JSON Web Token) is a token format — a compact, URL-safe way to represent claims that can be signed (and optionally encrypted).
  • OAuth 2.0 is an authorization framework for delegated access (how a client gets permission to access a resource).
  • OpenID Connect (OIDC) is an identity layer built on top of OAuth 2.0 that enables authentication (verifying who a user is) and returns an ID Token (usually a JWT).
  • They are complementary: OAuth2 handles authorization, OIDC adds authentication and ID tokens, and JWT is one common token representation used by both.

This article gives a developer-friendly, in-depth view: history, concepts, flows, security best practices, practical examples and when to use each.

Contents

  • Background & history (standards)
  • Core concepts & actors
  • JWT deep dive (structure, signing, validation)
  • OAuth 2.0 deep dive (flows, endpoints, tokens)
  • OpenID Connect deep dive (ID token, discovery, userinfo)
  • Comparing JWT, OAuth2, OIDC (short decision guide)
  • Common flows and practical examples (code snippets)
  • Security pitfalls & best practices
  • Deployment/architecture patterns (JWT vs opaque tokens, introspection, gateways)
  • Popular libraries and providers
  • Current state & future directions
  • FAQs and quick recommendations

Background & history (standards)

  • JWT: defined in RFC 7519 (2015). Part of a family of JSON-based identity specs (JWS, JWE, JWK).
  • OAuth 2.0: defined in RFC 6749 (2012). A widely used framework for delegated authorization.
  • OpenID Connect: published 2014 (built on OAuth2). Core spec adds authentication semantics and ID Tokens.

Why confusion? Because these technologies often appear together (e.g., an OAuth2 server emits JWT access tokens and OIDC emits JWT ID tokens). But they answer different questions:

  • Who is the user? (authentication) — OIDC
  • Can this client do X on behalf of the user? (authorization) — OAuth2
  • How do we encode claims or tokens? (token format) — JWT

Core concepts & actors

Common actors (OAuth2/OIDC terminology):

  • Resource Owner: the user or entity owning the resource.
  • Client: application wanting access (web app, mobile app, backend).
  • Authorization Server: issues tokens and performs authentication/consent.
  • Resource Server (API): consumes and validates access tokens to permit access.

Key terms:

  • Access token: used to access protected resources (opaque or JWT).
  • Refresh token: used to obtain new access tokens without re-authenticating the user.
  • ID token (OIDC): token containing user identity claims (usually a JWT).
  • Scope: requested/allowed permissions (e.g., profile email read).
  • Grant/Flow: method a client uses to obtain tokens (authorization code, client credentials, etc.).
  • JWK: JSON Web Key; public key format used to expose verification keys.

JWT deep dive

What is a JWT?

  • Compact, URL-safe token composed of 3 parts: header, payload (claims), signature.
  • Encoded as Base64URL(header) + "." + Base64URL(payload) + "." + Base64URL(signature).

Header example: `` { "alg": "RS256", "typ": "JWT", "kid": "abc123" } ``

Payload (claims) example: `` { "iss": "https://auth.example.com", "sub": "user-123", "aud": "api.example.com", "exp": 1618887999, "iat": 1618884399, "scope": "read:messages" } ``

Standard claims:

  • iss (issuer), sub (subject), aud (audience), exp (expiration), nbf (not before), iat (issued at), jti (unique id).

Signing and encryption:

  • JWS (signed): common algorithms HS256 (HMAC) and RS256/ES256 (asymmetric). RS/ES recommended for distributed verification (no shared secret).
  • JWE (encrypted): JWT can be encrypted to hide claims.

Advantages

  • Self-contained: resource servers can validate without contacting the auth server (if they have verification keys).
  • Compact and widely supported.

Disadvantages and caveats

  • Revocation is hard for long-lived JWTs (stateless). Use short TTLs and/or revocation strategies (blacklists or introspection).
  • Large JWTs increase request size (cookies/headers).
  • Inappropriate audience/issuer checks are common bugs.

Example: create & verify JWT (Node.js) ```js // npm install jsonwebtoken jwks-rsa const jwt = require('jsonwebtoken'); const fs = require('fs');

// Signing with RSA private key (server) const privateKey = fs.readFileSync('./private.pem'); const token = jwt.sign({ sub: 'user-123', scope: 'read' }, privateKey, { algorithm: 'RS256', expiresIn: '1h', issuer: 'https://auth.example.com', audience: 'https://api.example.com' }); console.log(token);

// Verification (resource server) const publicKey = fs.readFileSync('./public.pem'); try { const payload = jwt.verify(token, publicKey, { algorithms: ['RS256'], issuer: 'https://auth.example.com', audience: 'https://api.example.com' }); console.log(payload); } catch (err) { console.error('Invalid token', err); } ```

OAuth 2.0 deep dive

Purpose: delegated authorization — let a third-party client access resources on behalf of the user.

Primary endpoints:

  • Authorization endpoint: user-agent redirect for user consent and auth.
  • Token endpoint: exchange authorization code (or credentials) for tokens.
  • (Optional) Revocation and introspection endpoints.

Main grant types (flows)

  • Authorization Code (with PKCE): recommended for web & mobile apps. Server-side or public clients get a code then exchange it for tokens.
  • Implicit: older pattern for single-page apps returning tokens directly; largely deprecated due to security concerns.
  • Client Credentials: machine-to-machine; client acts on its own behalf (no user).
  • Resource Owner Password Credentials: deprecated/avoid — app collects user credentials directly.
  • Device Authorization (device code): for input-constrained devices.
  • Refresh Token: refresh access tokens without re-prompting the user.

Important: PKCE (Proof Key for Code Exchange)

  • Protects authorization code flow for public clients (mobile, SPAs) from code interception.
  • Client generates codeverifier and codechallenge sent to auth endpoint; token exchange requires the code_verifier.

Token types:

  • Access tokens: may be JWT or opaque strings — used at resource servers.
  • Refresh tokens: usually opaque and long-lived; used to get new access tokens.

Sequence: Authorization Code flow (simplified)

  1. Client redirects user to Authorization Endpoint with clientid, redirecturi, scope, state, code_challenge.
  2. User authenticates and consents.
  3. Auth server redirects back with code and state.
  4. Client sends code + code_verifier to Token Endpoint.
  5. Server returns accesstoken (and maybe refreshtoken).

Curl example: exchange code for tokens (sketch) ``bash curl -X POST https://auth.example.com/oauth/token \ -H "Content-Type: application/x-www-form-urlencoded" \ -d "granttype=authorizationcode&code=AUTHCODE&redirecturi=https://app.example.com/cb&clientid=CLIENTID&codeverifier=CODEVERIFIER" ``

OpenID Connect deep dive

What OIDC adds:

  • ID Token: JWT that contains identity claims about the authenticated user (sub, iss, aud, exp, iat, nonce...). It's intended for the client (Relying Party).
  • Well-Known Discovery: /.well-known/openid-configuration gives endpoints, supported features, JWK URI.
  • UserInfo Endpoint: returns additional claims about the user (profile, email) using the access_token.
  • Standard scopes: openid (required to do OIDC), profile, email, address, phone, offline_access (request refresh token).
  • Nonce: used to mitigate replay attacks against the ID token — client sends nonce during authorization request and validates it matches ID token claim.

Typical OIDC flow:

  • Same as OAuth2 Authorization Code flow, but include scope=openid (and optionally profile,email).
  • Token response includes idtoken (JWT) + accesstoken.
  • Client validates id_token (signature, issuer, audience, exp, nonce).

ID token example payload: `` { "iss": "https://auth.example.com", "sub": "user-123", "aud": "client-abc", "exp": 1618887999, "iat": 1618884399, "nonce": "n-0S6WzA2Mj", "email": "[email protected]", "emailverified": true } ``

Discovery example (curl) ```bash curl https://auth.example.com/.well-known/openid-configuration

returns JSON with issuer, authorizationendpoint, tokenendpoint, jwksuri, userinfoendpoint...

```

Key OIDC validations:

  • Validate signature (using JWKs from jwks_uri).
  • Validate iss, aud, exp, iat.
  • Verify nonce (for code flow with id_token).
  • If access token is used at userinfo endpoint, it must be sent securely.

Comparing JWT vs OAuth2 vs OIDC — short decision guide

  • Need to ...

Ready to see the full tree?

Clone the preview to open the complete learning structure, practice tools, and generated study materials.