AADSTS500113: No Reply Address Is Registered for the Application (Fix)

On 10/09/2026 I created a new app in Microsoft Entra ID for PnP PowerShell, ran Connect-PnPOnline -Interactive with its client ID. Instead of a working sign-in, the PnP login window said AADSTS500113: No reply address is registered for the application.

The cause is simple: the app had no redirect URI, so Entra ID had nowhere to send the token. Below I’ll show the fix with screenshots from my tenant, explain which redirect URI PnP PowerShell really needs, and cover device code sign-in and other tools.

Quick answer: Your app registration has no redirect URI. In the Microsoft Entra admin center, open Entra ID > App registrations > your app > Authentication > Redirect URI configuration > + Add Redirect URI > Mobile and desktop applications. Check the nativeclient URI, type http://localhost in the custom box, select Configure, and connect again.

What AADSTS500113 means

This is the command I ran:

Connect-PnPOnline -Url "https://contoso.sharepoint.com/sites/Marketing" `
    -ClientId "00000000-0000-0000-0000-000000000000" -Interactive

And this is what the Please login for PnP PowerShell window showed, with the IDs trimmed:

Sorry, but we're having trouble signing you in.

AADSTS500113: No reply address is registered for the application.

Troubleshooting details
Request Id: <GUID>
Correlation Id: <GUID>
Timestamp: 2026-10-09T18:57:01Z
Message: AADSTS500113: No reply address is registered for the application.

A redirect URI (Microsoft’s older name is reply URL) is the address where Entra ID sends you and your token after sign-in. Entra ID only sends tokens to addresses listed on the app registration. My app had none, so the sign-in stopped right there.

You’ll usually hit this right after building your own app for PnP PowerShell, which has been required since September 2024. The New registration page leaves the Redirect URI field optional, and it’s easy to skip. My guide to connecting to SharePoint Online using PowerShell walks through the full app setup.

Keep the Correlation Id and Timestamp from the Troubleshooting details. An admin can match them to the failed entry in the Entra sign-in logs.

Which redirect URI does PnP PowerShell need?

My screenshots below check the suggested nativeclient URI, while PnP’s own setup guide says to add http://localhost. So I checked what PnP PowerShell actually sends:

• PnP PowerShell 3.x opens your default browser for -Interactive and asks Entra ID to return the token to http://localhost on a random free port.
• PnP PowerShell 2.x on Windows showed the embedded Please login for PnP PowerShell window from my screenshot. It also used http://localhost with a random port.
• Entra ID ignores the port on localhost redirect URIs, so one http://localhost entry covers every port.

So http://localhost is the URI that matters. The nativeclient URI is Microsoft’s suggestion for apps with an embedded browser. It’s harmless, and PnP’s own registration cmdlet adds it too, but on its own it won’t match PnP’s request. You’d likely trade AADSTS500113 for AADSTS50011, the reply URL mismatch error.

How you connect	What PnP sends	What to add to the app
-Interactive	http://localhost:<port>	http://localhost under Mobile and desktop applications
-OSLogin (Windows sign-in broker)	Broker redirect URI	ms-appx-web://microsoft.aad.brokerplugin/<client ID>
-DeviceLogin	No redirect URI	Allow public client flows turned on

How to fix AADSTS500113 in the Microsoft Entra admin center

You need to own the app registration or hold a role that manages app registrations, such as Application Administrator or Cloud Application Administrator.

Step 1. Sign in to the Microsoft Entra admin center and go to Entra ID > App registrations > All applications. Open the app whose Application (client) ID matches the -ClientId you passed to PnP.

Step 2. Under Manage, select Authentication (Preview). On the Redirect URI configuration tab, select + Add Redirect URI. The banner at the top links back to the old experience if you prefer it.

Step 3. On Select a platform to add redirect URI, choose Mobile and desktop applications. PnP PowerShell is a desktop app, so Web and Single-page application are the wrong platforms.

Step 4. Check https://login.microsoftonline.com/common/oauth2/nativeclient as I did. Then type http://localhost in the custom box under the suggestions (http, not https). Leave the LiveSDK and msal<client-id>://auth entries unchecked, and select Configure.

Still on the old Authentication page? The path is Add a platform > Mobile and desktop applications, with the same checkbox, custom box, and Configure button.

To double-check, open the app’s Manifest from its Overview page. Desktop redirect URIs live under publicClient, not web or spa:

"publicClient": {
  "redirectUris": [
    "https://login.microsoftonline.com/common/oauth2/nativeclient",
    "http://localhost"
  ]
}

Reconnect and confirm the fix

Close the failed sign-in window and run the connection again. No token was issued the first time, so there’s nothing cached to clear:

$siteUrl  = "https://contoso.sharepoint.com/sites/Marketing"
$clientId = "00000000-0000-0000-0000-000000000000"   # Application (client) ID of my PnP PowerShell app

Connect-PnPOnline -Url $siteUrl -ClientId $clientId -Interactive
Get-PnPWeb | Select-Object Title, Url

When Get-PnPWeb returns your site title, AADSTS500113 is gone. A good next test is getting all SharePoint Online sites with PnP PowerShell, which also checks your SharePoint permissions.

A hand-built app often has only Microsoft Graph’s User.Read permission. If the next attempt fails with a resource error, see how to fix AADSTS650057 resource not listed by adding the SharePoint API permissions.

Device code, OS login and other tools

The same rule applies to every app: the redirect URI the client sends must already be on its app registration. Here’s what I’d check for each case:

• PnP -DeviceLogin. Device code sign-in doesn’t use a redirect URI. It needs Allow public client flows enabled on the Settings tab of Authentication (on the old page, it’s under Advanced settings). Without it, expect AADSTS7000218.
• Microsoft Graph PowerShell with your own app. Microsoft’s steps for Connect-MgGraph -ClientId also use http://localhost, plus a broker URI for Windows sign-in.
• Your own MSAL desktop app. Use nativeclient for an embedded browser and http://localhost for the system browser. That’s true whether the app calls Microsoft Graph or the SharePoint REST API.
• Web apps and SaaS connectors. Add the exact callback URL the product documents under the Web platform. Paths are case-sensitive.

For device code sign-in, the command looks like this:

Connect-PnPOnline -Url "https://contoso.sharepoint.com/sites/Marketing" `
    -ClientId "00000000-0000-0000-0000-000000000000" -DeviceLogin -Tenant contoso.onmicrosoft.com

AADSTS500113 vs AADSTS50011 and other sign-in errors

These codes show up in the same setup steps, so it helps to know which one you’re looking at:

Error	What it means	Fix
AADSTS500113	The app has no reply address at all.	Add a redirect URI (for PnP, http://localhost).
AADSTS50011	The reply address is missing, misconfigured, or doesn’t match the app’s list.	Add the exact URI the client sends.
AADSTS7000218	Entra ID expects a client secret or certificate.	Turn on Allow public client flows, or use the Mobile and desktop platform.
AADSTS650057	The requested API isn’t in the app’s permissions.	Add the API permission and grant consent.
AADSTS700016	The app wasn’t found in the tenant.	Check the client ID and tenant.

For any code, https://login.microsoftonline.com/error?code=500113 shows Microsoft’s current wording (swap in your number). Not every connection failure is an AADSTS code. If CSOM throws an ExecuteQuery exception instead, my post on the ExecuteQuery unable to connect error covers that one.

Still seeing AADSTS500113? Check these mistakes

• You edited the wrong app. Compare the client ID in your command with the app’s Application (client) ID, not its Object ID. An old ENTRAID_APP_ID environment variable can point PnP at another app.
• You never selected Configure. Closing the panel discards the URI. Reopen the Redirect URI configuration tab and confirm it’s listed.
• You picked Web or Single-page application. Move the URI to Mobile and desktop applications.
• You typed https://localhost. PnP sends http, so add http://localhost exactly.
• You fixed the app in another tenant. Check the Directory (tenant) ID on the app’s Overview page.

Redirect URIs always belong on the app registration, not the enterprise application. If everything checks out, sign in from a new PowerShell window and run a simple read, such as getting SharePoint Online site details with PowerShell.

Prevent AADSTS500113: let PnP register the app

On a new tenant, I let PnP PowerShell create the app. It registers both nativeclient and http://localhost, turns on public client flows, and adds SharePoint and Graph delegated permissions. You need a current module, so install or update PnP PowerShell first:

Register-PnPEntraIDAppForInteractiveLogin -ApplicationName "PnP PowerShell" -Tenant contoso.onmicrosoft.com

# Optional: skip -ClientId in every script (add this line to your PowerShell profile)
$env:ENTRAID_APP_ID = "00000000-0000-0000-0000-000000000000"

With ENTRAID_APP_ID set, Connect-PnPOnline -Url <site> -Interactive works without -ClientId. From there, try my PnP PowerShell scripts for SharePoint developers or browse the SharePoint PowerShell tutorials.

Once PnP PowerShell signs in cleanly, these guides make good next steps:

• How to Get All Lists and Libraries from a SharePoint Online Site Using PnP PowerShell
• How to Upload Files to a SharePoint Document Library Using PnP PowerShell
• How to Create a Site in SharePoint Online Using PnP PowerShell
• Create, Read, Update and Delete SharePoint List Items with PnP PowerShell

Frequently Asked Questions