OAuth 2.0 with Microsoft exposes the gap in delegated access controls

At a glance

What this is: This is a technical overview of OAuth 2.0 with Microsoft that shows how app registration, consent, scopes, tokens, and flow selection shape delegated access risk.

Why it matters: It matters because Microsoft OAuth implementations create NHI-style identities and long-lived access paths that IAM teams must govern, monitor, and revoke like any other privileged integration.

By the numbers:

• Only 20% have formal processes for offboarding and revoking API keys, and even fewer have procedures for rotating them.
• 85% of organisations lack full visibility into third-party vendors connected via OAuth apps.

👉 Read Oasis Security's guide to OAuth 2.0 with Microsoft

Context

OAuth in Microsoft environments is really a delegated access and identity governance problem. Once an app is registered, the combination of audience, scopes, redirect URI, and consent determines what the app can do on behalf of a user or tenant, which is why the boundary between application security and IAM disappears quickly.

For NHI practitioners, the important point is that OAuth creates non-human access paths that persist beyond a single login event. Service principals, access tokens, refresh tokens, and consent grants all need lifecycle controls, review, and revocation discipline. That is typical of modern enterprise OAuth usage, not an edge case.

Key questions

Q: How should security teams govern OAuth apps that access Microsoft resources?

A: Security teams should treat OAuth applications as non-human identities with owned lifecycles, explicit scopes, and recurring access review. The core controls are consent governance, exact redirect URI registration, token storage hygiene, and prompt revocation when the business use case ends. Without those controls, delegated access becomes standing access in practice.

Q: What is the difference between access tokens and refresh tokens in OAuth risk management?

A: Access tokens are short-lived credentials used for immediate API calls, while refresh tokens extend access by allowing new tokens to be issued without reauthentication. For security teams, the key difference is persistence: refresh tokens and the grants behind them keep trust alive after a session ends, so revocation matters as much as expiration.

Q: Why do OAuth consent grants create governance risk for IAM teams?

A: Consent grants turn a user or administrator decision into durable application access that can persist across sessions and, in some cases, across tenants. IAM teams need to review who granted what, whether the scope still matches the business purpose, and whether the app has become an unnecessary trusted path into enterprise data.

Q: How can organisations reduce delegated access risk in Microsoft OAuth environments?

A: Organisations should use least-privilege scopes, enforce PKCE, lock down redirect URIs, and review enterprise applications on a recurring schedule. They should also remove stale service principals and offboard OAuth apps as part of application retirement, not as an afterthought.

Technical breakdown

How Microsoft OAuth turns apps into non-human identities

In Microsoft Entra, app registration creates an identity record that can act inside a tenant. For organizational consent, the service principal represents the application instance and becomes the control point for permissions, authentication, and authorization. That means OAuth is not only a protocol exchange. It is also an identity creation event with governance consequences. The audience setting determines which tenants can interact with the app, while scopes define the delegated permissions the app can request. In practice, the app's effective access depends on both the user's consent and the tenant's policy boundaries.

Practical implication: inventory service principals as NHI assets and review their scopes like privileged accounts.

Why token lifetime and redirect handling shape OAuth risk

OAuth tokens are time-bound credentials, but the security story is wider than expiry. Access tokens grant immediate API access, refresh tokens extend that access, and redirect URIs control where authorization responses return. If redirect URIs are mismanaged, or if tokens are exposed in browser history, logs, or third-party scripts, the protocol's trust model weakens. Public clients are especially exposed because they cannot safely hold secrets, while confidential clients shift trust to the backend. PKCE reduces interception risk in authorization code flows by binding the code exchange to the original client.

Practical implication: enforce PKCE, restrict redirect URIs, and treat token storage as a first-class control.

Scopes, consent, and service principals create the governance surface

Scopes are the permissions contract, but consent is the enforcement event. A user or administrator can grant an app access that remains usable until revoked, which is why consent sprawl becomes a governance issue. In multi-tenant scenarios, service principals are created per tenant and can accumulate permissions unevenly across environments. This produces a familiar NHI pattern: the identity is machine-managed, the access is durable, and the review cadence is often weaker than the business risk warrants. The result is a large set of quietly trusted integrations that can outlive their original need.

Practical implication: build recurring consent reviews and revoke stale app grants before they become hidden standing access.

Threat narrative

Attacker objective: The attacker wants durable delegated access to Microsoft resources through trusted application and token paths rather than through interactive login.

1. Entry via a third-party OAuth app that receives delegated consent and valid scopes inside Microsoft Entra.
2. Escalation through overbroad permissions, weak redirect handling, or token exposure that lets the app act beyond intended scope.
3. Impact through persistent access to mail, calendar, files, or tenant data without directly stealing a user password.

Breaches seen in the wild

• Salesloft OAuth token breach — hackers stole OAuth tokens to access Salesforce data via Salesloft.
• Internet Archive breach — unsecured GitLab authentication tokens exposed 31M Internet Archive accounts.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

OAuth governance is NHI governance once apps can act on behalf of users. Microsoft-style delegated access creates machine identities with real authority, not just application metadata. The scope, consent, and tenant model define a security boundary that many IAM programmes still treat as an integration detail. Practitioners should classify OAuth apps as NHI assets and review them with the same discipline used for service accounts and API keys.

Token lifetime is not the same as control lifetime. Expired access tokens do not eliminate the underlying trust relationship if refresh tokens, consent grants, or service principals remain active. That is why OAuth risk often persists after the original session ends. Security teams should focus on revocation, consent hygiene, and tenant-level monitoring rather than assuming short token TTLs solve the problem.

Ephemeral authentication does not remove standing authorization. Even when users authenticate interactively, the application may retain durable delegated rights through granted scopes. That creates an identity blast radius that is larger than the login event suggests. The correct control objective is not simply preventing sign-in abuse, but limiting how far a consented app can move after authentication.

Microsoft OAuth exposes a runtime governance gap that many IAM programmes have not closed. The protocol is well understood, but operational ownership is often split between app teams, identity teams, and security operations. That split leaves consent reviews, redirect validation, and service principal monitoring under-managed. Practitioners should assign explicit ownership for OAuth NHI lifecycle controls before access drift becomes normal.

Delegated access needs the same offboarding discipline as any other privileged integration. If an app no longer needs access, the grant must be removed, the service principal reviewed, and any cached tokens invalidated where possible. Otherwise, the organisation keeps a trusted path open long after business need has ended. Teams should treat OAuth offboarding as a standard identity control, not an exception process.

From our research:

• 85% of organisations lack full visibility into third-party vendors connected via OAuth apps, according to The State of Non-Human Identity Security.
• Only 20% have formal processes for offboarding and revoking API keys, and even fewer have procedures for rotating them, according to the Ultimate Guide to NHIs.
• That combination of poor visibility and weak offboarding is why the Ultimate Guide to NHIs treats non-human lifecycle control as a core governance requirement, not an optional hygiene task.

What this signals

OAuth governance will increasingly be measured as part of identity exposure management, not application onboarding. As Microsoft estates accumulate more delegated apps, security teams need a repeatable way to identify which integrations can still act, what they can reach, and who approved them. The practical program shift is toward continuous consent review, not one-time deployment approval.

Delegated access is becoming an identity blast radius problem. If a single OAuth grant can expose mail, files, or directory data, then the size of that grant matters as much as the authentication method. Teams should prioritize visibility into service principals and app consents, because hidden trust paths tend to become the last control gap organizations notice.

Access review workflows need to move closer to runtime reality. In environments with many long-lived integrations, the gap between what was approved and what is still needed widens quickly. A mature programme will tie OAuth reviews to application ownership, data sensitivity, and offboarding checkpoints so that consent does not become permanent by default.

For practitioners

• Inventory OAuth apps as NHI assets Track every Microsoft OAuth application, its service principal, granted scopes, and owning team. Classify applications by data sensitivity and business criticality so reviews focus first on integrations with mail, files, security, or directory access.
• Enforce redirect URI and PKCE controls Restrict redirect URIs to exact, pre-registered endpoints and require PKCE for authorization code flows. Review browser-based clients for token exposure paths such as logs, history, and third-party scripts.
• Run recurring consent and scope reviews Revalidate delegated permissions on a fixed cadence, especially for multi-tenant apps and older integrations. Remove unused scopes, confirm business ownership, and revoke grants when the original purpose no longer exists.
• Separate public and confidential client risk handling Treat public clients as higher exposure because they cannot safely store secrets, then push sensitive exchanges to backend-controlled confidential clients where possible. Where public clients are unavoidable, narrow scopes and shorten trust windows.
• Build an OAuth offboarding process Document how to revoke consent, remove enterprise application entries, and invalidate long-lived access where supported. Include this in application retirement so OAuth access does not survive the business use case.

Key takeaways

• Microsoft OAuth is an identity governance problem because consented apps can hold durable delegated access.
• Short-lived tokens do not eliminate risk when refresh tokens, service principals, and consent grants remain active.
• Security teams should manage OAuth apps like other NHIs, with inventory, least privilege, review, and offboarding.

Key terms

• Service Principal: A service principal is the tenant-local identity that represents an application inside Microsoft Entra. It is the object that receives permissions, participates in authentication, and becomes the practical control point for app governance. In NHI terms, it is the application’s operational identity in a specific tenant.
• Delegated Access: Delegated access is permission for an application to act on a user’s behalf after consent has been granted. The app does not receive the user’s password, but it can still reach resources the user is allowed to access. That makes delegated access powerful and risky when scopes are broad or poorly reviewed.
• Refresh Token: A refresh token is a credential that lets an application obtain new access tokens without forcing the user to sign in again. It extends the life of an OAuth relationship and therefore extends exposure if the token is stolen or the grant is no longer needed. It must be treated as a sensitive secret.
• Redirect URI: A redirect URI is the pre-registered endpoint where the authorization server sends the browser after authentication. It is a critical trust boundary because the wrong URI, or a poorly protected one, can expose tokens or codes to unintended recipients. In OAuth security, exact matching and tight registration are essential.

Deepen your knowledge

OAuth consent, token handling, and service principal governance are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are formalising controls for Microsoft integrations, this is a practical place to start.

This post draws on content published by Oasis Security: OAuth 2.0 with Microsoft: Start Here. Read the original.