What is the difference between OAuth 2.0 and OpenID Connect?

OAuth 2.0 answers what an application is allowed to do on your behalf. It was built for delegated access, the prompt asking whether an app may see your calendar, and it was never built to answer who the user is. OpenID Connect is a thin identity layer on top of it that adds one thing: a signed identity token, issued by a provider you trust, stating who just logged in. For years teams bent OAuth into a login mechanism anyway and quietly created security weaknesses doing it, and that is the gap OpenID Connect closes properly.

Does single sign-on increase or reduce risk?

Both, in different places, which is why the trade is worth making deliberately. When authentication happens inside each application, identity risk is smeared across dozens of systems, each handling passwords differently and each a separate place to get it wrong. Concentrating it at one provider collapses that into a single point of control where you enforce multi-factor authentication once, and because it is one place you can afford to make it phishing resistant. The same concentration is a single point of failure and a very attractive target, because an attacker who phishes one identity does not get into one application, they get into all of them.

What is the most common way an OpenID Connect integration fails?

The application decodes the identity token, reads the name inside, and trusts it without checking the signature, the issuer, or who the token was issued for. This is the cardinal sin, because it lets an attacker present a forged or replayed token and be believed. A token that is decoded but not verified is not proof of anything, it is a claim. Every login you federate depends on the receiving application verifying what it receives.

Where should identity tokens be stored?

In storage that scripts cannot reach. Tokens placed in browser local storage are readable by JavaScript, so a single cross-site scripting bug hands an attacker the tokens and every session they open. This is worth asking about directly, because it is an implementation choice engineers can make silently and it changes nothing a user or a functional test would ever notice.

OpenID Connect: What a CISO Actually Needs to Know

Q: What happens if the identity provider is unavailable?

Everything that depends on it stops, which is the benign version of concentration risk and the one you can prepare for. The preparations are unglamorous and have to exist before you need them: break-glass accounts that reach critical systems without the provider, a fallback you have written down, and a recovery-time expectation agreed with the vendor and actually tested rather than assumed. An identity provider sits on the critical path of every login you run, which makes it a critical vendor rather than only an architecture decision.

OpenID Connect gives you one place to enforce security, and one place to lose it. Every login in the company comes to depend on a single provider: nothing is breached the day it stops answering, and nothing is reachable either.

That trade is worth understanding before you decide how much of the business to route through it.

What OpenID Connect actually is

OpenID Connect (OIDC) is a thin identity layer built on top of OAuth 2.0. The distinction sounds academic and is not. OAuth answers one question: what is this application allowed to do on your behalf? It was built for delegated access, the “allow this app to see your calendar” prompt. It was never built to answer the question every login actually asks, which is: who is this user?

For years, teams bent OAuth into a login mechanism anyway, quietly creating security weaknesses. OpenID Connect closes the gap properly. It adds one thing: a signed identity token, issued by a provider you trust, stating who just logged in. That token is the whole idea. Everything else is machinery to make that statement trustworthy.

Why identity concentration lands on your desk

Federated login is usually sold to you as convenience, and the convenience is real. But the reason it belongs on a CISO’s desk rather than an architect’s is that it changes where your identity risk lives. It concentrates it.

When authentication happens in each application, your identity risk is smeared across dozens of systems, each handling passwords differently, each a separate place to get it wrong. When authentication happens at one central provider, that mess collapses into a single point of control. You enforce multi-factor authentication once, and because it is one place, you can afford to make it your strongest: phishing-resistant methods like passkeys or hardware keys, backed by conditional access that weighs device and location on every login. Concentrating authentication is what earns you a single, defensible front door. Disable one account and someone’s access disappears everywhere. For most organizations that is a genuine security upgrade, and it is the right call.

The catch is that a single point of control is also a single point of failure, and a single, very attractive target. The Tuesday outage is the benign version: concentrate availability, and one provider’s bad day becomes your bad day. The answer is unglamorous and worth insisting on before you need it: break-glass accounts that can reach critical systems without the provider, a fallback you have written down, and a recovery-time expectation you have agreed with the vendor and actually tested. The hostile version is sharper. An attacker who phishes one identity, or compromises the provider itself, does not get into one application. They get into all of them, which is precisely why that front door has to be phishing-resistant rather than merely present. Your identity provider is now a vendor sitting on the critical path of every login you run, and it belongs in your vendor risk program, not just your architecture diagrams.

None of this is an argument against OpenID Connect. It is an argument for going in with your eyes open about what you have centralized.

How OpenID Connect works, to the depth you need

You do not need to implement this. You need to be able to reason about it, which means understanding three parties and one discipline.

The three parties are the user, the application they are trying to use (in this protocol it is called the relying party, because it relies on someone else to vouch for the user), and the identity provider that does the vouching.

   the user
      │  "who are you?"
      ▼
  application ───── trusts ─────▶ identity provider
 (relying party)   the signed      (Google, Entra ID,
                    token from       Okta, your own)

The flow beneath is more careful than the triangle suggests, and the care is the point. When a user signs in, the application never collects their password: it hands them to the provider, they authenticate there, and the provider returns a signed token asserting who they are. The application verifies that signature against the provider’s public key before it believes a word of the token, and only then creates a session.

The OpenID Connect authorization code flow between the end user, the relying party application, and the identity provider: the login redirect, the single-use code, the back-channel token exchange, the signed ID token, and token validation before a session is created. — The authorization code flow, end to end. Source: Learn Security Management.

Two things in that picture matter most. First, the application never sees the user’s credentials, which is exactly why concentrating logins reduces the number of places a password can leak. Second, the token is trusted only after it is validated. A token that is decoded but not verified is not proof of anything. It is a claim an attacker can forge.

Where OpenID Connect goes wrong

OpenID Connect is secure when its controls are applied, and only then. The failure modes are predictable, and each one turns into an incident on your desk.

The token is never really validated. An application decodes the identity token, reads the name inside, and trusts it, without checking the signature, the issuer, or who the token was issued for. This is the cardinal sin: it lets an attacker present a forged or replayed token and be believed. Every login you federate depends on the receiving application verifying what it receives.
Tokens are stored where scripts can read them. Put tokens in browser local storage and a single cross-site scripting bug hands them to an attacker. Tokens belong in storage that scripts cannot reach.
Scopes are broader than they need to be. Applications can ask for more about your users than they require. Nobody reviews the request, so the app that needed a name ends up holding email, phone, and more. Least privilege applies to identity data too.
The provider becomes the whole attack surface. Concentrate authentication and you concentrate its value to an attacker. Phishing one login, hijacking one session, or weak multi-factor at the provider now has organization-wide reach. The control you centralized is the control an attacker most wants to defeat.
Logout does not travel. Single sign-on makes one login open many doors. Without single sign-out, closing one door leaves the others open, and sessions outlive the moment you thought you ended them.
The front door is left loose. The technical countermeasures against having a login code stolen in transit (exact-match redirect addresses, and a mechanism called PKCE for apps that cannot keep a secret) are cheap and standard. Skipping them is a choice your engineers can make silently.

Questions to ask about OpenID Connect

You will not audit the cryptography yourself. You do not need to. A short list of questions, put to your teams and your vendors, separates an integration that is actually safe from one that merely works:

When an application receives an identity token, does it verify the signature, the issuer, and the intended audience before trusting it, or does it just decode and believe it?
Where do we store tokens, and could a cross-site scripting bug read them?
When we deprovision someone at the provider, how quickly does their access actually end everywhere? Have we watched it happen?
If the provider is unavailable for an hour, what stops working, and have we tested that scenario rather than assumed it?
Which pieces of user information does each application request, and does anyone review those requests?
Do we treat our identity provider as a critical vendor, with the due diligence, contractual assurances, and monitoring that status implies?

If those questions get crisp answers, you have federated identity done well. If they get shrugs, you have a concentration of risk that nobody is watching.

Federated identity does not remove your identity risk. It gathers all of it into one place, and hands you the keys and the liability in the same motion.