Self-Service Portal Sign-In Error: AADSTS50011

Applies To: Work 365 Self-Service Portal (Power Pages)
Audience: Administrators, Support Engineers

Overview

When customers try to sign in to the Self-Service Portal, they may see:

“Sorry, but we’re having trouble signing you in.
AADSTS50011: The redirect URI … does not match the redirect URIs configured for the application …”

This means the portal is sending users to a Redirect URI that doesn’t exactly match what’s configured in your Microsoft Entra ID (Azure AD) App registration, or your Portal Site Setting still points to an old URL.

Key Concepts

• Redirect URI: Exact HTTPS URL Entra ID returns users to after sign-in. Must match scheme + host + path exactly (e.g., https://portal.yourcompany.com/signin-oidc, no trailing slash).

• Client ID: The GUID of your Entra app. The portal’s ClientId Site Setting must match the correct app registration.

• Portal Site Settings (OIDC):

  Setting name	Purpose	Example
  Authentication/OpenIdConnect/CustomerAzureAD/RedirectUri	Post-login redirect	https://portal.yourcompany.com/signin-oidc
  Authentication/OpenIdConnect/CustomerAzureAD/PostLogoutRedirectUri (recommended)	Post-logout redirect	https://portal.yourcompany.com/
  Authentication/OpenIdConnect/CustomerAzureAD/ClientId	App registration Client ID	11111111-2222-3333-4444-555555555555

• Multiple hosts / custom domains: If you added a custom domain, Front Door/CDN/App Gateway, the public host must be present as a Redirect URI in the app and reflected in the portal Site Settings.

How It Works

1. User clicks Sign in on the portal.

2. Portal redirects to Entra ID with Client ID and Redirect URI.

3. Entra validates the Redirect URI against the app’s allow-list.

4. Any mismatch (scheme/host/path/casing/trailing slash/wrong app) ⇒ AADSTS50011.

Common Causes

• Portal moved from *.powerappsportals.com to a custom domain, but Site Settings and/or the App registration weren’t updated.

• The App registration was changed or deleted; the portal’s ClientId now points to the wrong app.

• You fronted the portal with Front Door/CDN/App Gateway but didn’t add that public host as a Redirect URI.

Fix 1 — Update Redirect URI after a Portal URL Change

Goal: Make the portal Site Setting and the Entra App’s Redirect URIs match your current host, typically:
https://<your-portal-domain>/signin-oidc

A) Update the portal Site Setting

1. Open Portal Management → Site Settings.

2. Open Authentication/OpenIdConnect/CustomerAzureAD/RedirectUri.

3. Replace any old host (e.g., https://yourorg.powerappsportals.com/signin-oidc) with your current domain, e.g.:
   https://portal.yourcompany.com/signin-oidc

4. Save and allow up to 15 minutes for cache refresh.

   • Exact match matters: HTTPS, path /signin-oidc, correct casing, no trailing slash.

B) Update the Entra ID App registration

1. Azure portal → Entra ID → App registrations → your portal app → Authentication.

2. Under Web → Redirect URIs, ensure entries exist for every active host (in use today):

   • https://portal.yourcompany.com/signin-oidc

   • (Optional) Keep the legacy https://yourorg.powerappsportals.com/signin-oidc only if still used.

3. Save and test portal sign-in.

Fix 2 — App Registration Was Changed or Removed

Goal: Recreate or re-link the correct app and update the portal’s ClientId.

A) Confirm the Client ID the portal expects
Portal Management → Site Settings → open .../ClientId → copy the GUID.

B) Check if that app exists
Entra ID → App registrations → All applications, search by Client ID.
If not found, the app was removed/rotated.

C) Rebuild and relink

1. Create a new app registration for the Work 365 portal (OIDC).

2. Add https://<your-portal-domain>/signin-oidc under Redirect URIs (Web).

3. Copy the new Application (client) ID and paste it into Site Setting:
   Authentication/OpenIdConnect/CustomerAzureAD/ClientId → Save.

4. Allow up to 15 minutes for cache to refresh, then test sign-in.

5. If your access model depends on invitation links, consider re-sending invitations.

Validate & (If Needed) Restart the Site

• Test in a private/incognito window.

• If sign-in still fails: Power Platform Admin Center → Environments → Power Pages → [your site] → Site actions → Restart site (2–5 minutes).

• Hard refresh the browser after restart.

Quick Checks (Optional)

• Browser cache: Hard refresh (Ctrl/Cmd+Shift+R) or incognito.

• Multiple hosts in parallel: If users access both *.powerappsportals.com and your custom domain, ensure both Redirect URIs exist in the app; set the portal RedirectUri Site Setting to the primary host.

• Typos: Must be HTTPS, correct host, no trailing slash, exact /signin-oidc.

• Recent content changes: Ensure web templates/config are published.

• Post-login permissions: If content looks blocked after login, review table permissions (separate from sign-in).

• Environment health: Check Microsoft service health/advisories.

Best Practices

• Change control: After any domain change, update both Site Settings and App registration in the same change window.

• Limit active URIs: Keep only Redirect URIs you actually use to reduce confusion.

• Document: Record the active domain(s), Client ID, and Redirect URIs in your runbook.

• Front Door/CDN: Always register the public hostname users hit.

• Cache timing: Plan a 10–15 minute propagation window after changes.

FAQs

Do I need to add the logout URL too?
Recommended. Set PostLogoutRedirectUri in Site Settings and, if required, add the corresponding entry in the app.

Can I keep both the old and new redirect URIs?
Yes—if both domains are still in use. If the old domain is retired, remove it.

We fronted the portal with Front Door/App Gateway—what then?
Add the public host (e.g., https://portal.yourcompany.com) to the app’s Redirect URIs and set the portal’s RedirectUri Site Setting to the same host.

Summary

AADSTS50011 indicates your Redirect URI and/or Client ID are out of sync between Portal Site Settings and the Entra App registration.
After domain changes, update RedirectUri in Site Settings and the app’s Redirect URIs. If the app was rotated/removed, create a new app, update the ClientId Site Setting, and ensure the Redirect URI matches. Allow a short cache window, then restart the site and retest.