OAuth 2.0 application consent: the silent back-door into your enterprise tenant

The consent prompt is the security boundary

Illicit consent attacks exploit an authorization decision: a malicious application tricks someone into granting access to organizational data. Microsoft documents that, by default, users can consent to permissions that do not require administrator approval. That can include mailbox access, but not unfettered read and write access to all organizational files. The practical distinction matters: user consent is not unrestricted tenant access, yet an allowed permission can still expose valuable information. Review consent separately from whether a sign-in succeeds.

Hypothetical example: an employee approves a supposed productivity tool that requests mailbox access. The review question is whether that application needs the access for an approved business purpose, not simply whether the employee authenticated successfully. NIST distinguishes authentication from authorization and rejects implicit trust based on network location or ownership. Apply that principle to application onboarding: require a reason for resource access, and assess the requested permissions rather than treating a familiar sign-in experience as sufficient assurance.

Evidence: Configure how users consent to applications, Zero Trust Architecture

Restrict consent without confusing verification with approval

Microsoft recommends restricting user consent to applications from verified publishers. Its built-in microsoft-user-default-low policy allows limited consent for verified-publisher applications and applications registered in your tenant, but only for permissions you classify as low impact. Classification is therefore a required configuration step, not an automatic assessment supplied by the policy. Recommended practice: keep that classification narrow and treat publisher verification as an eligibility condition, not a substitute for reviewing the application's purpose, requested access, and business owner.

Start policy changes by retrieving the current authorization policy and assigned permission grant policies. Microsoft distinguishes tenant-wide authorization settings from grant policies with inclusion and exclusion conditions, and warns administrators to preserve existing owned-resource policies when changing user consent. Applications requiring user assignment need administrator consent even where user consent would otherwise be allowed. Configuration also has role requirements: the admin center requires Global Administrator, while the documented programmatic approach requires Privileged Role Administrator. Plan the change accordingly.

Evidence: Configure how users consent to applications

Audit authorization models, not just permission names

Do not stop an audit at labels such as Mail.ReadWrite or Files.ReadWrite.All. Recommended review fields include the target API, actual grant, delegated or application access, approving authority, and business justification. Microsoft documents that client credentials uses the application's own identity, with no user involved; delegated permissions cannot serve that flow. Application permissions can authorize reading or writing all mailboxes, sending mail as any user, or reading directory data. Evaluate those capabilities explicitly rather than approving a recognizable name.

Custom APIs need additional scrutiny. Microsoft documents that app-only tokens can be issued without a roles claim to support resource-side access control lists. An absent roles claim therefore does not prove the application lacks access. Review the API's permission checks and, for ACL authorization, validation of both appid and a trusted iss value. Assignment requirements can block role-less app-only token issuance for that application. Also review credential protection: client credentials supports certificates or federated credentials, and never issues refresh tokens.

Evidence: Microsoft identity platform and the OAuth 2.0 client credentials flow

Follow downstream access, then record a decision

Next, trace middle-tier and downstream APIs. Microsoft's on-behalf-of flow passes user identity and permissions through a request chain, uses delegated scopes rather than application roles, and presents downstream consent upfront because the middle tier has no user interaction. It works only for user principals; app-only access needs client credentials instead. Review token audiences and reject tokens intended for another API. Preserve another documented limitation: middle-tier applications with custom signing keys, including enterprise SSO applications using those keys, cannot use OBO.

Finish with a repeatable approval sequence: establish the business owner, verify publisher eligibility, inspect grants and downstream dependencies, then compare each capability with the stated task. For requests outside your user-consent policy, establish a documented administrator review process; this is a governance recommendation, not a claim that changing consent settings creates that workflow. Record approval, rejection, or required permission reduction. Revisit existing grants separately, and do not treat a restrictive policy or verified publisher as an automatic security guarantee.

Evidence: Configure how users consent to applications, Microsoft identity platform and the OAuth 2.0 client credentials flow, Microsoft identity platform and OAuth 2.0 On-Behalf-Of flow