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.
Why delegated OAuth scopes raise the risk profile in Microsoft tenants
Delegated permissions are risky because they inherit the signed-in user’s authority and keep working until consent is reviewed or revoked. In Microsoft tenants, that makes scope choice, tenant-wide consent, and post-consent governance part of the security boundary. The app may be benign today and overreaching tomorrow, especially if it is reused, repurposed, or left with broad Graph access.
Delegated scopes also blur accountability. A user may grant access once, but the app can continue acting across mail, files, directory objects, or other tenant data that the user can reach. That creates a larger blast radius than teams often expect, because the application’s practical power is tied to the user’s standing access and the tenant’s consent posture.
For the protocol mechanics behind this, RFC 6749: The OAuth 2.0 Authorization Framework defines the delegated model that Microsoft builds on, while OpenID Connect Core 1.0 explains how identity assertions are layered on top when the tenant also relies on sign-in context.
Where the risk comes from in Microsoft consent and app governance
The main exposure is not OAuth itself, but the way delegated consent can be accumulated, forgotten, and overextended. If an app receives broad scopes such as mailbox, profile, files, or directory read permissions, the tenant has effectively extended trust to that app wherever the consenting identity has access. That is especially sensitive when admins approve consent for convenience, because the permission can outlive the original business need.
Tenant reuse is another pressure point. An app that is legitimate in one business unit can be reused in another tenant or by another team with a different risk tolerance, different data sensitivity, and different review discipline. A Microsoft tenant therefore needs to treat delegated scopes as governed access relationships, not as a one-time developer decision.
Guidance for secure OAuth design, including tighter token handling and reduced replay exposure, is well covered in RFC 9700: Best Current Practice for OAuth 2.0 Security. For practitioners managing delegated access at scale, RFC 8693: OAuth 2.0 Token Exchange is relevant where delegation and impersonation need tighter audience control than broad standing consent.
Microsoft-specific governance patterns also matter here: enterprise consent policies, app registration review, and admin consent workflows determine whether delegated access stays bounded or silently expands. If those controls are loose, the tenant ends up with a standing trust relationship that is hard to see and harder to unwind.
What good delegated-permission governance looks like
Good practice is to inventory apps by granted scopes, not by app name alone. The question is whether the scope set still matches the current business purpose and whether the app still needs user-delegated access at all. In many tenants, the right answer changes after the first deployment, when the app is no longer in active use but remains consented.
OWASP Non-Human Identity Top 10 is useful here because delegated app access often becomes an identity-governance problem once consented access, secret hygiene, and overprivilege are ignored. Where the app is part of a broader machine-to-machine or delegated system, the same discipline should be applied to scope minimisation and tenant ownership.
Microsoft tenants also benefit from pairing consent review with conditional checks on the identity that granted it. If the consenting user is highly privileged, if the app reaches sensitive mail or directory data, or if consent was granted tenant-wide, the app should be treated as a higher-risk trust path. That is where Privileged Access Management Guide becomes a useful lens for constraining standing privilege and Authorisation Models Guide helps teams think about finer-grained policy rather than broad blanket consent.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP API Security Top 10 addresses the attack surface, NIST SP 800-53 Rev 5 sets the technical controls, and ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | AC-2 — Account Management | Delegated app access needs lifecycle review of who can grant and retain permissions. |
| AC-6 — Least Privilege | Broad delegated scopes expand what the app can do on behalf of the user. | |
| IA-5 — Authenticator Management | Consent often relies on tokens and secrets that must be controlled across lifecycle. | |
| Recommendation — Review and remove stale consented access on a defined recertification schedule. Restrict app scopes to the minimum permissions needed for the use case. Rotate and protect credentials or tokens tied to delegated access paths. | ||
| ISO/IEC 27001:2022 | A.5.15 — Access control | Delegated scopes are an access-control decision that must be governed and reviewed. |
| Recommendation — Define approval, review, and revocation rules for delegated app access. | ||
| OWASP API Security Top 10 | API5 — Broken Function Level Authorization | Apps with delegated scopes can overreach into functions users should not expose. |
| Recommendation — Constrain app actions so delegated tokens cannot invoke unauthorized functions. | ||
Practitioner Guidance
What to prioritise: Start with the apps that have tenant-wide consent, high-value Graph scopes, or access through privileged users. Those are the combinations most likely to turn a routine consent into a durable identity risk.
What to verify: Confirm who approved the app, which scopes were granted, whether the app still has an active business owner, and whether the current scope set is still justified. If ownership is unclear, treat the consent as stale until proven otherwise.
Common mistake: Treating delegated permissions as a developer concern instead of a tenant governance concern. In practice, the risk sits with the tenant because the tenant decides what can be consented, retained, and reviewed.
Practitioner takeaway: The security question is not whether OAuth is delegated, but whether delegated access is still intentionally bounded, actively owned, and periodically re-validated against the tenant’s real data and privilege exposure.