Skip to main content
Version: Angophra

Application SSO

Menu path: Observe → Application Governance → Application SSO
URL: /en/insights/dashboard/appGov/sso

Purpose​

The Application SSO page provides an overview of how Single Sign-On is configured across your enterprise application estate and whether applications are enforcing access controls before granting sign-in. SSO is one of the foundational security controls for user-facing applications - it centralises authentication through Entra ID, enabling Conditional Access policies, MFA enforcement, and audit logging to apply to all user sign-ins.

This page shows how many applications are using each SSO protocol (OAuth/OIDC vs SAML), and - critically - whether those applications have "Assignment Required" enabled to gate access.

Charts​

SSO Adoption Overview​

Chart type: add example --> Donut chart
What it shows: 657 total service principals, with the vast majority using oAuth (OAuth/OIDC) and a small number using SAML.

Why it matters: oAuth/OIDC is the modern, preferred SSO protocol for new applications. SAML is an older protocol that is still widely supported and used by many legacy enterprise applications. Understanding the split between the two helps you plan modernisation efforts - SAML applications often require more complex configuration and may not support all modern security features.

In the example, almost all applications use oAuth, which is the healthy modern pattern.

Access Control Enforcement Trend​

Chart type: add example --> Time-series line chart with three series
What it shows: Over time, for newly onboarded SSO-enabled applications, how many have "Assignment Required" set to Required, Not Required, or Unknown.

Three lines:

  • Required (green) - Applications where users must be explicitly assigned before they can sign in
  • Not Required (red) - Applications where any user in the tenant can sign in without being assigned
  • Unknown (blue) - Applications where the configuration is not clearly determinable

Why it matters: The "Not Required" line is the governance risk line. Applications where assignment is not required are effectively open to all users in your Entra ID tenant. For a user-facing application, this means every employee (and every guest) can access the application - even if they have no business need to do so.

What to look for: Is the red "Not Required" line growing faster than the green "Required" line? If so, new applications are being onboarded without access control enforcement. The goal is to see the green line dominate and the red line decline as existing applications are brought into governance.

In the example, both lines are growing, with "Not Required" consistently above "Required" - indicating that most applications in this environment do not enforce assignment, meaning access is effectively open to all tenant users.

The SSO Applications Table​

The table lists all service principals with their SSO configuration:

  • Display Name - Application name (links to application details)
  • SSO Mode - oAuth, saml, or blank (no SSO configured)
  • Redirect URIs - Count of redirect URIs (relevant for OAuth/OIDC applications)
  • Asset ID - Governance tracking reference (blank = ungoverned)

What the table tells you​

Applications with a blank SSO Mode represent service principals that are not configured as user-facing SSO applications - they may be daemon/API applications, Microsoft system services, or managed identities. These typically do not need SSO configuration.

Applications with oAuth or saml mode but no Asset ID are in use for user authentication but lack governance metadata - they appear in the Tagging Compliance report as non-compliant.

Improving your SSO governance posture​

  1. Enable "Assignment Required" on all user-facing applications - This is the single most impactful control for SSO governance. It ensures that only explicitly authorised users can sign in.

  2. Create groups for each application - Rather than assigning individual users, create role-specific groups (e.g., "App-Payroll-Users", "App-Payroll-Admins") and assign those groups to the application.

  3. Enable Conditional Access policies - SSO through Entra ID allows you to apply Conditional Access (MFA requirements, device compliance checks, location restrictions) to application sign-ins. This only works effectively when "Assignment Required" is enabled.

  4. Tag all SSO applications - Ensure every SSO application has an Asset ID, owner, and governance metadata so it can be properly managed through its lifecycle.

  5. Prefer oAuth/OIDC for new applications - When configuring new SSO integrations, use OIDC where the application supports it. OIDC is more modern, supports more security features, and is better aligned with Microsoft's direction.