OpenID Connect (OIDC) is an identity layer built on top of OAuth 2.0 that lets an application securely verify who a user is and obtain basic profile information. Where OAuth alone answers "may this app access that resource?", OIDC answers the question OAuth was never designed for: "who is this person?" It is the standard that powers "Sign in with…" buttons across the web. When you use one account to log in to a different service, OIDC is almost always the machinery underneath, handing the application a trustworthy statement about your identity in the form of an ID token.
Why It Matters
OAuth 2.0 became the backbone of delegated access, but developers kept trying to use it for something it did not do well: logging users in. Because OAuth's tokens were about authorization, not identity, home-grown "login with OAuth" schemes were inconsistent and sometimes insecure — an access token proves an app can reach some data, not that the person in front of it is who they claim to be. OIDC was created to close that gap with a single, interoperable standard.
The payoff is significant. Users get to reuse one trusted account instead of creating and remembering yet another password, which reduces password reuse and fatigue. Applications get to offload the hard, risky work of storing credentials and verifying identity to a dedicated identity provider that specializes in it. And because OIDC is a formal standard, any compliant application can work with any compliant identity provider, making it a cornerstone of modern single sign-on. Fewer passwords stored in fewer places means a smaller attack surface for everyone.
A Simple Analogy: A Notarized Letter
Think of OIDC like a notarized letter of introduction. OAuth is the process of a trusted office agreeing to act on your behalf. OIDC adds a notary who signs a sealed letter stating "we have verified this is Jordan, here is their email, and we confirmed it just now." The receiving business does not need to interrogate you itself — it trusts the notary's seal. The ID token is that sealed, signed letter: the application reads it, checks the signature, and confidently knows who you are without ever handling your password.
How It Works
OIDC extends the familiar OAuth flow by adding an ID token alongside the access token. A simplified sign-in looks like this:
1. App sends you to the identity provider with scope "openid"
2. You authenticate there (password, MFA, etc.)
3. You consent to sharing your identity/profile
4. Provider returns an ID token (plus an access token)
5. App verifies the ID token's signature and its claims
6. App now knows who you are and can start a logged-in session
The ID token is a JWT — a compact, digitally signed token — carrying claims about you, such as a unique user identifier, your email, and when you authenticated. Because it is signed by the identity provider, the application can verify it has not been tampered with. There is also a UserInfo endpoint the app can call with its access token to fetch additional profile details. The critical discipline is that the application must validate the ID token — checking the signature, the intended audience, and the expiry — rather than trusting it blindly.
Key Things to Know
The relationship between OAuth and OIDC trips many people up:
| Aspect | OAuth 2.0 | OpenID Connect |
|---|---|---|
| Primary purpose | Authorization (access) | Authentication (identity) |
| Key token | Access token | ID token (plus access token) |
| Answers | "May this app do X?" | "Who is this user?" |
| Relationship | The foundation | A layer built on top |
The most important takeaway is that OIDC does not replace OAuth — it extends it. OAuth handles the delegated-access plumbing; OIDC adds the standardized identity statement on top. If you need to log a user in, OIDC is the right tool. If you only need to access a resource on their behalf, OAuth alone may suffice.
How Safeguard Helps
OIDC is implemented through open-source identity libraries that handle the delicate work of validating ID tokens, verifying signatures, and checking claims. A flaw in that validation logic — accepting an unsigned token, skipping the audience check — can let an attacker forge an identity, which is among the most severe kinds of security bug. Safeguard's software composition analysis inventories the OIDC and JWT libraries in your project and flags any with known vulnerabilities before they become a way in.
Because a plain list of findings is hard to prioritize, Griffin AI surfaces the flaws that actually affect code your application runs and explains them in plain language. To explore the connected ideas — OAuth, JWTs, and single sign-on — the concepts library lays them out simply. To see your own dependencies analyzed, create a free account, or build the fundamentals in Safeguard Academy.
Frequently Asked Questions
How is OpenID Connect different from OAuth 2.0?
OAuth 2.0 handles authorization — granting an app delegated access to resources — while OpenID Connect adds authentication, telling the app who the user is. OIDC is built on top of OAuth and introduces the ID token, a signed statement of identity. In short, OAuth answers "may this app do something," and OIDC answers "who is this person."
What is an ID token?
An ID token is a signed JSON Web Token issued by an identity provider that contains claims about the authenticated user, such as a unique identifier and email address. The application verifies the token's signature and claims to confirm who the user is. Unlike an access token, the ID token exists specifically to convey identity to the application itself.
Is OpenID Connect the same as single sign-on?
Not exactly. OIDC is a protocol; single sign-on is the experience of logging in once and accessing many applications. OIDC is one of the main standards used to implement single sign-on, but SSO is a broader concept that can also be built with other protocols such as SAML. OIDC is a common way to achieve SSO, not a synonym for it.
Why must an application validate the ID token?
Because an unvalidated token can be forged or tampered with, letting an attacker impersonate any user. Proper validation checks the provider's signature, confirms the token was intended for this specific application, and verifies it has not expired. Skipping these checks is a serious and well-documented vulnerability, which is why reputable libraries perform them by default.