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

At a glance

What this is: A Microsoft OAuth primer that explains delegated access, consent, tokens, and the security implications of app registration choices.

Why it matters: It matters because OAuth settings directly affect how NHI and human identity boundaries are enforced, reviewed, and revoked across enterprise applications.

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

Context

OAuth becomes an identity governance problem when applications can act on a user's behalf without a matching lifecycle model for consent, token validity, and revocation. In Microsoft environments, the practical question is not whether OAuth works, but how much delegated access it creates and how long that access can persist.

This is especially relevant for NHI programmes because OAuth apps, service principals, access tokens, and refresh tokens all create machine-access paths that often outlive the user action that created them. For IAM teams, the core issue is visibility into who granted what, where tokens are stored, and how permissions are removed when applications are no longer needed.

Key questions

Q: How should security teams govern Microsoft OAuth apps that act on behalf of users?

A: Treat each consented application as a governed identity with an owner, an approved scope set, and a removal path. Review the service principal, the tenant in which it exists, and the permissions it has received. If the app cannot be tied to a business purpose and offboarding process, the access is not properly governed.

Q: Why do OAuth tokens create long-lived identity risk in enterprise environments?

A: Because token lifetime and refresh mechanics can outlast the original sign-in event. Even when the access token is short-lived, a refresh token or stored credential can extend access beyond the user interaction that granted it. The risk grows when tokens are stored in browsers, logs, shared code, or other exposed locations.

Q: What breaks when redirect URIs and token storage are not tightly controlled?

A: The token handoff becomes a leakage point. If the redirect URI is weakly managed or if code running in the browser can access returned tokens, the application may expose credentials to malicious scripts, browser history, or unintended recipients. In practice, the trust boundary shifts from the identity provider to the app implementation.

Q: What is the difference between delegated access and application access in OAuth governance?

A: Delegated access acts on behalf of a signed-in user and is bounded by that user's entitlements, while application access is direct app-to-resource access with broader organisational reach. Governance must distinguish them because delegated permissions still create durable machine access paths that require lifecycle review and revocation.

Technical breakdown

Delegated access, scopes, and consent boundaries

OAuth separates authentication from authorisation. In Microsoft, scopes define the permissions an app requests, while user consent turns those requested permissions into effective delegated access. That access is bounded by the user's own entitlements, but it can still be broad if the consented scopes are broad. Service principals represent the application inside an organisation tenant, which means the identity object must be governed like any other enterprise access path, not treated as a one-time setup artifact.

Practical implication: Review consented scopes and service principals as governed identities, not configuration details.

Redirect URIs, token returns, and attack surface

The redirect URI is the browser handoff point that returns tokens, codes, or identity assertions to the application after sign-in. If that URI is weakly controlled, misregistered, or exposed to hostile page logic, the token exchange can become a leakage point. The article also distinguishes access tokens, ID tokens, refresh tokens, and authorization codes, each with different lifetimes and handling requirements. Token storage discipline matters because tokens written to logs, browser history, or shared page memory become reusable credentials.

Practical implication: Lock down redirect handling and token storage as part of application security review.

OAuth flows and client types change the trust model

Implicit, authorization code, and hybrid flows do not create equal risk. Public clients operate in environments where code and tokens are exposed to the user device, while confidential clients can protect secrets on a backend server. PKCE improves the authorization code flow by binding the exchange to the original client session, reducing interception risk. The important security point is that the same OAuth vocabulary can describe very different operational trust models depending on where tokens are issued, stored, and redeemed.

Practical implication: Map each app to its actual client type and flow before approving OAuth access.

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 consent is an access governance event, not a user convenience step. In Microsoft environments, consent creates durable delegated access that can persist well beyond the moment of approval. That means the governance problem is not the sign-in itself but the lifecycle attached to the permission grant. IAM teams should treat every consented application as an identity relationship that needs ownership, review, and eventual removal.

Service principals are the enterprise control point for OAuth applications. The article makes clear that organisation tenants create service principals for consented apps, which means app access becomes a tenant-managed identity object. That shifts OAuth from a development concern into NHI governance territory. Practitioners should be reviewing these principals with the same seriousness they apply to other non-human identities.

Redirect handling exposes a token boundary that many programmes still under-govern. Redirect URIs, authorization codes, and token exchange mechanics are where browser-mediated trust becomes real. If the application, browser session, or page context is weak, the control boundary moves from Microsoft to the app implementation itself. Security teams need to recognise that OAuth is only as strong as the redirect and storage path that carries its credentials.

Token lifetime creates the real risk window, not the initial login event. Access tokens, refresh tokens, and offline access introduce different persistence horizons, and those horizons matter more than the sign-in ceremony. A short-lived token can still enable meaningful access if refresh or storage controls are weak. This is why OAuth governance must focus on revocation, inventory, and storage, not just interactive authentication.

OAuth security is increasingly NHI security by another name. The article's concepts map directly to machine access governance because applications, service principals, and refresh tokens behave like non-human identities with delegated authority. The field should stop treating OAuth as a web-app integration topic and start treating it as part of enterprise identity control design. Practitioners who do that will close the gap between app registration and access governance.

From our research:

• 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.
• 96% of organisations store secrets outside of secrets managers in vulnerable locations including code, config files, and CI/CD tools.
• OAuth lifecycle governance belongs in the same operational category as secret handling, so the Ultimate Guide to NHIs is the right reference point for building revocation discipline.

What this signals

OAuth is a useful reminder that many enterprise identity risks now live in delegated machine access rather than primary human login journeys. With 96% of organisations storing secrets outside of secrets managers in vulnerable locations including code, config files, and CI/CD tools, the control problem is as much about access persistence as it is about authentication design.

Delegated-access drift: when consented applications accumulate scopes over time, the risk is not a single bad grant but a gradually expanding permission boundary. IAM teams should watch for consent sprawl, unactioned service principals, and refresh-token persistence as the signs that OAuth governance has become operationally weak.

For practitioners, the next step is to align app registration review, token storage policy, and offboarding workflows into one lifecycle model. That approach fits naturally with Zero Trust Architecture and the broader identity governance discipline described in NIST SP 800-63 Digital Identity Guidelines.

For practitioners

• Inventory consented applications and service principals Build a tenant-wide view of apps that have delegated access, then reconcile each entry to an owner, business purpose, and removal path. Use enterprise application and consent reporting to find orphaned or over-broad app permissions.
• Review scopes before approving multi-tenant access Compare requested scopes against the application’s actual use case, especially when an app supports both private accounts and organisations. Flag any permission set that exceeds the minimum required for the business workflow.
• Harden redirect URI and token handling Require pre-registered redirect URIs, avoid token exposure in browser history or logs, and ensure browser-side code cannot read credentials it does not need. Treat token storage as a privileged design decision rather than a convenience detail.
• Separate public-client and confidential-client review paths Assess SPA and server-side implementations differently because their token protection assumptions are not the same. Public clients need stricter scrutiny of token exposure in the browser, while confidential clients need controls around server secret storage and refresh token retention.
• Test revocation and offboarding for OAuth access Verify that access can be revoked when an application is retired, a user leaves, or a tenant relationship changes. Confirm both token invalidation and service principal cleanup so access does not persist after the business need ends.

Key takeaways

• OAuth in Microsoft environments is an identity governance issue because consented applications become durable access relationships, not one-time events.
• The biggest risk is not the login flow itself but the persistence path created by tokens, refresh mechanisms, and poorly governed service principals.
• Teams should govern OAuth apps like non-human identities, with explicit ownership, scope review, revocation testing, and token-handling controls.

Key terms

• Delegated Access: Delegated access is when an application acts on a user's behalf after the user grants permission. In Microsoft OAuth, that permission becomes an enduring access relationship that must be owned, reviewed, and revoked like any other non-human access path.
• Service Principal: A service principal is the tenant-local identity that represents an application inside an organisation. It is the control object that lets IAM teams assign, review, and remove application permissions, which makes it central to OAuth governance.
• Refresh Token: A refresh token is a long-lived credential used to obtain new access tokens without repeated user interaction. It extends access beyond the original login moment, so storage, revocation, and expiration policy are critical to controlling its risk.
• Redirect URI: A redirect URI is the registered destination where an identity provider sends the browser after authentication. It is a security boundary because it carries the handoff for codes or tokens, and any weakness in registration or handling can expose credentials.

Deepen your knowledge

OAuth consent, scopes, and token handling are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building governance for delegated app access in Microsoft environments, it is worth exploring.

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