OAuth 2.0 and JWT Explained: How "Login with Google" Actually Works

OpenID Connect: The Identity Layer on Top of OAuth

OIDC standardizes exactly the piece OAuth deliberately leaves undefined: how a client learns, in a verifiable and interoperable way, who just authenticated. It adds three things on top of plain OAuth 2.0:

1. The openid scope, which signals to the authorization server that this request wants identity information, not just API access.
2. The ID token — a JWT, always, containing standardized identity claims (sub, email, name, email_verified, and others) that your application decodes and validates using the same rules covered earlier in this reference.
3. A standardized UserInfo endpoint and discovery document (/.well-known/openid-configuration) so any OIDC-compliant client can find an issuer's endpoints and public keys without provider-specific configuration.

// A decoded ID token payload — this is the piece plain OAuth never defined
{
  "iss": "https://accounts.google.com",
  "sub": "110169484474386276334",
  "aud": "your-client-id",
  "email": "user@example.com",
  "email_verified": true,
  "name": "Alice Example",
  "exp": 1710003600,
  "iat": 1710000000
}

Before OIDC existed, every identity provider (Google, Facebook, Twitter) had invented its own bespoke way of layering "who is this user" on top of plain OAuth, and every client library needed provider-specific code to handle each one. OIDC is precisely the standardization that made "Login with X" buttons for a dozen different providers a solved, largely interchangeable problem instead of a dozen separate integrations.