SAML SSO with Entra ID

SAML 2.0 is one of the two main standards (along with OpenID Connect / OAuth 2.0) for federated single sign-on between identity providers and applications. Microsoft Entra ID acts as a SAML identity provider for thousands of SaaS apps. Knowing the moving parts saves a lot of debugging.

The SAML flow

When a user signs into a SAML-enabled app:

1. User clicks Sign in in the app.
2. The app redirects the browser to Entra ID's SAML sign-in URL, with a request for an assertion.
3. Entra ID authenticates the user (password, MFA, Conditional Access).
4. Entra ID generates a SAML assertion — an XML document with claims about the user — signed with Entra's private key.
5. The browser POSTs the assertion back to the app's Assertion Consumer Service (ACS) URL.
6. The app validates the signature using Entra's public key, reads the claims, creates a session.

The user sees a single-sign-on experience; under the hood, two redirects and an XML POST happened.

Setting it up in Entra ID

For each SAML app, you create an Enterprise application in Entra ID (either from the gallery or as a non-gallery app), then configure Single sign-on → SAML:

1. Identifier (Entity ID) — a URI provided by the app, identifying the app to Entra.
2. Reply URL (ACS URL) — where Entra POSTs the assertion.
3. Sign-on URL — optional, where users go for IdP-initiated SSO.
4. User attributes & claims — what claims to include in the assertion (email, name, groups, custom fields).
5. SAML signing certificate — Entra's certificate that the app uses to verify assertions. Download and upload to the app.
6. Login URL / Logout URL — what Entra exposes for the app to redirect to.

Once configured, assign users / groups to the application — only assigned identities can SSO in.

Common pitfalls

• Clock skew — SAML assertions have validity windows. If the app's clock is significantly off, assertions fail.
• NameID format mismatches — the app expects a specific identifier format (email, UPN, custom); Entra needs to send it correctly.
• Required claims missing — the app needs a claim Entra isn't sending; configure attribute mappings.
• Certificate rotation — Entra signing certs have expiration dates; rotate them deliberately with the app's awareness.
• SP-initiated vs IdP-initiated — apps may support only one; understand which flow the app expects.

SAML vs OIDC

For modern apps, OpenID Connect (OIDC) / OAuth 2.0 is increasingly the right choice over SAML:

• OIDC uses JSON over HTTPS (cleaner than XML).
• OIDC is mobile and SPA-friendly out of the box.
• OIDC scopes are richer for API access.
• SAML is still ubiquitous for legacy enterprise SaaS.

Most SaaS vendors support both. Pick OIDC for new integrations where available; SAML for legacy apps that require it.

Operational considerations

• Conditional Access policies apply to SAML sign-ins — gate the app by MFA, device compliance, location.
• Audit logs in Entra show every SAML sign-in attempt and result.
• Just-in-time (JIT) provisioning lets some apps auto-create user records on first SAML sign-in; for others, pair SAML with SCIM provisioning.

SAML is mature, well-understood, and unlikely to disappear — but it's not where Microsoft or modern SaaS vendors are investing for new features.