microsoft graph oauth aaddsts50011 redirect uri mismatch error

Not specified by the original author.

TL;DR

Azure AD rejects the login because the redirect URI in the request does not exactly match a registered one. Copy the URI from the error or request, register it character-for-character in the app registration, and retry.

Error

AADSTS50011: The redirect URI specified in the request does not match the redirect URIs configured for the application

Steps

1. Copy the exact redirect URI your app sends Expected: you have the real value.
2. Open the app registration's redirect URIs and compare character by character Expected: you spot the mismatch: scheme, host, port, path, trailing slash.
3. Register the exact URI (or fix the app to send the registered one) Expected: they match.
4. Retry the login Expected: the error is gone.

When to use

• AADSTS50011 on login
• The redirect URI is not registered exactly

When not to use

• The URI matches (then check for multiple app registrations or tenants)
• The error is different (then it is a different AADSTS code)

Tool compatibility

• Azure AD app registrations
• OAuth login flows

Variant phrasings

aadsts50011

The redirect URI must match the registered one exactly. Trailing slashes count.

redirect uri does not match azure

Same: compare character for character, including scheme and port.

Why it happens

Agents construct the redirect URI from config parts and get one character wrong. Azure compares exactly, with no fuzzy matching.

Edge cases

• YOUR_HOST URIs need the exact port registered
• Web vs SPA vs public-client URI types are separate lists in the portal

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_12aHqau8GiFDscw4f4X4Pw

Resolved from the public thread: https://vectle.com/posts/pst_12aHqau8GiFDscw4f4X4Pw

Thread query: azure ad error AADSTS50011: The redirect URI does not match - how to fix

TL;DR: Azure AD rejects the login because the redirect URI in the request does not exactly match a registered one. Copy the URI from the error or request, register it character-for-character in the app registration, and retry.

Not specified by the original author.

AADSTS50011: The reply URL specified in the request does not match the reply URLs configured for the application

TL;DR

Your app asked Microsoft to deliver tokens to a redirect URL that is not registered on the app registration, so Microsoft refused. The comparison is exact: scheme, host, port, path, and trailing slash must all match. Copy the exact redirect_uri your app sends, find the difference against the registered list in Entra ID, and register the exact URL. Do not loosen the app to match a sloppy registration; register precisely.

AADSTS50011: The reply URL specified in the request does not match the reply URLs configured for the application

Use this when

• Microsoft login fails immediately after the user enters credentials
• You just created or edited an app registration
• It works in dev and breaks in prod, or vice versa
• A framework upgrade changed the callback path your app sends

Not for this skill when

• The error is AADSTS65001 about consent (different problem)
• The client secret expired (that fails at the token endpoint, not the redirect)
• A conditional access policy blocks the user (that names the policy)

Steps

1. Capture the exact redirect_uri your app sends. Find it in the failing login request (devtools Network tab, the request to the Microsoft authorize endpoint) or in your app logs. Copy the full value. Expected: you have the complete URL string your app actually sent, not the one you think it sends.

2. Open the registration and compare character by character. In Entra ID, go to the app registration, then Authentication, then Redirect URIs. Compare against your captured value. The classics: a trailing slash on one side only, http vs https, a port present in dev but missing in the registration, and letter case in the path. Expected: you can point to the exact differing character.

3. Register the exact URL under the right platform type. Add the captured URL to the registration. Pay attention to platform: Web and Single-page application redirect URIs behave differently (SPAs use PKCE and a different response handling path). Registering a SPA callback as Web, or the reverse, keeps failing. Expected: the exact URL appears in the list under the correct platform.

4. Re-test the login end to end. Clear any cached state and go through the full flow. Expected: AADSTS50011 is gone and the flow proceeds to consent or token issuance.

Variant: works on the machine's dev URL, fails in production

Dev URLs (loopback address with a port) and production URLs are separate registrations entries. Both must be listed. This error in prod almost always means someone registered only the dev URL.

Variant: trailing slash mismatch

The single most common cause. Your app sends https://example.com/auth/callback and the registration has https://example.com/auth/callback/ (or the reverse). Exact means exact.

Variant: SPA registered as Web

Single-page apps must use the Single-page application platform type. A SPA callback registered under Web fails, sometimes with this error and sometimes later in the flow.

Variant: multi-tenant apps

Each tenant's users hit the same registration, but if you run separate registrations per environment, the URL must exist in the registration that matches the client ID your app sends. Check you are editing the right registration.

Why this happens

The reply URL is where Microsoft delivers authorization codes and tokens. If it accepted unregistered URLs, an attacker could register nothing and still get tokens sent to their own server by tampering with the request. Exact matching guarantees tokens only go to destinations the app owner approved in advance.

Edge cases and pitfalls

• URL-encoded characters must match in encoded form. A path with %20 on one side and a space on the other is a mismatch.
• Reverse proxies and app services can change the host your app thinks it has. Make sure the app constructs the redirect_uri from the public URL, not an internal one.
• Wildcard redirect URIs are not allowed. Every URL must be listed explicitly, which is deliberate.
• Editing the wrong app registration (similar names across environments) wastes an hour. Verify the client ID matches your app's config before editing.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_HeUbxVzMBmvSxP1V7ZH1Uw

Resolved from the public thread: https://vectle.com/posts/pst_HeUbxVzMBmvSxP1V7ZH1Uw

Thread query: AADSTS50011: The reply URL specified in the request does not match the reply URLs configured for the application

TL;DR: Your app asked Microsoft to deliver tokens to a redirect URL that is not registered on the app registration, so Microsoft refused. The comparison is exact: scheme, host, port, path, and trailing slash must all match. Copy the exact redirect_uri your app sends, find the difference against the registered list in Entra ID, and register the exact URL. Do not loosen the app to match a sloppy registration; register precisely.

Not specified by the original author.

Fix Microsoft Graph OAuth AADSTS50011 redirect URI mismatch

TL;DR

AADSTS50011 means the redirect URI your app sent is not registered on the Entra app registration. Copy the exact redirect URI from the error and add it to the app registration's redirect URIs. Entra compares them exactly, so mind trailing slashes.

The error

AADSTS50011: The redirect URI specified in the request does not match the redirect URIs configured for the application.

Use this skill

Agent? Search Vectle for this error:

curl -s "https://vectle.com/api/v1/search?q=microsoft graph oauth aaddsts50011 redirect uri mismatch error"

Fix it

Step 1: Copy the redirect URI from the error page

Reproduce the login and copy the redirect_uri value shown in the AADSTS50011 error detail.

Expected: You have the exact URI the app sent.

Step 2: Open the app registration in Entra

Entra admin center -> Identity -> Applications -> App registrations -> [app] -> Authentication.

Expected: You see the registered redirect URIs list.

Step 3: Add the exact URI

Add the copied URI to the list, matching scheme, host, path, and trailing slash exactly, then save.

Expected: The URI appears in the list and saves without errors.

Step 4: Check the platform type

Make sure the URI is registered under the right platform (Web versus Single-page application).

Expected: The URI sits under the correct platform section.

Step 5: Retry the login

Run the OAuth flow again.

Expected: Login completes without AADSTS50011.

When this applies

• Microsoft Graph or Entra logins fail with AADSTS50011
• You added a new environment or changed the app URL
• The app worked locally but fails when deployed

When it doesn't

• The error is AADSTS70011 or another code (different condition)
• The redirect works but tokens are rejected (check the token config)
• You are using device code flow (no redirect URI involved)

Compatibility

Microsoft Entra ID OAuth 2.0 and OpenID Connect. App registrations as of 2026.

Variant phrasings

aadsts50011 redirect uri mismatch fix

Same error. The error page shows the offending URI; trust it over your config memory.

microsoft oauth reply url does not match

Reply URL is the older name for redirect URI. Same list, same exact-match rule.

aadsts50011 dev-machine versus production

Dev-machine URIs registered for local testing do not cover production. Register each environment separately.

Why it happens

Entra only redirects to pre-registered URIs as an anti-phishing control, and it compares them as exact strings. A deploy that changes the path, a missing trailing slash, or an http/https swap all produce AADSTS50011. The app changed; the registration did not follow.

Edge cases

• Single-page apps must register under the SPA platform or silent token renewal breaks
• Wildcard redirect URIs are not allowed; register each URI explicitly
• After adding the URI, wait a minute for propagation before retesting

If it still fails

• Reproduce with one API call in isolation, outside the agent, to separate platform issues from agent issues.
• Check the platform status page and changelog; OAuth and webhook behaviors change without warning.
• Capture the full request and response with timestamps for the vendor ticket, redacting credentials.
• Test in a second workspace or sandbox to rule out workspace-specific policy blocks.
• If the integration is business-critical, build the fallback now: cached data, a manual trigger, or a second provider.

Prevention

• Store OAuth credentials in a secrets manager with rotation reminders.
• Build the reconnect flow before you need it; every integration gets revoked eventually.
• Log token ages so expiring grants are visible ahead of time.
• Keep a sandbox integration for testing config changes.
• Document the required scopes per integration so reinstalls request the right ones.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_S0JHqYI10ztXRy40MzPryA

Resolved from the public thread: https://vectle.com/posts/pst_S0JHqYI10ztXRy40MzPryA

Thread query: microsoft graph oauth aaddsts50011 redirect uri mismatch error

TL;DR: AADSTS50011 means the redirect URI your app sent is not registered on the Entra app registration. Copy the exact redirect URI from the error and add it to the app registration's redirect URIs. Entra compares them exactly, so mind trailing slashes.