AADSTS500113: No reply address is registered for the app (fix)

What does AADSTS500113 mean?

Microsoft’s error code reference doesn’t list AADSTS500113 (checked 30 October 2026).

In my lab tenant, an unauthenticated authorize request in a browser, for an app registration with no redirect URI, showed this error on the page:

AADSTS500113: No reply address is registered for the application.

“Reply address” is the older name for a redirect URI. Microsoft’s redirect URI page explains why Entra needs one: “To sign in a user, your application must send a login request to the Microsoft Entra authorization endpoint, with a redirect URI specified as a parameter. The redirect URI is a critical security feature that ensures the Microsoft Entra authentication server only sends authorization codes and access tokens to the intended recipient.” Our reading: with no redirect URI registered at all, there is no allowed place to send the result, so Entra refuses the request.

A Microsoft moderator on Microsoft Q&A gave the same reading: “The error states that the reply URL is not available, hence to fix this, you need to add a valid RedirectURI/ReplyURL in your app registration in AAD.”

Don’t confuse it with AADSTS50011, which Microsoft does list. Our reading of the difference: 50011 means the app has redirect URIs but the one in the request doesn’t match; 500113 means the app has none.

Reproduced in the lab

In a manual lab test on 30 October 2026, an authorize URL for a lab app registration with no redirect URI was opened in a private browser window, without signing in. Entra showed AADSTS500113 on its error page with this first line:

AADSTS500113: No reply address is registered for the application.

That confirms the code and its wording at the authorize endpoint. It also shows the error doesn’t need a signed-in user: the request was unauthenticated. It lands in SigninLogs, and the row was logged under the account that was already signed in to that browser (the lab admin), with client app “Browser”. So the user on a 500113 row can be whoever had a session, not someone who typed a password. The KQL below was run on these rows (how). The first query found the row. The AuditLogs query isn’t tested: the export has no audit rows.

Is it an attack?

No. It is an app registration that is missing its redirect URI.

Pattern	Likely meaning
A new app registration, first test sign-in	The developer created the registration and never added a platform.
A desktop or mobile app (for example an Android app) fails on first interactive sign-in	The registration has no Mobile and desktop applications platform. Users report this on Microsoft Q&A (Android) and the Icewolf blog (delegated login).
An app registration made for a background service is now used for user sign-in	Likely: app-only (client credentials) apps don’t use the authorize endpoint, so they never needed a redirect URI. Microsoft doesn’t say this; a user commenter on the same Q&A thread does.
An app that worked and now fails	Someone removed its redirect URIs. Check the audit log (query below).

An attacker who sends this request probably learns only that the app has no redirect URI. Nobody is signed in and nothing is issued.

How do I find it in my logs (KQL)?

Microsoft doesn’t document which sign-in table 500113 is logged in. The lab run above logged it in SigninLogs, under the account that already had a session in the browser. Check both user sign-in tables:

union withsource=SourceTable SigninLogs, AADNonInteractiveUserSignInLogs
| where TimeGenerated > ago(30d)
| where ResultType == "500113"
| summarize Rows = count(), LastSeen = max(TimeGenerated) by SourceTable, AppId, AppDisplayName

The audit log is more useful. If the app used to work, find who changed its registration:

AuditLogs
| where TimeGenerated > ago(90d)
| where OperationName == "Update application"
| mv-expand Target = TargetResources
| where tostring(Target.displayName) == "<app display name>"
| mv-expand Prop = Target.modifiedProperties
| project TimeGenerated,
    Actor = coalesce(tostring(InitiatedBy.user.userPrincipalName), tostring(InitiatedBy.app.displayName)),
    Property = tostring(Prop.displayName),
    OldValue = tostring(Prop.oldValue),
    NewValue = tostring(Prop.newValue)
| sort by TimeGenerated desc

The table reference documents TargetResources and InitiatedBy only as dynamic columns. The field names inside them (displayName, modifiedProperties, user.userPrincipalName) aren’t documented there, and neither is the operation name Update application. Look for a property whose old value held URLs and whose new value is empty.

How do I fix AADSTS500113?

For the user: you can’t fix this yourself. Report the app name to whoever set it up.

For developers and admins: add a platform and redirect URI to the app registration. Microsoft’s steps:

1. In the Microsoft Entra admin center, in App registrations, select the application.
2. Under Manage, select Authentication.
3. Select Add Redirect URI (on the Redirect URI configuration tab).
4. Pick the platform that matches the app: Web, Single-page application, iOS / macOS, Android or Mobile and desktop applications.
5. Enter or select the redirect URI, then select Configure.

Microsoft: “For Web and Single-page applications, you specify a redirect URI manually. For Mobile and desktop platforms, you select from generated redirect URIs.” Use the exact URI the app sends. If it then fails with AADSTS50011, the URI you added doesn’t match the one in the request.

If the app is only meant to run as a background service, it shouldn’t be sending users to the authorize endpoint at all. Our reading: switch it to the client credentials flow rather than adding a redirect URI it doesn’t need.