Microsoft Entra ID SAML integration for SaaS apps
How do I set up Microsoft Entra ID SAML SSO for a SaaS application?
In Microsoft Entra ID (formerly Azure AD), you add SAML single sign-on by creating an enterprise application, entering the Identifier (Entity ID) and Reply URL (ACS URL) from your SaaS app, mapping the NameID and claims, configuring the signing certificate or federation metadata, assigning users, and testing the connection. Entra is the SAML 2.0 identity provider (IdP); your SaaS app is the service provider (SP) that consumes the signed assertion. Basic SAML SSO is free on every Entra tier and needs only an admin role.
This is Part 1 of a two-part series. It walks the identity-provider setup path: the protocol basics, prerequisites and licensing, a six-step Zendesk walkthrough, attribute mapping, and certificate rotation. Part 2 continues with SCIM provisioning, security hardening, and troubleshooting, then turns to the part most Entra tutorials skip: what changes when your SaaS has to accept SAML from many customers' Entra tenants at once.
Facts here are current as of June 2026. Anything pricing-sensitive or in preview carries an as-of date, because those change often. Verify them against the vendor's own page before you commit.
Key takeaways:
- Microsoft Entra ID (formerly Azure AD) acts as the SAML 2.0 IdP; your SaaS app is the SP that validates the assertion.
- Basic SAML SSO is free on every Entra tier, including custom non-gallery apps. You only need an admin role. P1/P2 licenses add Conditional Access, group-based assignment, group provisioning, and token encryption.
- The six core steps: create the enterprise app, set Identifier and Reply URL, map the NameID and claims, configure the signing certificate, assign users, and test.
- Entra's signing certificate defaults to 3-year validity; rotate it through an overlapping inactive certificate to avoid downtime.
- A SAML assertion is valid for 70 minutes by default. SP-initiated SSO is preferred over IdP-initiated for security.
- SAML authenticates; SCIM provisions and deprovisions. Use both for the full account lifecycle.
- If your SaaS must accept SAML from many customers' Entra tenants, that's a multi-tenant service-provider problem, covered in Part 2.
What is SAML SSO with Microsoft Entra ID?
SAML 2.0 is an XML standard for exchanging authentication and authorization data between an identity provider and a service provider. It was ratified as an OASIS Standard in 2005 and remains the entrenched enterprise SSO protocol (OASIS Technical Overview). In a Microsoft Entra integration, Entra is the IdP and the SaaS app is the SP (Microsoft Learn: SAML architecture).
The login itself runs as one of two flows. In SP-initiated SSO, the user starts at your app, which sends a SAML AuthnRequest to Entra over an HTTP Redirect; Entra authenticates the user and POSTs a signed Response back to your Assertion Consumer Service (ACS) URL. In IdP-initiated SSO, the user starts from a tile in Entra and Entra POSTs the assertion without a prior request. Entra supports both, and uses HTTP Redirect for the request and HTTP POST for the response (Microsoft Learn: SAML protocol).
Trust between the two parties is cryptographic. Entra signs each assertion with an X.509 certificate, and your app validates that signature against Entra's published certificate or federation metadata. The assertion carries the user's identity in a Subject/NameID plus an AttributeStatement, time-bounds it in a Conditions element, and records how the user authenticated in an AuthnStatement.
Here's a trimmed, representative Entra SAML response. Real assertions are larger and include the XML signature, but this shows the elements an SP reads and validates:
<samlp:Response Version="2.0" IssueInstant="2026-06-04T07:38:15.128Z"
Destination="https://acme.zendesk.com/access/saml" InResponseTo="_req-id-123"
xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol">
<Issuer xmlns="urn:oasis:names:tc:SAML:2.0:assertion">https://sts.windows.net/00000000-0000-0000-0000-000000000000/</Issuer>
<samlp:Status>
<samlp:StatusCode Value="urn:oasis:names:tc:SAML:2.0:status:Success" />
</samlp:Status>
<Assertion Version="2.0" IssueInstant="2026-06-04T07:38:15.128Z"
xmlns="urn:oasis:names:tc:SAML:2.0:assertion">
<Issuer>https://sts.windows.net/00000000-0000-0000-0000-000000000000/</Issuer>
<!-- ds:Signature over this Assertion element belongs here -->
<Subject>
<NameID Format="urn:oasis:names:tc:SAML:2.0:nameid-format:persistent">a1b2c3-opaque-pseudonym</NameID>
<SubjectConfirmation Method="urn:oasis:names:tc:SAML:2.0:cm:bearer">
<SubjectConfirmationData InResponseTo="_req-id-123"
NotOnOrAfter="2026-06-04T07:43:15.128Z"
Recipient="https://acme.zendesk.com/access/saml" />
</SubjectConfirmation>
</Subject>
<Conditions NotBefore="2026-06-04T07:38:15.128Z" NotOnOrAfter="2026-06-04T08:48:15.128Z">
<AudienceRestriction>
<Audience>https://acme.zendesk.com</Audience>
</AudienceRestriction>
</Conditions>
<AttributeStatement>
<Attribute Name="http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress">
<AttributeValue>ada@acme.com</AttributeValue>
</Attribute>
<Attribute Name="http://schemas.microsoft.com/identity/claims/objectidentifier">
<AttributeValue>11111111-2222-3333-4444-555555555555</AttributeValue>
</Attribute>
</AttributeStatement>
<AuthnStatement AuthnInstant="2026-06-04T07:38:10.000Z">
<AuthnContext>
<AuthnContextClassRef>urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport</AuthnContextClassRef>
</AuthnContext>
</AuthnStatement>
</Assertion>
</samlp:Response>Notice the two time windows. The Conditions NotOnOrAfter is exactly 70 minutes after NotBefore, which is Entra's documented assertion validity window (Microsoft Learn: SAML protocol). The shorter SubjectConfirmationData NotOnOrAfter (about 5 minutes) is the bearer window during which the assertion can be presented to the ACS URL. One quirk worth knowing: the sign-in Issuer is https://sts.windows.net/<tenant-id>/, a legacy host string that Entra still emits.
Enterprises require SAML SSO into SaaS apps for three reasons: centralized identity (one corporate login, not a password per app), security and compliance (MFA, Conditional Access, and audit trails enforced in one place), and lifecycle control (access granted and revoked from the directory).
SAML vs. OIDC in Microsoft Entra ID: which to choose
For new application development, use OpenID Connect (OIDC); reach for SAML when you're integrating an existing app that only speaks SAML. That's Microsoft's own guidance, and stating it plainly matters more than the fact that this article targets SAML.
Microsoft writes: "Choose OpenID Connect and OAuth 2.0 if the application you're connecting to supports it" and "Choose SAML whenever possible for existing applications that don't use OpenID Connect or OAuth" (Microsoft Learn: Plan SSO deployment). For greenfield work it's blunter: "For new application development, we recommend using OpenID Connect (OIDC) for authentication" (Microsoft Learn: Authenticate applications and users).
The technical contrast is short. SAML uses signed XML assertions, a mature enterprise feature set, and a metadata-plus-certificate exchange. OIDC uses JSON and JWTs on top of OAuth 2.0, with discovery via a /.well-known/openid-configuration endpoint and key rotation through a JWKS endpoint that removes most manual certificate handling. Entra fully supports both protocols, and Microsoft documents SAML 2.0 as a current, supported SSO protocol with no announced retirement, even as it recommends OIDC for new development (Microsoft Learn: SAML vs. OpenID Connect; Microsoft Learn: Authenticate applications and users).
Key SAML terms and their Microsoft Entra ID equivalents
The single most useful reference for configuring Entra is the mapping between standard SAML vocabulary and the exact labels in the admin center. The first three columns of your setup all live in the Basic SAML Configuration blade.
The values in the bottom three rows are what you copy out of Entra and into your SaaS app. Everything else you type into Entra from your app's requirements.
Prerequisites for configuring Entra ID SAML SSO
You need an Entra admin role, a handful of values from the SaaS app, and a test user. You do not need a premium license for basic SAML SSO.
Admin role. Cloud Application Administrator is the recommended role; it equals Application Administrator minus app-proxy management. For a single app, assigning yourself as the application's owner is the least-privilege option. Both admin roles can add credentials to an app and effectively impersonate it, so treat them as high-privilege, and note that neither grants Conditional Access (that needs the Conditional Access Administrator role) (Microsoft Learn: Delegate app roles).
Values to collect from the SaaS app. The Identifier (Entity ID), the Reply URL (ACS URL), an optional Sign on URL, the expected NameID format, and any required claims. A non-production test user or group to validate against before you roll out to everyone.
Licensing reality check. SSO for enterprise apps is free on every Entra tier. Microsoft states it directly: "SSO for preintegrated enterprise applications is free" (Microsoft Learn: Plan SSO deployment). That sentence names gallery ("preintegrated") apps, but custom non-gallery apps are covered too: the SAML setup guide lists only an admin role as a prerequisite and states that SAML SSO is configurable on "single tenant applications or gallery applications" — and a custom "Create your own application" app is single-tenant (Microsoft Learn: Enable SAML SSO). What needs Entra ID P1 or P2 is the set of features layered on top: Conditional Access, group-based app assignment, automated group provisioning and provisioning logs, and SAML token encryption (Microsoft Learn: Licensing). Automated user provisioning is available on the Free tier.
Choosing an integration approach
Gallery vs. non-gallery (custom) enterprise applications
If your SaaS app is in the Entra application gallery, add it from there: the gallery holds thousands of pre-integrated apps with preconfigured SSO, per-app setup tutorials, and provisioning where supported (Microsoft Learn: Application gallery). If it isn't listed, create a custom app with New application > Create your own application and configure SAML manually.
The trade-off is pre-filled metadata and tested defaults (gallery) versus full manual control (custom). Neither path costs a premium license; custom SAML SSO is a Free-tier feature, exactly like gallery SSO. The only things that push you to P1 or P2 are group-based assignment, Conditional Access, group provisioning, and token encryption.
IdP-initiated vs. SP-initiated SSO
Prefer SP-initiated SSO. It binds the response to the request through the InResponseTo attribute (derived from the AuthnRequest ID) plus RelayState, which gives login-CSRF and replay protection that IdP-initiated flows structurally lack. OWASP's guidance is to not allow IdP-initiated SSO where you can avoid it, because a stolen assertion can be injected into another browser session (OWASP SAML Security Cheat Sheet; Scott Brady).
The honest nuance: many enterprise customers still launch apps from their IdP dashboard, so a well-built SaaS app usually has to support IdP-initiated flows too, just safely (validate InResponseTo when present, enforce short assertion lifetimes, and detect replays).
Step-by-step: configure SAML SSO in Microsoft Entra ID (Zendesk walkthrough)
This walkthrough uses Zendesk as a representative SaaS app. Its URL patterns are clean and consistent, and it has no mandatory SAML attributes, so it shows the flow without edge cases. The same six steps apply to any gallery app; for an app that isn't in the gallery, the Microsoft Entra SAML Toolkit is Microsoft's vendor-neutral test app. Throughout, <subdomain> is your Zendesk subdomain.
The admin center is at entra.microsoft.com. The current top-level navigation is Entra ID > Enterprise apps, not "Azure Active Directory."
Step 1: Create the enterprise application
Go to Entra ID > Enterprise apps > New application, search the gallery for Zendesk, and add it (or choose Create your own application for a non-gallery app). Open the app and select Single sign-on > SAML.
Step 2: Configure Basic SAML Configuration
Select the edit (pencil) icon on the Basic SAML Configuration card and enter Zendesk's values (Microsoft Learn: Zendesk tutorial):
The Identifier tells Entra which app the assertion is for (it becomes the Audience). The Reply URL is where Entra POSTs the response. The Sign on URL is the page that kicks off SP-initiated login.
Two details that save debugging later. A single SAML app can hold a list of up to 256 Reply URLs (handy for separating staging and production, or regional subdomains) (Microsoft Learn: Reply URL). The AssertionConsumerServiceURL in the app's AuthnRequest is optional; when present, Entra honors it and POSTs the response to the Reply URL that exactly matches that literal string (case-sensitive on the path, not a SAML index) (Microsoft Learn: SAML protocol). When no ACS URL is sent — as in IdP-initiated flows, which have no AuthnRequest — Microsoft states the response goes to the first Reply URL in the list (Microsoft Q&A, answered by a Microsoft moderator). A requested URL that isn't in the list throws AADSTS50011 (see troubleshooting).
The Relay State (Optional) field is more useful than its label suggests. RelayState carries the user's intended destination across the round-trip. In SP-initiated SSO the app sends RelayState in its request and Entra echoes the same value back, so the app can route the user to the page they originally asked for. The field on this blade only takes effect for IdP-initiated flows, where it supplies the landing URL (Microsoft Q&A: RelayState). The SAML spec caps RelayState at 80 bytes, so apps commonly store the real URL server-side and pass a short token (OASIS SAML 2.0 errata, section 3.4.3).
Step 3: Configure user attributes and claims
Open Attributes & Claims. The default Unique User Identifier (Name ID) is user.userprincipalname, and Zendesk needs no other mandatory attributes. Some apps do need the NameID remapped: GitHub Enterprise and Box, for instance, expect user.mail as the identifier rather than the UPN. The deep dive below covers when and how to change this.
Step 4: Set up the signing certificate and metadata
In the SAML Certificates card, you can either download the Certificate (Base64) and App Federation Metadata Url to hand to the SaaS app, or copy individual values. For Zendesk specifically, copy the certificate Thumbprint (SHA-256); Zendesk wants the fingerprint, not the full certificate.
Step 5: Assign users and groups
Go to Users and groups > Add user/group and assign your test user. By default the app's Assignment required property is Yes, so only assigned users can sign in. Assigning individual users works on every tier; group-based assignment requires P1 or P2 (Microsoft Learn: Assign user or group access). Nested group membership is not honored, so assign users directly or through a directly assigned group.
Step 6: Test the SSO integration
Use the Test single sign-on button on the SAML page (it stays greyed out until you save the Basic SAML Configuration). For deeper inspection, install the My Apps Secure Sign-in Extension for Chrome or Edge, which captures the SAML request and response and offers a "Fix it" prompt for common errors (Microsoft Learn: Debug SAML SSO).
Once the app is configured and the test user (or a group they're in) is assigned, the app tile also appears automatically on that user's My Apps portal at myapps.microsoft.com, Entra's end-user launchpad. Microsoft notes it "can take several minutes for an application to appear" there (Microsoft Learn: My Apps). Launching from a My Apps tile drives an IdP-initiated flow. Keep the portal (the website launchpad) separate from the Extension (the debugging browser add-on); they share a name but do different jobs.
Configure the Zendesk service-provider side
Back in Zendesk Admin Center, go to Account > Security > Single sign-on > Create SSO configuration > SAML and map the Entra values you collected:
Activate the configuration by assigning it to Team member and/or End user authentication. Two documented gotchas trip up many first attempts: the Test single sign-on button stays greyed out until the Basic SAML Configuration is saved (Microsoft Learn: Debug SAML SSO), and forgetting to assign the test user produces an AADSTS50105 error ("The signed in user is not assigned to a role for the application") at sign-in (Microsoft Learn: AADSTS50105).
Attribute mapping and claims customization
This is where most real-world integrations succeed or fail, so it's worth the depth.
Choosing a stable NameID
The NameID is how your SaaS app recognizes a returning user, so it must be stable. Entra's NameID format dropdown offers Default, Persistent, Email address, Unspecified, and Windows domain qualified name (Transient is supported but not in the dropdown), and you can source it from attributes like the UPN, email, objectid, employeeid, or extension attributes (Microsoft Learn: SAML claims customization).
Lead with stability. Microsoft describes the persistent NameID as "persistent, it can be revoked, but is never reassigned... opaque," and the object ID (objectid) as "immutable, globally unique, and reuse safe" (Microsoft Learn: SAML token reference). Microsoft's own nOAuth advisory warns against using the mutable, non-unique email claim for authorization decisions; prefer the immutable OID (Microsoft MSRC: nOAuth). Use email for display, not as the sole identity key.
Claim names Entra sends
By default Entra emits a standard set of claims under these URIs:
The name claim is the UPN and is display-only, not a unique key (Microsoft Learn: SAML token reference).
Transformations and group claims
Entra can transform ordinary claims with a library of functions (lowercase, regex replace, extract, join, and more), up to two transformations per claim. The NameID is more restricted: only ExtractMailPrefix and Join are allowed there, and a Join suffix must be a verified tenant domain (Microsoft Learn: Claims customization reference).
Group claims have a hard limit that surprises people. Entra emits at most 150 groups in a SAML assertion (200 in a JWT). Past that, it "completely omit[s] sending group claims in the token" and substitutes an overage link to Microsoft Graph instead (Microsoft Learn: Group claims). It's an all-or-nothing cliff, not a truncation. You can scope the claim (all groups, security groups, directory roles, or just groups assigned to the application) and filter only when a user is in 1,000 or fewer groups. When auth succeeds but the app reports "user not found," it's almost always because the value Entra sends doesn't match how the app stores the user; the fix is to align the Unique User Identifier claim with the SP's expectation (Microsoft Learn: Troubleshoot SAML SSO).
Managing SAML signing certificates
Default validity and why rotation matters
Entra generates a self-signed signing certificate that's "valid for three years" (Microsoft Learn: Manage certificates). When it expires, every SAML login to that app breaks, so rotation is an operational must, not an optional nicety. The validity period is configurable only at creation (anywhere from now to three years out) and can't be changed afterward.
Rotating a certificate without downtime
The mechanism that makes zero-downtime rotation possible is the secondary, inactive certificate:
- Create a new certificate. It lands in an Inactive state.
- Download it in the format your SaaS app needs, or rely on metadata if the app consumes the federation metadata URL.
- Configure or pre-trust the new certificate on the SP side.
- Select Make certificate active. The old certificate flips to Inactive.
- Retire the old certificate once you've confirmed sign-ins work.
During the overlap, Entra publishes both certificates in its federation metadata, so a metadata-consuming SP can trust the next certificate before it goes active (Microsoft Learn: Federation metadata). Watch one edge case: if an expired certificate and an inactive-but-valid one coexist, Entra uses the valid one, which can surprise an SP that wasn't ready for it.
Expiration notifications and automation
Entra sends email warnings "60, 30, and 7 days before the SAML certificate expires," and you can list up to five notification addresses (Microsoft Learn: Manage certificates). Keep the signing algorithm at the SHA-256 default and only drop to SHA-1 if an app truly requires it (Microsoft Learn: Certificate signing options).
There's an industry trend toward shorter certificate lifetimes — the CA/Browser Forum's Ballot SC-081v3 steps the maximum validity of publicly trusted TLS certificates down from 398 days to 47 days by March 2029 (200 days in March 2026, then 100 days in March 2027) (CA/Browser Forum: Ballot SC-081v3). That mandate applies to publicly trusted TLS certificates, not the private SAML signing certificate Entra issues (three-year default). The takeaway is to automate rollover, not to force your SAML certificate to 47 days.
Conclusion
At this point, the Microsoft Entra enterprise application has the core SAML configuration it needs: Identifier, Reply URL, claims, assignments, and certificate handling. The remaining work is operational.
This is Part 1 of a two-part series, covering the identity-provider setup path: SAML concepts, Entra terminology, prerequisites and licensing, gallery versus custom applications, the Zendesk walkthrough, claims, and signing-certificate rotation. Part 2 picks up where this leaves off: SCIM provisioning and deprovisioning, security hardening, troubleshooting the AADSTS error codes, and what changes when your SaaS must accept Entra SAML from many customers' tenants at once, including the build-versus-buy decision.
FAQ
Does a custom Microsoft Entra SAML app require Entra ID P1 or P2?
No. Basic SAML SSO for custom non-gallery enterprise applications is available on the Free tier. P1 or P2 is needed for features layered on top, such as Conditional Access, group-based assignment, group provisioning, provisioning logs, and SAML token encryption.
Should the NameID use email or an immutable identifier?
Use an immutable identifier such as the persistent NameID or Entra object ID for account matching. Email is useful for display and communication, but it is mutable and should not be the sole authorization key.
In this series
- Microsoft Entra ID SAML integration for SaaS apps (you are here)
- Microsoft Entra ID SAML integration for SaaS apps - Part 2