SAML and OIDC

A few days ago, a peer asked me a question:

“You often integrate SSO in Entra ID, right? But do you actually know what happens behind the scenes in SAML or OIDC?”

That question made me pause. I knew how to add the application, configure the IdP, exchange certificates, assign roles, and test the login. But if I’m being honest, I hadn’t really thought deeply about how these protocols actually worked once the user clicked “Sign in.”

So I decided to dig in. And here’s what I learned about SAML and OIDC—two of the most widely used Single Sign-On (SSO) protocols.

Why SSO Matters

SSO exists to make life easier: users log in once, and they gain access to multiple apps without typing their password again and again (Microsoft Learn – SSO basics).

In Entra ID, this looks seamless. But underneath that convenience are protocols handling trust, tokens, and identity exchange.

The two most common protocols? SAML (older, XML-based) and OIDC (newer, JSON-based, built on OAuth 2.0).

The High-Level Flow

No matter which protocol you use, the flow has the same main actors:

User – the person trying to log in.
Identity Provider (IdP) – the trusted authority (like Entra ID).
Service Provider (SP) or Relying Party (RP) – the application the user wants to access.

The flow looks like this:

The user requests access to an app.
The app redirects them to the IdP.
The IdP verifies the user and issues a token or assertion.
The app validates it.
The user is logged in.

Simple on the surface, but the details differ between SAML and OIDC.

Deep Dive: SAML

SAML (Security Assertion Markup Language) is XML-based and has been around since the early 2000s. It shines in enterprise environments with legacy apps (Microsoft SAML docs).

The IdP sends an Assertion (in XML) containing who the user is and sometimes their role or group membership.
The Service Provider validates the Assertion using the configured certificate.
If it checks out, the user is authenticated.

Think of it as: “Here’s a signed document proving this person is who they say they are.”

Deep Dive: OIDC

OIDC (OpenID Connect) is the modern cousin. Built on top of OAuth 2.0, it uses JSON Web Tokens (JWTs) (Microsoft OIDC docs).

The IdP issues an ID Token (JWT) after the user signs in.
The token is compact, base64-encoded, and easier for developers to work with.
Apps can also request Access Tokens to call APIs.

Think of it as: “Here’s a lightweight badge with your photo and details, easy for apps and APIs to scan.”

Comparing SAML and OIDC

Here’s a quick side-by-side:

Aspect	SAML	OIDC
Format	XML	JSON (JWT)
Built on	Custom XML protocol	OAuth 2.0
Best suited for	Legacy enterprise web apps	Modern apps, APIs, mobile
Token type	Assertion	ID Token (JWT)
Complexity	Heavy, verbose	Lightweight, developer-friendly

A nice overview of how these protocols compare is also available in Auth0’s Identity Protocols Explained.

The Risks of Mishandling

This is where it gets serious. If you misconfigure or mishandle SSO, the impact is huge: one compromise could open doors to multiple apps.

SAML Risks
- Assertion replay attacks if assertions aren’t time-bound.
- Forgetting to validate digital signatures.
- Poor certificate management.
OIDC Risks
- Treating ID Tokens as proof of authorization (they’re not).
- Not validating signatures, issuers, or expiration times.
- Storing tokens insecurely (e.g., localStorage → XSS risk).
Common Risks
- Weak security at the IdP = compromise everywhere.
- Insecure redirect URIs → attackers hijack sessions.
- Over-permissioned apps trusting SSO blindly.

Many of these pitfalls are also highlighted in the OWASP Authentication Cheat Sheet, which is a must-read if you work with identity.

In other words: SSO doesn’t remove risk, it centralizes it.

Closing Thoughts

That question—“Do you actually know what happens behind the scenes?” was a wake-up call.

Integrating SSO in Entra ID is easy. But understanding what’s going on with SAML and OIDC helps me appreciate both the power and the responsibility that comes with it.

These protocols are the silent backbone of modern authentication. And as identity professionals, it’s not enough to just wire them up. We need to know the risks, validate tokens properly, and configure them securely.

Because when SSO breaks, it’s not just one app at risk.

SAML vs OIDC: What Really Happens Behind the Scenes