Legacy OAuth
Menu path: Observe → Application Governance → Legacy OAuth
URL: /en/insights/dashboard/appGov/insecure-oauth
Purpose
The Legacy OAuth Configurations page identifies applications in your Entra ID tenants that are using deprecated, insecure, or legacy OAuth authentication patterns. These patterns were common in older applications but have been superseded by more secure alternatives. Microsoft has deprecated some of these flows, and security best practices strongly recommend migrating away from them.
This page is showing you the security debt in your application estate - the places where your non-human entities are using authentication practices that should no longer be accepted. Every application on this page is a risk that needs to be remediated.
Understanding the Insecure OAuth Patterns
Before diving into the charts, it is important to understand what each insecure pattern means:
Implicit Grant Flow (Access Tokens): The application is configured to receive access tokens directly in the browser redirect URL rather than via a back-channel token exchange. This exposes the token in the browser history and referrer headers, where it can be stolen. Microsoft now requires applications to use the Authorization Code with PKCE flow instead. Applications using Implicit Grant for access tokens must be migrated.
Implicit Grant Flow (ID Tokens): Similar to above, but for ID tokens (used for authentication rather than authorisation). The same risks apply. The modern equivalent is also the Authorization Code flow.
Public Client: The application is configured as a "public client" - meaning it cannot securely hold a client secret. Public clients include mobile apps and desktop applications where the source code (and any embedded secrets) could be inspected by a user. While public clients are sometimes legitimate (e.g., a mobile app), a public client that also has high-privilege permissions is a serious risk, because it means those permissions could be accessed by anyone who can run the application without needing a secret.
V1 OAuth Endpoint (Default): Applications using the legacy V1 Entra ID authentication endpoint (login.microsoftonline.com/{tenant}/oauth2/token) rather than the modern V2 endpoint (login.microsoftonline.com/{tenant}/oauth2/v2.0/token). The V2 endpoint supports more modern token formats, scopes, and security features. 500 of the 657 applications in this environment use the V1 endpoint by default - this is the most widespread legacy configuration.
Observation Cards
Implicit Grant: Access Tokens
What it means: 2 applications have the "Allow access tokens" implicit grant setting enabled.
Why it matters: This is a concrete security vulnerability. These applications should be migrated to the Authorization Code + PKCE flow immediately, and the implicit grant setting should be disabled in their application registration manifests.
Implicit Grant: ID Tokens
What it means: 10 applications have the "Allow ID tokens" implicit grant setting enabled.
Why it matters: Same concern as access tokens, but somewhat less severe since ID tokens are used for authentication rather than authorisation. However, leaking ID tokens can still be exploited. These should be migrated and the setting disabled.
Public Client Apps
What it means: 1 application is configured as a public client.
Why it matters: Investigate whether this is intentional. If it is a legitimate mobile or desktop application, this may be acceptable. If it is a web service or API, it should not be a public client.
Charts
OAuth Version Adoption
Chart type: add example --> Donut chart
What it shows: 500 out of the total application estate using V1 OAuth (Default). This means the vast majority of applications have not been updated to explicitly use the V2 endpoint.
Why it matters: While Microsoft has not yet decommissioned the V1 endpoint, it is a legacy configuration that should be updated as part of application modernisation. New application registrations should always target the V2 endpoint.
Insecure OAuth Configuration Growth
Chart type: add example --> Time-series line chart
What it shows: Over time, how the count of applications using each insecure configuration (Public Client, Implicit Access Token, Implicit ID Token, V1 OAuth) has changed.
Why it matters: If the lines are flat or decreasing, your remediation efforts are working. If the lines are still growing, new applications are continuing to be registered with insecure configurations, indicating a process failure at the point of application onboarding.
The Applications Table
The table lists all applications with insecure OAuth configurations:
- Display Name - Application name
- Implicit Access Tokens - Yes/No
- Implicit ID Tokens - Yes/No
- Public Client - Yes/No
- Principal Type - Application, ManagedIdentity, etc.
- Enabled - Whether the application is enabled
Key findings from the table
From the example data, 19 applications appear in this report. Notable patterns:
- Multiple applications have Implicit ID Tokens enabled (10 total), including some Apporetum integration applications and external vendor applications (BeyondTrust)
- Two applications (Apporetum-prod-ftp22pi and apporetum-prod-iwcum4x) have both Implicit Access Tokens and Implicit ID Tokens enabled - these are production applications with active sign-in that should be prioritised for migration
- apporetum-prod-iwcum4x is additionally configured as a Public Client - the combination of all three insecure configurations on a production application with Critical-level permissions is a significant security finding
Remediation approach
For each application in this list:
- Identify the application owner
- Assess whether the application is actively used (check Last Sign-In)
- For active applications: plan migration to Authorization Code + PKCE, then disable implicit grant settings
- For inactive applications: disable the application entirely and clean up the registration