OpenID Connect (OIDC): Authentication as a Service

WHY IT EXISTS: Building and maintaining your own secure login system is complex, risky, and distracts from your core product. OIDC was created to eliminate the need for every website to manage its own password database, improving security and user experience by letting users log in with a single, trusted identity they already have.

THE MENTAL MODEL: Think of OIDC like a digital passport check at an airport. Your application (the airline) doesn't issue the passport or verify the person's life story. It just trusts the government that issued it (the Identity Provider, like Google or Okta). The ID Token is the passport itself—a verifiable, tamper-proof proof of identity that your app can inspect to confirm who the user is.

HOW IT WORKS: OIDC is a thin identity layer built on top of the OAuth 2.0 protocol. When a user wants to log in, your app redirects them to an Identity Provider (IdP). After the user authenticates with the IdP, the IdP sends back an ID Token, which is a JSON Web Token (JWT). Your application validates the ID Token's digital signature to confirm the user's identity. The app can then establish a session for that user without ever seeing their password.

WHEN TO USE IT: Use OIDC whenever you need to verify a user's identity before granting them access to your application. It's the modern standard for implementing "Sign in with X" functionality on consumer websites and for enabling Single Sign-On (SSO) in enterprise environments, where an employee logs in once to access multiple internal applications.

WHEN NOT TO USE IT: Don't use OIDC if you only need authorization without authentication. If an application simply needs permission to access an API on behalf of a user (e.g., a script that posts to your social media feed), plain OAuth 2.0 is sufficient. OIDC is specifically for logging a user in and verifying their identity.

ONE CANONICAL EXAMPLE: A user clicks "Log in with Google" on your web app. The app redirects them to Google's login page. The user enters their Google credentials. Google then redirects them back to your app with an ID Token in the URL. Your app's backend verifies the token's signature using Google's public key, extracts the user's email and name from the token's payload, and creates a session for them.