TL;DR: OAuth with Microsoft is not just an authentication pattern. It is a delegated access model that depends on scopes, consent, redirect handling, token storage, and tenant-specific service principals, according to the source article from Oasis Security. That makes OAuth governance an IAM and NHI control problem, not only an application integration concern.
At a glance
What this is: This is a technical guide to OAuth 2.0 with Microsoft that shows how delegated access, consent, service principals, tokens, and redirect handling fit together.
Why it matters: It matters because practitioners must govern OAuth as an access lifecycle and token risk problem, not just an application login pattern, especially where Microsoft tenants and delegated permissions are involved.
Context
OAuth 2.0 with Microsoft is not just about signing users in. In this model, the application is granted delegated access to resources through scopes, consent, tokens, and tenant-specific identities, which means the real governance challenge is how permission is issued, stored, and later reviewed.
The article is useful because it connects application integration to identity control points that security teams already own: app registration, service principals, redirect URIs, and token handling. That makes it directly relevant to IAM, NHI governance, and OAuth risk management in Microsoft-heavy environments.
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 do delegated OAuth permissions increase identity risk in Microsoft tenants?
A: Because delegated scopes bind application behaviour to the permissions of the consenting user or tenant, not to a fixed application-only boundary. That creates a governance problem when apps accumulate broad scopes, remain consented after their use case changes, or are reused across multiple tenants.
Q: What are the signs that OAuth consent governance is failing?
A: Common signs include broad scopes granted to unfamiliar applications, app registrations that survive beyond their business purpose, and consent events that are logged but not acted on. If reviewers only see the abuse in hindsight, governance is too slow for the risk level. The control needs policy, not just audit trails.
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 in OAuth 2.0 with Microsoft
Delegated access means an application acts on a user's behalf after the user grants consent to specific scopes. In Microsoft environments, that consent creates a permissions boundary that is tenant-aware, app-specific, and shaped by the chosen sign-in audience. The important governance point is that OAuth does not hand over a password, it hands over an authorisation grant that can outlive the initial session through refresh tokens and retained consent.
Practical implication: review delegated permissions as standing access and treat consent as an access grant that requires lifecycle oversight.
Service principals, app registrations, and tenant scope
A Microsoft app registration creates an application identity, while a service principal represents that application inside a tenant after consent is granted. That distinction matters because the same app can behave differently across tenants, and administrators must govern the local instance rather than only the global app registration. Multi-tenant configurations expand the governance surface because one application definition can generate many tenant-specific identities and permission states.
Practical implication: inventory service principals by tenant and correlate each one to its granted scopes and approver.
Token handling, redirect URIs, and flow choice
OAuth flow selection changes where tokens are handled and therefore where exposure risk sits. Implicit flow returns tokens directly to the client, while authorization code flow uses a code exchange and PKCE to reduce interception risk. Redirect URIs must be pre-registered because they determine where the browser sends the authorization response, and weak token storage can expose access through logs, browser history, or third-party code in the same page.
Practical implication: validate redirect URIs, require PKCE where applicable, and keep tokens out of browser-visible storage and logs.
Threat narrative
Attacker objective: The attacker wants durable delegated access to Microsoft resources that looks legitimate to users and administrators while enabling ongoing token-based abuse.
- Entry occurs when a user is prompted to consent to an OAuth application requesting access to Microsoft resources on their behalf.
- Privilege is established when the app receives delegated scopes through the consented service principal and can act within those permissions.
- Escalation can occur when refresh tokens, broad scopes, or poor token storage extend access beyond the intended interaction boundary.
- Impact is unauthorized reading or use of mailbox, calendar, or tenant resources under the appearance of legitimate delegated access.
Breaches seen in the wild
- Microsoft verified publisher OAuth phishing 2022: Malicious OAuth apps with a fraudulently obtained Microsoft verified publisher badge tricked UK users into granting mailbox access in 2022.
- 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.
Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
Delegated access is an access-control model, not just an authentication pattern. Once an app receives consented scopes, it becomes a governed identity plane that must be treated like any other non-human access path. In Microsoft environments, the core question is not whether the user signed in successfully but whether the granted scope is still appropriate for the tenant, the app, and the data. Practitioners should evaluate OAuth as part of IAM, not as a peripheral integration detail.
OAuth consent creates service-principal sprawl unless the tenant governs it deliberately. Every tenant-specific service principal is a separate enforcement point with its own permission history and operational risk. That means inventory, ownership, and approval tracking are not optional administration tasks but part of access governance. Practitioners need to understand that one app registration can translate into many local identities with different risk profiles.
Token lifetime is the hidden control boundary in Microsoft delegated access. Access tokens may be short-lived, but refresh tokens, cached consent, and long-lived application configuration can preserve access far beyond the original sign-in event. That shifts the governance burden from login events to issuance, storage, and revocation. Practitioners should manage OAuth as a lifecycle problem, not a session-only problem.
Redirect integrity and token storage are where many delegated-access assumptions break down. A correct OAuth design can still fail if redirect handling is loose or if tokens are available to browser code, logs, or other local components. The issue is not the protocol itself but the deployment choices around it. Practitioners should treat browser-exposed token handling as a control boundary and not as a minor implementation detail.
Consent review needs to be part of NHI governance because OAuth grants behave like standing entitlements. The article’s substance shows that delegated permissions can persist, accumulate, and be reused without fresh human review. That places OAuth inside the same governance conversation as service-account sprawl, privileged access review, and application offboarding. Practitioners should align OAuth oversight with lifecycle governance rather than app onboarding alone.
From our research library:
- Security researchers tracked consent phishing campaigns affecting 900 tenants and 3,000 user accounts in 2025.
What this signals
Delegated OAuth access needs lifecycle governance, not just secure authentication design. Once an app has consented scopes, the risk profile is determined by how long those grants remain valid, where tokens are stored, and whether the tenant can still explain why the access exists. Practitioners should manage OAuth grants as identity assets with ownership and offboarding requirements.
Service principal sprawl is the governance blind spot in Microsoft-centric OAuth estates. A single app registration can produce many tenant-local identities, each with its own permission state and review burden. That means the operational question is not whether OAuth works, but whether the organisation can continuously account for every granted instance.
OAuth redirect and token controls sit at the boundary between identity governance and application security. When redirect URIs are loose or tokens are exposed to browser-visible components, the protocol’s security model is weakened by implementation choice rather than by the abstract standard itself. Practitioners should place those checks inside their access governance programme, not outside it.
For practitioners
- Review delegated scopes as standing access Map every consented Microsoft application to the scopes it holds, the user or tenant that granted them, and the data those scopes can reach. Revoke any grant that no longer matches the business purpose or tenant ownership.
- Inventory tenant-specific service principals List service principals in each tenant, confirm which applications they represent, and tie each one to an owner and approval record. This helps reveal duplicate consent states and orphaned application identities.
- Harden redirect URI handling Restrict redirect URIs to pre-registered values only, verify they match the intended app flow, and avoid broad patterns that can route tokens to unintended endpoints.
- Reduce token exposure in client code Keep access tokens and refresh tokens out of logs, browser history, and third-party scripts running in the same page. Prefer server-side handling where the application design allows it and review client-side storage paths carefully.
Key takeaways
- OAuth in Microsoft environments is a delegated access model that creates real governance obligations around scopes, consent, and service principals.
- The main risk is not login failure but persistent authorisation that remains valid after the original user interaction has ended.
- Teams should focus on consent review, token handling, redirect integrity, and tenant-level ownership to keep delegated access under control.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 and MITRE ATT&CK address the attack and risk surface, while NIST SP 800-53 Rev 5, NIST CSF 2.0 and CSA Cloud Controls Matrix set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-04 — Insecure Authentication | OAuth consent, redirect handling, and token exchange are core authentication trust points in this article. |
| NHI-05 — Overprivileged NHI | The article centres on scopes that can exceed the minimum necessary delegated access. | |
| NHI-07 — Long-Lived Secrets | Refresh tokens and stored credentials can preserve access long after the original sign-in event. | |
| Recommendation — Audit OAuth flows for weak authentication handling and require PKCE where browser-based clients are involved. Review consented scopes against least-privilege expectations and remove broad or stale delegated permissions. Limit token persistence, restrict storage locations, and shorten exposure windows where possible. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Token and credential lifecycle management is central to the article's control model. |
| Recommendation — Apply IA-5 to govern token issuance, storage, revocation, and expiry across OAuth integrations. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | The article focuses on reviewing and governing granted permissions and entitlements. |
| Recommendation — Use PR.AA-05 to inventory and review delegated permissions, app owners, and tenant-level authorizations. | ||
| CSA Cloud Controls Matrix | IAM — Identity and Access Management | Microsoft OAuth delegated access is fundamentally an identity and access governance issue in cloud tenants. |
| Recommendation — Apply IAM governance to service principals, app consent, and tenant-local delegated access states. | ||
| MITRE ATT&CK | TA0006 — Credential Access | Consent phishing and token abuse are central threat patterns discussed in the source and related incidents. |
| Recommendation — Map OAuth abuse to TA0006 and hunt for token theft, consent abuse, and unauthorized app grants. | ||
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.
- 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.
- 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.
Deepen your knowledge
NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.
Published by the NHIMG editorial team on May 31, 2026.
Updated on October 6, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org