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.

JIT provisioning vs SCIM

Just-in-time provisioning creates the user's account in the target app the moment they first sign in via SAML, using the attributes carried in the SAML assertion (name, email, department) to populate the new record — no separate provisioning step needed before the user's first sign-in. It's simple and requires no extra configuration beyond the SAML integration itself, but it's also a one-way, sign-in-triggered operation: JIT only fires on sign-in, so it doesn't proactively deprovision an account when someone leaves, doesn't push attribute updates on a schedule, and won't create the record ahead of time for an app that needs pre-provisioning (a seat reserved before day one, say). SCIM provisioning is the fuller alternative — Entra ID actively pushes create, update, and deactivate events to the app on its own schedule (typically every 20–40 minutes) based on group membership or assignment, independent of whether the user has signed in at all. For apps that support both, the two aren't mutually exclusive: some organisations use JIT purely to get an account into existence at first login, with SCIM handling the ongoing lifecycle — attribute sync and, critically, deprovisioning when access is unassigned — afterward. Apps that only support JIT and not SCIM need a separate, deliberate offboarding process, since nothing will automatically deactivate the account when the person leaves.

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