You configure OIDC single sign-on in Microsoft Entra ID by registering the application, setting the correct redirect URIs and choosing OIDC as the sign-in protocol. Then map the claims the application needs and test token validation, logout and consent behaviour. Watch for mismatched reply URLs, excessive permissions and applications that accept tokens without proper audience checks.
What OIDC single sign-on changes in Entra ID
OpenID Connect in microsoft entra id is an authentication pattern, not just an app setting. You are establishing a trust relationship between the application and the identity provider so the app can accept signed identity tokens, validate them, and use claims for sign-in decisions. That means the real work is getting the app registration, redirect URI, token validation and logout behaviour aligned with the app’s runtime expectations.
For most integrations, the practical question is whether the application can safely consume an ID token and, when needed, access token responses without treating Entra ID as a generic login shortcut. That is why the redirect URI, issuer, audience, nonce, token lifetime and claim mapping all matter together. If any of those are inconsistent, users may be redirected, but the application will still fail at authentication or session establishment.
One useful way to think about the setup is to separate what Entra ID issues from what the application enforces. Entra ID handles the sign-in transaction and token issuance, while the app still has to verify signature, issuer, audience and the claims it depends on for authorisation decisions. When an application accepts tokens without strict audience checks or relies on brittle reply URL matching, the result is often a login flow that appears functional but is structurally unsafe.
Which registration and token settings usually matter most
The application registration is where you define the trust boundary. You register the app, add the exact redirect URIs the application will use, choose OIDC as the sign-in protocol, and then configure the claims and consent the app actually needs. If the application spans multiple environments or hostnames, each callback URL must be deliberate, because Entra ID will only return tokens to allowed endpoints.
Claim mapping should stay as small as the application can support. In most cases, the app needs a stable subject identifier, tenant context, and any group or role claims required for local authorisation logic. If you request too much, consent becomes noisier and the token becomes harder to reason about; if you request too little, the app may compensate with custom lookups that are harder to audit and test.
Logout and session handling deserve the same attention as sign-in. OIDC single sign-on is only complete when the application knows how to close its own session after Entra ID sign-out or token expiry, and when it understands whether front-channel or back-channel behaviour is in use. That is where subtle bugs often appear: the user thinks they signed out, but an app session remains active and can still be used.
If you want a broader grounding in the protocol mechanics, the OAuth 2.0 and OpenID Connect Guide for Identity Teams covers the flow, tokens and common implementation mistakes that show up during Entra ID integrations. For the protocol itself, the OpenID Connect Core 1.0 specification defines how ID tokens and SSO are supposed to work.
Where Entra ID OIDC setups usually fail in practice
The most common failures are not exotic protocol bugs, but trust mismatches. A reply URL that differs by scheme, path or environment can break the redirect. A token accepted for the wrong audience can let one application trust another application’s token. A weak consent posture can expose permissions the app does not need. And if the logout path is incomplete, the user may leave one session but keep another alive.
These mistakes become more serious when the application is granted broader directory or Graph permissions than it actually needs. In that case, OIDC becomes the front door to a much larger privilege footprint than the developer intended. The integration should therefore be reviewed as both an authentication design and an access-risk decision, not only as a sign-in configuration task.
Attacks against identity integrations often start with consent abuse, token theft or forged trust assumptions rather than password guessing. NHIMG’s Identity Provider and SSO Security Guide explains why hardened IdP controls matter around OIDC and SSO, and the Storm-1283 OAuth apps abuse 2023 case shows how abused Entra ID apps can be turned into a foothold for downstream misuse. For the protocol foundation, RFC 6749: The OAuth 2.0 Authorization Framework remains the base reference.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-63, NIST SP 800-53 Rev 5 and OWASP ASVS set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-63 | Digital Identity Guidelines | Covers federation, authentication assurance and token-based sign-in trust. |
| Recommendation — Apply phishing-resistant assurance and federation checks before trusting the sign-in flow. | ||
| NIST SP 800-53 Rev 5 | IA-2 — Identification and Authentication (Organizational Users) | OIDC SSO for workforce apps establishes user authentication to the service. |
| IA-5 — Authenticator Management | OIDC integrations depend on secure handling of client secrets, keys and token lifecycles. | |
| Recommendation — Require strong user authentication before the application accepts identity tokens. Manage client secrets and signing material with defined rotation and revocation. | ||
| OWASP ASVS | V10 — OAuth and OIDC | Directly covers secure OIDC integration, redirect handling and token validation. |
| Recommendation — Validate redirect handling, token checks and OIDC flow requirements against the implementation. | ||
| ISO/IEC 27001:2022 | A.5.15 — Access control | OIDC SSO is an access control decision that shapes who can enter the application. |
| Recommendation — Define and enforce access rules for federated application sign-in. | ||
Practitioner Guidance
What to verify: Confirm the app registration uses the exact redirect URIs the application will actually serve, and test sign-in in every environment before promoting the configuration. Validate that the app rejects tokens with the wrong audience and that it handles logout in a way users can observe.
Decision rule: If the application needs only sign-in, keep the token and claim surface narrow; if it needs data access as well, separate the OIDC login path from any delegated API permissions so the privilege decision stays explicit. Do not treat successful interactive login as proof that the authorization model is sound.
Common mistake: Teams often stop after the first successful browser redirect and miss the harder checks, such as audience validation, consent scope review and session invalidation. Those are the checks that decide whether the integration is merely working or actually trustworthy.
Practitioner takeaway: A correct OIDC setup in Entra ID is one where the application can prove who the user is, only accept the tokens it should trust, and fail safely when the callback, consent or session model drifts.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Free weekly newsletter
Subscribe to the NHI & AI Identity Journal
The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.
Bonus 33% off our NHI Course when you subscribe.
Reviewed and updated by the NHIMG editorial team on October 20, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org