What Is OAuth 2.0? OAuth, OpenID Connect, JWT, and SSO Explained

OAuth 2.0 is an open authorisation framework that lets a user grant a third-party application limited access to their resources on another service — without sharing their password. It is the standard behind "Sign in with Google", "Connect with GitHub", and nearly all modern API integrations.

OpenID Connect (OIDC) is a thin identity layer built on top of OAuth 2.0 that adds authentication — proving who the user is, not just what they can access.

OAuth vs OpenID Connect vs SAML

| | OAuth 2.0 | OpenID Connect (OIDC) | SAML | |---|---|---|---| | Purpose | Authorisation (access delegation) | Authentication + authorisation | Authentication (enterprise SSO) | | Token format | Opaque or JWT | JWT (ID token) | XML assertions | | Use case | API access, mobile apps | Consumer login ("Sign in with X") | Enterprise SSO (Okta, Azure AD) | | Complexity | Moderate | Moderate | High |

Key Roles in OAuth 2.0

| Role | Description | Example | |---|---|---| | Resource Owner | The user who owns the data | You | | Client | The app requesting access | A fitness app | | Authorisation Server | Issues tokens after authenticating the user | Google, Azure AD | | Resource Server | Hosts the protected resources | Google Calendar API |

The Authorisation Code Flow (Most Common)

Used by server-side web apps. The most secure OAuth 2.0 flow:

1. User clicks "Sign in with Google" on the client app
2. Client redirects user to Google's authorisation server:
   GET /authorize?response_type=code&client_id=...&redirect_uri=...&scope=email profile&state=xyz

3. User authenticates and consents on Google's page
4. Google redirects back to the client with an authorisation code:
   GET /callback?code=AUTH_CODE&state=xyz

5. Client exchanges the code for tokens (server-to-server):
   POST /token
   grant_type=authorization_code&code=AUTH_CODE&client_id=...&client_secret=...

6. Authorisation server returns:
   { access_token, refresh_token, id_token, expires_in }

7. Client uses access_token to call Google APIs on the user's behalf

The authorisation code is short-lived and single-use. The actual tokens are exchanged server-to-server, keeping them out of the browser URL bar.

PKCE: Protecting Public Clients

For mobile apps and SPAs (which cannot securely store a client secret), PKCE (Proof Key for Code Exchange) is added to the authorisation code flow:

1. Client generates a random code_verifier
2. Client hashes it: code_challenge = SHA256(code_verifier)
3. code_challenge is sent in the initial authorisation request
4. When exchanging the code for tokens, the client sends the original code_verifier
5. The server verifies the hash-cryptographic-hash-functions-explained) matches — confirming the same client that started the flow is completing it

PKCE prevents authorisation code interception attacks without requiring a client secret.

The Four OAuth 2.0 Grant Types

| Grant Type | Use case | Security level | |---|---|---| | Authorisation Code | Server-side apps | Highest | | Authorisation Code + PKCE | Mobile apps, SPAs | Highest for public clients | | Client Credentials | Machine-to-machine (no user) | High | | Device Code | Smart TVs, CLI tools | Moderate | | ~~Implicit~~ | SPAs (deprecated) | Low — avoid |

The implicit flow (which returned tokens directly in the URL) is deprecated. Use Authorisation Code + PKCE for all browser and mobile apps.

Tokens Explained

Access Token

A credential that grants access to protected resources. The resource server validates it on every API call. Usually short-lived (minutes to hours). Can be opaque (a random string the server looks up) or a JWT.

Refresh Token

A long-lived credential used to obtain a new access token without re-authenticating. Stored securely by the client. Must be revocable by the authorisation server.

ID Token (OIDC only)

A JWT that contains claims about the authenticated user (email, name, subject identifier). Used by the client to know who the user is. Never sent to APIs.

JSON Web Tokens (JWT)

A JWT is a compact, URL-safe token format used for access and ID tokens. It has three base64url-encoded parts separated by dots:

header.payload.signature
eyJhbGciOiJSUzI1NiJ9.eyJzdWIiOiJ1c2VyMTIzIiwiZXhwIjoxNjk5OTk5OTk5fQ.SIGNATURE

• Header: Algorithm and token type ({"alg":"RS256","typ":"JWT"})
• Payload: Claims — sub (subject/user ID), exp (expiry), iss (issuer), aud (audience), plus custom claims
• Signature: Cryptographic signature verifying the token has not been tampered with

Common JWT security mistakes:

• Accepting alg: none (no signature) — always validate the algorithm
• Not validating exp, iss, or aud claims
• Storing JWTs in localStorage (accessible to JavaScript) — prefer HttpOnly cookies

Single Sign-On (SSO)

SSO lets users authenticate once and access multiple applications without re-entering credentials. OAuth 2.0 / OIDC powers consumer SSO ("Sign in with Google"). SAML powers enterprise SSO (Okta, Azure AD, Google Workspace).

How OIDC-based SSO works:

1. User signs into the Identity Provider (IdP) once
2. When accessing any connected application, the app checks with the IdP
3. IdP returns an ID token confirming the user is already authenticated
4. User is logged in — no password prompt

OAuth Security Risks

| Risk | Description | Mitigation | |---|---|---| | Open redirectors | redirect_uri not strictly validated | Whitelist exact redirect URIs | | State parameter missing | CSRF attack on the OAuth flow | Always use and validate state | | Token leakage | Access token in URL or logs | Use code flow; avoid implicit | | Overly broad scopes | Requesting more permissions than needed | Request minimum necessary scopes | | Insecure token storage | Tokens in localStorage | Use HttpOnly cookies or secure storage |

Key Takeaways

• OAuth 2.0 is for authorisation (access delegation); OpenID Connect adds authentication
• The Authorisation Code flow is the most secure; always add PKCE for public clients
• Access tokens grant API access; ID tokens identify the user; refresh tokens renew access
• JWTs are self-contained tokens — always validate the signature, expiry, issuer, and audience
• SSO lets users authenticate once across multiple applications via a central Identity Provider