Setting up SSO with Azure AD for a SaaS product is usually done using SAML 2.0 or OpenID Connect (OIDC), with OIDC preferred for new web/mobile apps and SAML common for enterprise SaaS.

High-level steps

1) Choose the protocol

• OIDC: Modern, simpler for app developers, best for interactive login.
• SAML: Often required by enterprise customers and common in SaaS admin setups.

If you’re building a new SaaS app, start with OIDC unless your customers specifically ask for SAML.

---

2) Register your app in Azure AD

In the customer’s Azure portal (or your own tenant for testing):

1. Go to Microsoft Entra ID (Azure AD).
2. Select App registrations → New registration.
3. Enter:
   • Name
   • Supported account types
   • Redirect URI:
     • OIDC: https://yourapp.com/auth/callback
4. Save the app registration.

For SAML, instead use Enterprise applications → New application → Create your own application.

---

3) Configure identity endpoints

If using OIDC

You need:

• Client ID
• Client secret (or certificate for confidential clients)
• Tenant ID
• Authority / issuer URL

Typical authority:

• https://login.microsoftonline.com/{tenant-id}/v2.0

Your app will use:

• Authorization endpoint
• Token endpoint
• JWKS endpoint for token validation

Azure provides these via the discovery document:

• https://login.microsoftonline.com/{tenant-id}/v2.0/.well-known/openid-configuration

If using SAML

You need:

• Entity ID / Identifier
• Reply URL / ACS URL
• Sign-on URL (optional)
• Certificate for signing/validation

Azure will send:

• SAML assertion
• NameID
• Optional claims like email, groups, roles

---

4) Configure claims and user mapping

Decide what user attributes your SaaS app needs:

• email
• name
• tenant ID
• groups / roles
• immutable user ID

Best practice:

• Use a stable unique identifier, not just email.
• Map Azure claims to your internal user record.
• Support JIT provisioning if needed.

For Azure AD, useful claims include:

• oid = user object ID
• tid = tenant ID
• preferred_username
• email
• groups or app roles

---

5) Implement login flow in your SaaS app

OIDC flow

1. Redirect user to Azure login.
2. User authenticates in Microsoft.
3. Azure redirects back with an authorization code.
4. Your backend exchanges code for tokens.
5. Validate the ID token:
   • signature
   • issuer
   • audience
   • nonce
   • expiration
6. Create your app session.

SAML flow

1. User clicks “Sign in with Microsoft”.
2. Your app sends a SAML AuthnRequest to Azure.
3. Azure authenticates the user.
4. Azure posts a SAML response to your ACS endpoint.
5. Validate the assertion.
6. Create your app session.

---

6) Handle tenant/customer onboarding

For SaaS, each customer may have their own Azure tenant.

Common patterns:

• Single-tenant per customer: customer configures your app in their tenant.
• Multi-tenant OIDC: allow login from any Azure tenant, then restrict access in your app.
• Enterprise SSO onboarding: customer admin configures SAML/OIDC metadata in your admin UI.

You’ll typically ask the customer for:

• Tenant ID
• Domain name
• Metadata URL or federation metadata
• Claims mapping requirements

---

7) Provision users and roles

SSO only proves identity. You still need to decide:

• Is this user allowed into your app?
• What role should they have?
• Should accounts be auto-created?

Options:

• Just-in-time provisioning
• SCIM provisioning for automated user management
• Manual approval / invite only

If you need lifecycle management, use SCIM in addition to SSO.

---

8) Secure the integration

Important security practices:

• Always use HTTPS.
• Validate all tokens/assertions.
• Check issuer, audience, expiry, and signature.
• Use PKCE for public clients.
• Rotate secrets regularly.
• Don’t use email alone as the primary key.
• Restrict access by tenant if required.
• Log auth events for auditing.

---

9) Test with a pilot tenant

Test:

• First-time login
• Existing user login
• Logout
• Expired tokens
• Wrong tenant
• Missing claims
• Group/role assignment
• Account provisioning

---

10) Document setup for customers

Provide clear admin instructions:

• What they need to configure in Azure
• Redirect URLs / ACS URLs
• Entity ID / issuer
• Required claims
• How to assign users/groups
• Contact info for support

---

Recommended approach for SaaS

If you control the product design:

• Use OIDC for authentication
• Add SCIM for provisioning
• Optionally support SAML for enterprise customers who require it

---

Example: OIDC setup at a glance

You’d typically store:

• tenant_id
• client_id
• client_secret
• redirect_uri

And validate:

• iss = expected Azure issuer
• aud = your client ID
• tid = allowed customer tenant
• nonce and state

---

If you want, I can give you:

1. a step-by-step Azure portal setup,
2. a Node.js / Python / .NET example, or
3. a SAML vs OIDC decision guide for your SaaS.