What is OpenID Connect (OIDC) and How It Extends OAuth 2.0 for Authentication

Overview of OAuth 2.0

OAuth 2.0 is a delegation framework that lets a third‑party application obtain limited access to a user’s resources on another service (e.g., read a profile, post a photo). - Actors: Resource Owner (the user), Client (the app), Authorization Server, and Resource Server. - Tokens: Access tokens (bearer tokens) are used to call protected APIs. - Flows: Authorization Code, Implicit, Resource Owner Password Credentials, Client Credentials.

OAuth 2.0 is authorization‑focused; it does not define how to prove who the user is.

Limitations of OAuth 2.0 for Authentication

1. No identity data – Access tokens are opaque or JWTs that contain only scopes, not user details.
2. No standard user info – The client must ask the resource server for profile data, which may be inconsistent.
3. No built‑in session handling – The client must manage login state itself.

Because of these gaps, building a reliable login experience with only OAuth 2.0 requires extra hacks.

Introducing OpenID Connect

OpenID Connect (OIDC) is a thin identity layer on top of OAuth 2.0. It defines: - ID Token – a signed JWT that the client can trust to know who the user is. - UserInfo endpoint – optional REST API that returns additional profile attributes. - openid scope – signals that the request is for authentication, not just authorization.

In short, OIDC lets the client authenticate the user while still using OAuth 2.0 for authorization.

How OIDC Works – The Flow

Below is a simplified sequence for the most common Authorization Code Flow with PKCE:

1. Client redirects the user’s browser to the Authorization Server with response_type=code, scope=openid profile email, and a PKCE code verifier.
2. The Authorization Server prompts the user to log in (if needed) and then redirects back to the client with an authorization code.
3. The client exchanges the code for tokens at the Token Endpoint (access token, refresh token, ID token, optionally refresh token).
4. The client verifies the ID token’s signature (using the server’s JWKS) and decodes the JWT payload to obtain the user’s sub (unique identifier), name, email, etc.
5. If more data is required, the client calls the UserInfo endpoint with the access token.

+--------+                                +-----------------+
|  Browser|   1. Redirect to Auth Server   | Authorization   |
| (User)  +----------------------------->+  Server         |
+--------+                                +-----------------+
                                   | 2. Login (if needed)
                                   v
+--------+   3. Redirect with code   +-----------------+
| Client | <---------------------------- +               |
| (App)  +                               | 4. Token Exchange|
+--------+   5. Verify ID Token      +-----------------+

Core Components

• ID Token – a JWT (header.payload.signature). The payload contains claims such as sub (subject), email, name, and exp (expiration).
• openid scope – must be present; without it the server treats the request as authorization‑only.
• UserInfo endpoint – GET /userinfo (or /openid-connect/userinfo) returns additional claims when the client needs more detail than the ID token provides.
• JWKS – JSON Web Key Set URL provided by the authorization server (/.well-known/jwks.json). The client downloads the public keys to verify the ID token signature.

Real‑World Example: Login with Google

Google’s OAuth 2.0 endpoints are also OIDC‑compatible. Here’s a step‑by‑step walkthrough:

1. Redirect URL (client): https://myapp.com/auth/callback
2. Authorization request (browser): GET https://accounts.google.com/o/oauth2/v2/auth? response_type=code& client_id=123456789-abc.apps.googleusercontent.com& redirect_uri=https%3A%2F%2Fmyapp.com%2Fauth%2Fcallback& scope=openid email profile& state=RANDOM_STRING& code_challenge=XYZ& code_challenge_method=S256
3. Google authenticates the user, shows the consent screen, and redirects back with a code and state.
4. Token exchange (client): ```python import requests

token_url = "https://oauth2.googleapis.com/token" data = { "code": auth_code, "client_id": "123456789-abc.apps.googleusercontent.com", "client_secret": "MY_SECRET", "redirect_uri": "https://myapp.com/auth/callback", "grant_type": "authorization_code" } response = requests.post(token_url, data=data) tokens = response.json() # contains id_token, access_token, refresh_token 5. **Verify the ID token** (using `pyjwt`):python import jwt import requests

# Fetch Google's JWKS jwks = requests.get("https://www.googleapis.com/oauth2/v3/certs").json() # Decode without verification first to inspect unverified = jwt.decode(tokens["id_token"], options={"verify_signature": False}) print(unverified) # shows sub, email, name, exp, iat, etc.

# Get the correct key from JWKS and verify key = jwt.algorithms.RSAAlgorithm.RS256(jwks["keys"][0]["e"], jwks["keys"][0]["n"]) decoded = jwt.decode(tokens["id_token"], key, algorithms=["RS256"]) print(decoded["sub"]) # unique Google user ID print(decoded["email"]) `` 6. **Create a session** in your app using thesub` claim as the stable identifier.

Benefits of OIDC

• Standardized authentication – No need to implement password handling or session cookies yourself.
• Stateless tokens – The ID token is self‑contained; the server can verify it without a database lookup.
• Single Sign‑On (SSO) – Multiple apps can use the same provider (e.g., Azure AD, Okta) and share the same user session.
• Secure by design – Tokens are signed, optionally encrypted, and have short lifetimes.

Common Pitfalls

• Skipping signature verification – Accepting an ID token without checking the signature opens the door to forged identities.
• Relying solely on the access token – The access token may not contain user info; always use the ID token or UserInfo endpoint.
• Ignoring token expiration – Tokens can become invalid; implement refresh logic or re‑authenticate when needed.
• Not handling revocation – If a user logs out, the refresh token may still be usable; use the provider’s revocation endpoint or short‑lived tokens.

Summary

OpenID Connect extends OAuth 2.0 by adding an ID token and a UserInfo endpoint, enabling clients to authenticate users reliably. By requiring the openid scope and returning a signed JWT, OIDC gives developers a standard, secure way to know who the user is while still leveraging OAuth 2.0 for authorization. Real‑world providers like Google, Microsoft, and Auth0 implement OIDC, making it easy to add login functionality to web and mobile apps. Remember to verify token signatures, respect expiration, and use the standard claims (sub, email, name) to maintain a consistent user identity across your applications.