OAuth 2.0 and OpenID Connect (OIDC)
OAuth 2.0 and OpenID Connect (OIDC) are the industry standards for handling authorization and authentication in modern applications. While often used together, they solve different problems.
1. OAuth 2.0 (Authorization)
OAuth 2.0 is an authorization framework. It allows a third-party application (Client) to obtain limited access to an HTTP service (Resource Server) on behalf of a resource owner.
- Analogy: A "Valet Key" for your car. It lets the valet drive the car (limited access) but doesn't let them open the trunk or sell the car. It also doesn't tell the valet who you are.
Key Roles
- Resource Owner: The user who owns the data (You).
- Client: The application requesting access (e.g., a mobile app).
- Authorization Server: The server that issues tokens (e.g., Google, Auth0).
- Resource Server: The API hosting the data (e.g., Google Drive API).
Tokens
- Access Token: A credential used to access protected resources. Often a JWT (JSON Web Token) or an opaque string. Short-lived.
- Refresh Token: A credential used to obtain a new Access Token when the current one expires. Long-lived.
Common Grant Types (Flows)
- Authorization Code Flow: The most secure flow for server-side apps. The client exchanges a code for a token.
- Client Credentials Flow: Machine-to-machine communication (no user involved).
- PKCE (Proof Key for Code Exchange): An extension to the Authorization Code flow, mandatory for mobile and single-page apps (SPAs) to prevent code interception.
2. OpenID Connect (Authentication)
OpenID Connect (OIDC) is an identity layer built on top of OAuth 2.0. It allows Clients to verify the identity of the End-User based on the authentication performed by an Authorization Server.
- Analogy: An ID badge. It proves who you are.
The ID Token
The core of OIDC is the ID Token. It is a JWT (JSON Web Token) that contains claims about the authenticated user.
sub(Subject): Unique user ID.iss(Issuer): Who issued the token.aud(Audience): Who the token is for (Client ID).exp(Expiration): When it expires.name,email,picture: User profile data.
3. OAuth vs. OIDC
| Feature | OAuth 2.0 | OpenID Connect (OIDC) |
|---|---|---|
| Purpose | Authorization (Access) | Authentication (Identity) |
| Question | "What can this app do?" | "Who is this user?" |
| Token | Access Token | ID Token |
| Analogy | Valet Key | ID Card |
4. Typical Flow (OIDC + OAuth)
- User clicks "Login with Google".
- Redirect: App redirects user to Google's authorization server.
- Login: User logs in to Google and consents ("Allow App to view profile").
- Callback: Google redirects back to App with an
authorization_code. - Exchange: App sends the code + client secret to Google (backend channel).
- Response: Google returns:
access_token: To call Google APIs.id_token: To know who the user is.refresh_token: To stay logged in.
5. JWT (JSON Web Token) Structure
A JWT is a compact, URL-safe means of representing claims to be transferred between two parties. It consists of three parts separated by dots (.): Header.Payload.Signature.
1. Header
Contains metadata about the token, such as the signing algorithm.
{
"alg": "HS256",
"typ": "JWT"
}2. Payload
Contains the claims (statements about an entity and additional data).
- Registered Claims: Predefined claims like
iss(issuer),exp(expiration),sub(subject). - Public/Private Claims: Custom data like
role: "admin"oremail.
3. Signature
Used to verify that the sender of the JWT is who it says it is and to ensure that the message wasn't changed along the way.
- It is created by taking the encoded header, the encoded payload, a secret, and the algorithm specified in the header.
HMACSHA256(
base64UrlEncode(header) + "." +
base64UrlEncode(payload),
secret)programming/rest-apis programming/web-security programming/cybersecurity-basics