OAuth 2.0 with Microsoft: delegation, consent, and token risk

At a glance

What this is: This is a governance guide to Microsoft OAuth 2.0 that shows how delegated access, consent, scopes, redirect handling, and token type determine the real security boundary.

Why it matters: It matters because IAM and NHI teams often treat OAuth as plumbing, when the article shows it directly shapes standing access, revocation reach, and long-lived token exposure.

Context

Microsoft OAuth is a delegated access and authentication control plane, not just an application integration pattern. The security boundary is defined by app registration choices, consent handling, scopes, redirect URIs, and token storage, which means identity teams have to govern it as access policy rather than code wiring.

For Microsoft Entra ID, the same flow behaves differently for single-tenant and multi-tenant apps, public and confidential clients, and delegated versus application permissions. That makes OAuth a lifecycle issue as much as a protocol issue, because the initial grant, the service principal created in tenant scope, and the token validity window all affect how access persists.

Key questions

Q: What breaks when OAuth consent is treated like a one-time setup step?

A: Consent turns into standing delegated access when teams stop tracking scopes, owners, and tenant-specific service principals after approval. The result is access that outlives the business need and becomes difficult to review, revoke, or explain during governance checks.

Q: Why are refresh tokens riskier than access tokens after compromise?

A: Access tokens are usually short-lived, so their damage window is limited. Refresh tokens can mint new access tokens repeatedly, which means possession can preserve access for months or longer. That makes the refresh token the persistence mechanism and the access token only the temporary execution credential.

Q: What are the signs that an OAuth integration is being overused or behaving outside its intended purpose?

A: Look for integrations that access data continuously when the business use case only needs occasional access, or that touch multiple users’ files, calendars, or mailboxes far beyond expected workflow limits. A useful signal is the gap between declared purpose and observed activity in logs. If an app is synchronizing broad content or making repeated high-value API calls, its real risk is higher than its stated function.

Q: How should teams govern OAuth app access in Microsoft environments?

A: Teams should treat every consented app as a governed identity with an owner, a purpose, a scope set, and a revocation path. That means reviewing granted permissions regularly, tracking tenant-specific service principals, and aligning offboarding with the app lifecycle rather than with user sign-in alone.

Technical breakdown

Delegated access and consent create the real access boundary

OAuth delegated access means the app acts on behalf of a signed-in user, but only within the scopes that the user has approved. In Microsoft’s model, consent creates a service principal in organizational tenants and binds the app’s access to the granted permissions. That boundary is not fixed at registration time alone, because the effective privilege comes from the combination of audience, scopes, and who approved them. For IAM teams, that means the trust decision lives in the consent event and the resulting tenant object, not just in the application code.

Practical implication: inventory delegated grants and treat consented service principals as governed identities, not passive app metadata.

Token type and lifetime shape exposure after initial access

OAuth issues different credential types for different purposes. Access tokens authorize API calls, refresh tokens extend access after the first grant, and ID tokens validate identity for sign-in use cases. The security problem is not merely issuance, but persistence: refresh tokens can maintain access long after the user forgets the app, while access tokens cannot be revoked once issued. That creates a governance gap between the moment of approval and the later moment of discovery or review. In NHI terms, the token becomes the operative credential, even when the original human consent is stale.

Practical implication: separate short-lived access from long-lived refresh token governance and monitor where refresh tokens are stored and reused.

Redirect URIs and flow choice decide where token theft becomes feasible

The redirect URI is the browser handoff point where the authorization server returns the result of the OAuth flow. In implicit flow, tokens can arrive directly in the browser, which increases exposure if scripts, browser history, or third-party code can see them. Authorization code flow is safer because the app exchanges a short-lived code, ideally with PKCE, rather than receiving the access token immediately. The distinction matters because flow selection changes the attack surface: browser-visible tokens, code interception, and weak redirect registration all influence whether consented access can be abused outside the intended session.

Practical implication: prefer authorization code flow with PKCE and tightly registered redirect URIs wherever browser-exposed token handling is avoidable.

Threat narrative

Attacker objective: The objective is durable delegated access to Microsoft resources through tokens and consent rather than direct password theft.

1. Entry occurs when a user is steered into granting consent to a Microsoft OAuth application with scopes that look routine but are broader than the user realises.
2. Credential access follows when the application receives access tokens and, in some cases, refresh tokens that can be reused to call Microsoft APIs on the user’s behalf.
3. Escalation happens when stored tokens, permissive scopes, or multi-tenant reach let the application continue operating after the original sign-in moment.
4. Impact is unauthorized persistence of delegated access across mail, calendar, files, or other Microsoft resources until grants are reviewed and removed.

Breaches seen in the wild

• CoPhish OAuth phishing via Copilot Studio: Datadog showed Copilot Studio agents on a Microsoft domain can front OAuth consent phishing and forward stolen tokens; no victims reported.
• Taiwan autonomous AI agent cyberattack 2026: Up to eight autonomous AI agents cracked 85 Taiwanese government accounts, pivoted through SSO and exfiltrated 2,564+ personnel records.

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

NHI Mgmt Group analysis

Consent is the control event, not a paperwork event. In Microsoft OAuth, the user’s approval creates the access path that matters operationally, because that approval materialises into a tenant-scoped service principal and granted scopes. Organisations that treat consent as a one-time setup step miss the fact that it is a standing delegated-access grant with lifecycle consequences. The practitioner implication is that consent needs the same governance attention as any other privileged access event.

Long-lived token exposure is the hidden NHI risk in OAuth. Access tokens may be short-lived, but refresh tokens and stored browser tokens extend the attack window well beyond the original authentication moment. That means the real asset is not the app registration alone, but the token-bearing identity state created by the flow. Teams should read OAuth through the lens of NHI lifecycle governance, because the credential lives longer than the login that created it.

Redirect handling defines whether OAuth stays a controlled handoff or becomes a browser-side exposure. Implicit flow, weak redirect registration, and token handling in page context all widen the places where credentials can leak or be reused. This is where NHI governance meets application security: a delegated identity is only as safe as the redirect and storage choices around it. The practitioner implication is that flow design belongs in identity review, not just development review.

Microsoft OAuth is a governance system for delegated machine actions, not just a sign-in protocol. The article’s core lesson is that scopes, audiences, service principals, and token lifetime together define who or what can act in Microsoft environments. That collapses the old assumption that identity governance ends at human authentication. The implication is that IAM programmes must govern consented non-human access with the same seriousness as workforce access, but through different controls and evidence.

From our research library:

• Security researchers tracked consent phishing campaigns affecting 900 tenants and 3,000 user accounts in 2025.

What this signals

Consent governance is the missing boundary in many Microsoft OAuth programmes. The practical control point is not the app registration alone but the consented service principal and its scopes. That means review and revocation processes need to track who approved access, what was approved, and whether the resulting delegated identity is still justified.

OAuth becomes an NHI lifecycle problem once refresh tokens enter the picture. A user can leave, forget, or rotate their credentials, yet the app can continue acting with issued tokens until those tokens are explicitly removed or expire. Programmes that do not inventory refresh token persistence are leaving a long-lived non-human access path ungoverned.

Redirect URI discipline is a security boundary, not a developer preference. When the browser carries tokens or authorization codes through loosely controlled endpoints, the flow inherits the risk of the surrounding web application. Identity teams should make redirect registration and token-handling review part of architecture approval, especially for Microsoft-integrated applications.

For practitioners

• Audit tenant-scoped consent grants Review enterprise applications and user-granted permissions to identify service principals that have accumulated delegated access beyond their current business need.
• Restrict browser-exposed token handling Prefer authorization code flow with PKCE for web applications and avoid designs where access tokens or refresh tokens are exposed to page scripts or browser storage.
• Tighten redirect URI registration Allow only pre-registered redirect URIs and verify that each URI matches the actual application origin and flow type in use.
• Review refresh token persistence Locate where refresh tokens are stored, how long they remain valid, and which applications can continue using them after the original user session ends.

Key takeaways

• OAuth in Microsoft environments is really about delegated access governance, because consent, scopes, and tenant-scoped service principals define the real access boundary.
• Token lifetime matters as much as initial sign-in, since refresh tokens and stored browser tokens can keep access alive after the user no longer expects it.
• Authorization code flow with PKCE and tightly controlled redirect URIs reduce exposure, while browser-visible token handling expands it.

Key terms

• Delegated Access: Delegated access is permission granted to one identity to act on behalf of another user, service, or system. In NHI environments, this usually appears in OAuth-connected apps and automation tooling. It is powerful, but it must be tightly scoped and reviewed because it can persist long after the original business need ends.
• Service Principal: An application identity object in Microsoft Entra ID and Microsoft 365 that represents a specific app inside a tenant. It holds permissions, ownership, and configuration data that define what the application can do. In NHI governance, it is a high-value identity that should be reviewed like any other privileged account.
• Refresh Token: A longer-lived credential that can mint new access tokens without forcing the user to authenticate again. Because refresh tokens can preserve access for extended periods, they are a major governance concern when malicious or over-scoped applications are granted consent.
• Redirect URI: A redirect URI is the endpoint where an authorization server sends the user back after a login or consent step. In secure OAuth implementations, it must be pre-registered and matched exactly so an attacker cannot divert the response to a malicious destination.

Deepen your knowledge

NHI governance, identity lifecycle management, and secrets management are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.