02. Why OpenID

 

Why do we need OpenID Connect (OIDC) on top of OAuth 2.0 to get user information? Why didn’t OAuth 2.0 itself handle user authentication and profile fetching (like email)? Couldn’t OAuth have just added its own variables/scopes to support it? 

OAuth 2.0 was never designed for authentication, only authorization.So, OAuth doesn’t define how to return user identity in a secure, standard way.

That's mean:

• No standard for id_token (JWT),
• No standard for /userinfo endpoint.

 But If we want, we can build our own identity solution on OAuth alone (to get user information), but:

• There would be no standard token format,
• No standard way to verify the user's identity,
• High risk of doing it wrong (and creating security holes).

That’s why OpenID Connect exists — to make authentication safe, easy, and interoperable.

 OpenID Connect was created to safely and consistently add authentication and user identity on top of OAuth.

 OpenID handle:

1. Standardized id_token Format (JWT)

OIDC introduces the id_token — a JSON Web Token (JWT) with a defined structure.

This token:

• Contains who the user is (sub, name, email, etc.).
• Is digitally signed by the identity provider (e.g., Google, Cognito, Keycloak).
• Can be verified by your backend using the provider’s public keys (via JWKS URI).

 

2. Standard Scopes and Claims

OIDC uses specific, standardized scopes like:

• openid → enables OIDC
• profile → name, birthdate, etc.
• email → email address

 And standardized claims in the id_token, like:

• sub (user ID)
• email
• name
• iss (issuer)
• aud (audience)

 We get predictable fields, no matter who the provider is. 

3. Defined User Info Endpoint 

The /userinfo endpoint is created and exposed by the Identity Provider (IdP) — that means the authentication server that implements OpenID Connect (OIDC), such as: Google, AWS Cognito, Keycloak

/userinfo endpoint - It’s not something you create manually — it's automatically provided by any OIDC-compliant Identity Provider. 

When your app is integrated with an Identity Provider using OIDC, the provider gives you a well-known configuration URL, like this: https://accounts.google.com/.well-known/openid-configuration

This config URL returns a JSON like:

{

  "issuer": "https://accounts.google.com",

  "authorization_endpoint": "https://accounts.google.com/o/oauth2/v2/auth",

  "token_endpoint": "https://oauth2.googleapis.com/token",

  "userinfo_endpoint": "https://openidconnect.googleapis.com/v1/userinfo",

  ...

}

 

The `userinfo_endpoint` is listed there — this is where your app can make a request (with a valid access token) to fetch the user’s profile.

 

1. User logs in through OIDC flow.

2. Your app gets an access token (and maybe an `id_token`).

3. You call the `/userinfo` endpoint with: 

   GET /userinfo

   Authorization: Bearer <access_token> 

4. The identity provider returns a JSON response like:

   {

     "sub": "1234567890",

     "name": "John Doe",

     "email": "john@example.com",

     "picture": "https://example.com/photo.jpg"

   }