OIDC: OAuth's Identity Layer

OAuth 2.0 solved delegation: “How do I let an app access my data without giving it my password?” But it never solved authentication: “How do I know who you actually are?”

That’s where OpenID Connect (OIDC) comes in.

The Problem OAuth Left Open

When you authorize an app via OAuth, you’re granting it permission to act on your behalf. The authorization server confirms you’re you, grants a token, and the app moves on. But here’s the gap: the app doesn’t actually learn who you are. It gets an access token. That token proves the app can access your resources, but it says nothing about your identity.

For many use cases — like a SaaS app that needs to log you in — that’s a problem.

OIDC: A Thin Identity Layer on OAuth

OIDC adds one critical piece to OAuth: an ID token.

When you authenticate via OIDC:

1. You authorize the application (standard OAuth flow)
2. The authorization server issues an access token (as usual) AND an ID token (new)
3. The ID token is a signed JWT containing claims about your identity: your user ID, email, name, groups, whatever the server issues
4. The app verifies the signature, decodes the token, and learns who you are

That’s it. OIDC isn’t a new protocol — it’s OAuth 2.0 plus:

• A standardized ID token format (JWT)
• Standardized identity claims
• A UserInfo endpoint to fetch additional claims if needed

Why This Matters

For enterprises: OIDC is how modern SSO works. Instead of SAML assertions, you get an OAuth-flavored identity proof that’s easier to integrate with modern apps.

For developers: OIDC is simpler to implement than SAML. OAuth libraries you’re already using (google-auth, passport, etc.) add OIDC support with minimal overhead.

For security: The signature on the ID token proves it came from the authorization server. You can’t forge it without the server’s private key.

OIDC in Practice

A typical flow:

1. User clicks “Sign in with Google”
2. Browser redirects to Google’s authorization endpoint
3. User logs in and consents
4. Google redirects back with an authorization code
5. Your app exchanges the code for an access token and an ID token
6. Your app decodes the ID token, extracts sub (subject/user ID), and logs the user in
7. Your app uses the access token to fetch the user’s Google Drive files (if requested)

The ID token answers “who are you?” The access token answers “what can you access?”

OIDC vs SAML: When to Use Each

OIDC:

• Cloud-native, SaaS-first applications
• Modern tech stacks with good OAuth/OIDC libraries
• You want a lighter protocol footprint
• Identity is secondary to delegation (e.g., “sign in with Google” to access a photo app)

SAML:

• Enterprise environments with existing identity infrastructure
• Compliance requirements mandate SAML (healthcare, finance)
• You need strong assertions and detailed control
• Identity is primary, delegation is secondary

Looking Forward

OIDC is becoming the standard for authentication in cloud systems. If you’re building a modern SaaS application, OIDC + OAuth 2.0 is the right choice. If you’re integrating with enterprise customers, you’ll support both OIDC and SAML.

The key insight: OIDC solves the authentication problem OAuth left open. They’re complementary, not competing.