Use redirect URIs that are exact, pre-registered, and tied only to the app’s real sign-in flow. Prefer HTTPS for web apps, avoid wildcards, and remove unused URIs. For public clients, use platform-specific loopback or custom schemes only where required. Misconfigured redirect URIs can enable code interception, token leakage, or account takeover.
How redirect URIs fit into the Entra app trust boundary
Redirect URIs are not just a configuration field, they are part of the app’s proof that an authorization response should come back to a specific client and endpoint. For Entra app registrations, that means the URI list should be as small as the real sign-in flow requires, because every extra entry expands the places an auth code or token can be delivered.
Exact matching matters because redirect handling is where attacker-controlled endpoints, scheme confusion, or cross-app collisions turn a legitimate login into credential or token theft. The safest pattern is to register only the production and required platform-specific callback endpoints, then keep them stable and review them whenever the app’s sign-in path changes. The OAuth and OpenID Connect basics in the OAuth 2.0 and OpenID Connect Guide for Identity Teams help frame why the redirect step is security-sensitive rather than purely functional.
For web apps, HTTPS redirect URIs should be the default because they reduce exposure to interception and tampering during the return leg of the flow. For public clients, loopback or custom-scheme redirects are sometimes necessary, but the safer design is still a tightly scoped callback that matches the client type and platform, not a broad URI pattern that can be reused or guessed.
What goes wrong when redirect URIs are too broad
Broad or loosely controlled redirect URIs create a trust problem at the exact moment the app receives the authorization response. If wildcard-like patterns, reusable custom schemes, or stale callback entries remain in the registration, an attacker can try to capture an authorization code, access token, or one-time response by steering the flow to a malicious destination or a competing application.
That risk is not limited to obviously broken configurations. A URI that was once valid for testing, a forgotten localhost callback, or a mobile scheme shared with another app can become an abuse path later if it remains registered. The mobile security guidance in the Mobile App Security Guide is useful here because mobile deep links, custom schemes, and URI hijacking are the same class of problem in a different client shape.
Unused redirect URIs are also a maintenance risk. They enlarge the app’s attack surface, create ambiguity during reviews, and make it harder to prove which callback is actually used for production sign-in. The practical control is not just “use HTTPS”, it is “use the smallest possible allowlist that maps to the real client and remove everything else.”
How to keep Entra redirect URI hygiene operationally safe
The best operational model is to treat redirect URIs as release-managed configuration. Add them only when a platform or app flow genuinely needs them, and remove them when that flow is retired, renamed, or replaced. In mixed environments, this is especially important when one app registration supports multiple platforms, because each platform adds its own callback shape and its own review burden.
That discipline sits naturally alongside broader Entra application governance. The Entra ID Applications and Consent Guide helps place redirect URI hygiene in the wider context of application registration, consent, and app exposure, while the Microsoft 365 Security Guide is useful when you want the tenant-level view of Entra sign-in controls and audit visibility.
For higher-assurance environments, pair redirect URI review with app ownership checks, change control, and sign-in log review. If a callback is added outside a normal release path, or if a URI appears that no deployment record can explain, treat that as a security event, not a harmless admin change.
Risk and Threat Considerations
Redirect URI misconfiguration can convert a normal OAuth sign-in into a token capture or account takeover path. The practical danger is highest when the authorization response can be redirected to a location the attacker controls, or when the app accepts more callback variants than the client genuinely needs.
Failure mechanism: An attacker abuses an overbroad, stale, or reusable redirect URI to intercept the authorization response, then redeems or reuses the returned code or token before the legitimate client can complete the flow.
Impact: Depending on the app and scope set, the result can be session hijacking, unauthorized API access, mailbox or data exposure, or persistent account compromise until the app registration is corrected and affected sessions are reviewed.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 addresses the attack and risk surface, while NIST SP 800-63, OWASP ASVS and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-63 | Digital Identity Guidelines | Redirect URI handling is part of OAuth/OIDC federation and callback trust. |
| Recommendation — Use phishing-resistant redirect handling and exact callback validation for the sign-in flow. | ||
| OWASP ASVS | V10 — OAuth and OIDC | ASVS V10 directly covers OAuth/OIDC redirect handling and authorization flow security. |
| Recommendation — Validate exact redirect URIs and restrict callback endpoints to the intended OAuth/OIDC flow. | ||
| NIST SP 800-53 Rev 5 | IA-2 — Identification and Authentication (Organizational Users) | Entra app sign-in redirects are part of authentication assurance for organizational users. |
| Recommendation — Enforce exact redirect registration as part of authenticated sign-in controls. | ||
| OWASP Non-Human Identity Top 10 | NHI-02 — Secret Leakage | Misrouted auth responses can expose tokens or secrets tied to the app flow. |
| Recommendation — Minimise exposed callback paths so authorization responses cannot leak to unintended endpoints. | ||
Practitioner Guidance
What to verify: Confirm that every registered redirect URI maps to one documented client type and one real sign-in path. If a callback exists only for testing, local development, or an old platform version, remove it from the production app registration rather than leaving it “just in case”.
Decision rule: If the redirect target can be influenced by a user-controlled browser, mobile scheme, or competing application, treat the URI as high-risk and require an exact-match callback with the narrowest possible scope. Do not rely on broad patterns to save implementation effort.
Practitioner takeaway: Redirect URI security is mostly a precision problem, the safest registration is the one that exposes the fewest valid return paths and is easy to explain, audit, and retire.
Related resources from NHI Mgmt Group
- What are the best practices for LLM app security when handling sensitive data?
- How should security teams extend Microsoft Entra ID to legacy on-premises applications without rewriting every app?
- Why do app registrations and client secrets create security risk if they are left unmanaged in Entra ID?
- What are the key AI App Security best practices?