Skip to main content
Version: Angophra

SSO Redirect Security

Menu path: Observe → Application Governance → SSO Redirect Security
URL: /en/insights/dashboard/appGov/sso-redirect

Purpose​

The SSO Redirect Security page analyses the redirect URIs (also known as reply URLs or callback URLs) configured in your application registrations. Redirect URIs are the URLs where Entra ID sends authentication tokens after a successful sign-in. They are a critical security configuration - if a redirect URI is misconfigured or insecure, attackers may be able to intercept authentication tokens.

This page surfaces four specific categories of redirect URI risk, showing the good (properly configured HTTPS URIs pointing to live production domains), the bad (localhost and development URIs left in production), and the ugly (insecure HTTP URIs and subdomain takeover risks where the domain is no longer owned).

Observation Cards​

Localhost Redirects​

What it means: 2 redirect URIs point to localhost (e.g., https://localhost:44340/... or http://localhost:3000/...).

Why it matters: Localhost redirect URIs are typically added by developers during local development and testing. They should never remain in a production application registration. A localhost redirect URI in a production application means: (1) if another application on a user's machine is listening on that port, it could potentially intercept the authentication redirect; and (2) it suggests the application's security configuration has not been properly reviewed since development.

Wildcard Redirects​

What it means: No applications have wildcard redirect URIs configured.

Why it matters: A wildcard redirect URI (e.g., https://*.example.com) would allow any subdomain of that domain to receive authentication tokens. This is a severe misconfiguration - if any subdomain is compromised, the attacker can redirect tokens to their controlled subdomain. Zero is the correct value here.

Insecure HTTP Redirects​

What it means: 1 redirect URI uses HTTP (unencrypted) rather than HTTPS.

Why it matters: HTTP redirect URIs transmit authentication tokens over an unencrypted connection, where they can be intercepted by a network attacker (man-in-the-middle attack). All redirect URIs in production must use HTTPS. The presence of even one HTTP redirect URI is a security finding.

Subdomain Takeover Risk​

What it means: 7 redirect URIs point to domains or subdomains that are no longer registered or owned.

Why it matters - this is one of the most serious redirect URI findings. Subdomain takeover occurs when a DNS entry points to a cloud resource (like an Azure Web App) that has been deleted, but the DNS record and the Entra ID redirect URI still reference that subdomain. An attacker can register that cloud resource name (e.g., an Azure Web App with the same subdomain name), and because the redirect URI in Entra ID points to it, they will receive authentication tokens from legitimate sign-ins. This is a complete token hijacking vulnerability.

In the example, 7 redirect URIs point to .azurewebsites.net subdomains that no longer have corresponding Azure Web App instances - classic subdomain takeover risk.

Charts​

Redirect URI Sources​

Chart type: add example --> Donut chart
What it shows: 20 total redirect URIs across applications, broken down by source type: Web (server-side web applications) vs PublicClient (mobile/desktop applications).

Why it matters: Web redirect URIs and PublicClient redirect URIs have different security properties. Web redirect URIs should always use HTTPS to a server you own. PublicClient redirect URIs are used by mobile and desktop apps and may have different URL formats (e.g., custom URI schemes).

TLS Enforcement by Source​

Chart type: add example --> Stacked bar chart
What it shows: For each redirect URI source type (PublicClient, Web), the breakdown of URIs that use HTTPS (secure) vs HTTP (insecure).

Why it matters: This chart visually shows where insecure HTTP redirect URIs are concentrated. In the example, the Web source type has one HTTP entry, while PublicClient appears mostly secure.

Redirect Security Findings​

Chart type: add example --> Bar chart
What it shows: The count of each security finding type (HTTP, Localhost, Subdomain Takeover, Wildcard) broken down by redirect URI source.

Why it matters: This gives you a consolidated view of all the redirect URI security work needed, showing which source types (Web vs PublicClient) are contributing to each issue type.

The Redirect URIs Table​

The table lists all redirect URIs with:

  • Application - The application the redirect URI belongs to (links to application details)
  • URI - The full redirect URI
  • Source - Web, PublicClient, or SPA
  • Localhost - Yes/No
  • HTTP - Yes/No (insecure HTTP)
  • Wildcard - Yes/No
  • Subdomain Takeover Risk - Yes/No
  • Last Sign-In - When the application last signed in

Use the filter toggles (HTTP, Localhost, Subdomain Takeover, Wildcard) to focus on specific risk types.

Key findings from the example data​

Subdomain takeover risks (7 findings):

  • Apporetum-prod-ftp22pi: Two redirect URIs pointing to .azurewebsites.net subdomains - these application instances appear to have been deleted
  • apporetum-prod-iwcum4x: Three redirect URIs with subdomain takeover risk
  • Apporetum-prod-nmdakbh: Two redirect URIs with the same issue

These findings suggest application instances were deployed to Azure, their infrastructure was later deleted, but the application registrations were not updated to remove the old redirect URIs.

Localhost redirects (2 findings):

  • apporetum-prod-iwcum4x has two localhost redirect URIs: https://localhost:44340/signin-oidc and http://localhost:3000/api/auth/callback/azure-ad. The second is both a localhost URI and an insecure HTTP URI - a double finding on a production application.

Remediation guidance​

For each finding type:

Localhost URIs: Remove them from the application registration. These should never be in production.

HTTP URIs: Verify whether the application endpoint supports HTTPS. If yes, update the redirect URI to HTTPS. If no, work with the application team to enable TLS.

Subdomain Takeover Risk: Check whether the domain/subdomain is still registered and owned by your organisation. If the resource no longer exists, remove the redirect URI from the application registration immediately. If the resource should exist, redeploy it and verify DNS resolution.

Wildcard URIs: Remove them and replace with explicit, fully-qualified HTTPS URIs.