cyber-security identity sso claude-curated
Azure AD — now branded Microsoft Entra ID — is one of the most widely deployed identity providers for enterprise SSO. Most SaaS apps that target enterprises end up integrating with it, and there are recurring patterns and pitfalls worth knowing independent of any specific tenant.
SAML 2.0 vs OpenID Connect
Entra ID supports both protocols for SSO. Choice depends on the relying app:
- SAML 2.0 — older, XML-based, still dominant for enterprise SSO and most pre-2015 SaaS apps. Browser-based, uses a POST binding for assertions. Verbose but battle-tested.
- OpenID Connect (OIDC) — built on OAuth 2.0, JSON-based, friendlier for modern web and mobile apps. Pairs naturally with API access via OAuth.
For a greenfield SaaS app, OIDC is usually the better choice. For integrating with an existing enterprise that already has a SAML federation pattern, SAML often wins by inertia.
App Registration vs Enterprise Application
A common source of confusion in Entra ID:
| Object | What it is |
|---|---|
| App Registration | The developer artefact. Defines the app globally — its identity, redirect URIs, secrets, certificates, exposed scopes, required permissions. |
| Enterprise Application | The tenant-specific instance. Created when an app is consented to in a tenant. Holds tenant-specific config: user/group assignments, conditional access, SSO settings, claim mappings. |
A single-tenant app has both objects in the same tenant. A multi-tenant app has one App Registration in the publisher’s tenant and an Enterprise Application in each customer’s tenant. Settings live in different objects, and the admin UI does not always make this obvious.
Redirect URIs / Reply URLs
For OIDC, reply URLs are where Entra ID sends the user back after authentication, with a code or token. Rules:
- Exact match required — the URL the app sends in the auth request must exactly match an entry registered on the app. No path prefixes, no implicit suffixes.
- Multiple URIs supported — register one per environment (dev, staging, prod) and one per tenant domain.
- No wildcards — Entra ID does not support wildcard reply URLs. This is a deliberate security choice; wildcard reply URIs enable open-redirect-style attacks.
- HTTPS required — except for
http://localhostfor local development. See TLS and TLS Certificate Authorities. - Per-platform configuration — Web, SPA, and Mobile platforms each have their own reply URL list with different rules (SPA requires CORS, Mobile uses custom schemes).
For multi-tenant or multi-domain apps where customers run on their own custom domains, every domain needs its own reply URL entry. The list grows quickly. Entra ID has limits (publicly documented around the low hundreds per app), so high-cardinality customer domains push you toward indirection patterns — see OAuth Redirect URL Management.
Conditional Access
Entra ID’s policy engine sits in front of every authentication. Policies can require:
- MFA for specific apps, users, or groups
- Device compliance (managed by Intune)
- Trusted network locations
- Risk-based authentication (sign-in or user risk)
- Session controls (token lifetime, persistent browser session)
Conditional Access runs at the IdP, so it applies regardless of the relying app’s own controls. This is the right layer for enforcing MFA centrally rather than per-app.
Token lifetimes
Entra ID’s defaults are reasonable for most apps: ID tokens valid for ~1 hour, refresh tokens long-lived but revocable. Conditional Access sign-in frequency policies let admins shorten this — useful for high-sensitivity apps.
Apps must handle token expiry gracefully: detect expired access tokens, use refresh tokens silently, prompt for re-auth only when refresh fails.
Common errors
Entra returns errors with AADSTS codes. Useful ones to recognise:
| Code | Meaning |
|---|---|
AADSTS50011 | Reply URL mismatch — the URL the app sent does not match any registered reply URL. Most common error during initial integration. |
AADSTS70001 | App not found in tenant — the app is registered in another tenant and the user’s tenant has not consented. Multi-tenant apps need admin consent. |
AADSTS65001 | User or admin consent missing — the app requested scopes the user has not granted. |
AADSTS50105 | User not assigned to the app. Happens when the Enterprise Application requires explicit assignment and the user is not in the assigned group. |
AADSTS50058 | Silent sign-in failed — usually means the user’s session expired and the app needs to do an interactive login. |
AADSTS90019 | No tenant identifier in the request — the auth URL is missing the tenant ID and the app is not configured as multi-tenant. |
Group claims vs role claims
For authorisation, two patterns:
- Group claims — Entra includes the user’s group memberships in the token. The app maps groups to roles internally. Flexible but verbose; group claims have a size limit (~150 groups before Entra switches to a Graph API call instead of inline claims). A user in many groups silently breaks group-based auth.
- App role claims — defined on the App Registration, assigned to users or groups in the Enterprise Application. The token includes only the assigned roles. Cleaner and avoids the size limit, but requires defining roles up front. Aligns well with RBAC and ABAC models.
For new integrations, app roles are usually the better choice. Group claims are easier to retrofit onto existing AD group structures.
Tenant types
Entra distinguishes single-tenant from multi-tenant apps. Multi-tenant means users from any Entra tenant can sign in (subject to admin consent). For B2C scenarios — public users with social or local accounts — Entra External ID (formerly Azure AD B2C) is a separate product with its own user directory and policy model.