Auth0 + Microsoft 365 integration
Set up Auth0 as the identity provider for Microsoft 365 via SAML — for B2B scenarios where Auth0 customers federate into a partner Microsoft 365 tenant.
- Auth0 tenant admin
- Partner M365 tenant cooperation
1. Create a new SAML 2.0 application in Auth0
In the Auth0 admin console, create a new SAML 2.0 application. Choose "Web Application" type. Note the placeholders for ACS URL + Entity ID — you'll get these from Microsoft 365 in step 3.
2. Get the SAML metadata URL from Auth0
Auth0 exposes the IdP metadata at a stable URL. Copy this URL — you'll paste it into Microsoft 365's SSO configuration. Alternatively, download the metadata XML if Microsoft 365 doesn't support URL-based metadata.
3. Configure SSO in Microsoft 365
In Microsoft 365's admin → security → SSO settings, paste the Auth0 metadata URL (or upload the XML). Microsoft 365 will display the ACS URL + Entity ID it expects — copy these.
4. Return to Auth0 + complete the SAML app config
Paste Microsoft 365's ACS URL into the Auth0 app's Single Sign-On URL field. Paste the Entity ID into the Audience URI field. Set the NameID format to EmailAddress (or persistent if Microsoft 365 expects that).
5. Configure attribute mapping
Map the attributes the SP expects (see the Attribute Mapping section below). At minimum, email is required. Most apps also expect firstName + lastName.
6. Assign users + groups
In Auth0, assign the SAML app to users or groups that should have access. Test with a pilot group before broad rollout.
7. Test end-to-end
Sign in to Microsoft 365 via the IdP-initiated link (from Auth0 dashboard) AND via SP-initiated (direct Microsoft 365 login URL). Both should work. Check the SAML Tracer browser extension or SAML decoder to inspect the assertion if anything fails.
What flows from where.
| Source (Auth0) | Target (Microsoft 365) | Note |
|---|---|---|
| user.email | NameID | — |
| user.email | UPN | — |
- Clock skew: Auth0 and Microsoft 365 clocks must be within ~5 minutes. NTP-sync both. SAML's NotBefore + NotOnOrAfter are strict.
- NameID format mismatches are the most common failure. Microsoft 365 typically wants EmailAddress; Auth0 defaults vary. Mismatch → cryptic "invalid assertion" errors.
- Just-in-time (JIT) provisioning vs SCIM: many apps support both. SAML JIT creates the user on first SSO; SCIM creates them ahead of time. Pick one — both can cause attribute drift.
- Audience restriction: Microsoft 365's expected Audience URI must match exactly what the IdP sends. Trailing slashes + protocol (http vs https) matter.
- Signed Response vs signed Assertion: many SPs require the Assertion to be signed (not just the Response envelope). Check the SP's docs.
- Less common — typically used for partner B2B federation into M365 SharePoint or Teams external access.
- IdP-initiated SSO works (sign in from the IdP dashboard)
- SP-initiated SSO works (visit Microsoft 365 directly + get redirected to IdP)
- User attributes flow through correctly (email, name, groups)
- Logout (single logout if supported) works as expected
- Step-up MFA fires when policy requires it
- Unauthorized users (not assigned to the app) get a clean denied message
- Capture a successful SAML response and inspect it (use the SAML decoder tool)
For the latest vendor-side configuration changes, refer to:
Auth0 SAML provider docs →