Because MFA and passkeys validate the user at sign-in, but they do not automatically control what the user can delegate to an application after authentication succeeds. If consent policy is permissive, a trusted login can still produce untrusted portable authority. The control gap sits at grant time, not at the password prompt.
Why the login can be strong while the grant is still weak
oauth consent abuse exploits a different control point than MFA or passkeys. Strong authentication proves who signed in, but consent decides what that signed-in user is allowed to delegate to an application. If the application request is broad, unclear, or socially engineered, a legitimate login can still produce an overpowered token or delegated grant.
That is why phishing-resistant sign-in improves the front door but does not, by itself, close the authorization gap created at consent time. The weakness is not that the user was impersonated during authentication. The weakness is that a real user can be induced to approve access that exceeds what the business intended them to hand out.
How OAuth consent turns trust into portable authority
OAuth is built to let a user authorize a client to act on their behalf, and that delegation can be highly useful when the scope is narrow and well governed. Problems begin when the consent screen, app trust model, or admin policy allows broad permissions, obscure scopes, or repeated re-consent. In that case, the application does not need to defeat MFA again, because the delegated access already exists.
That distinction matters operationally. A passkey can stop credential theft, replay, and many phishing paths, but it does not evaluate whether the requested scopes are excessive, whether the app is trustworthy, or whether the user understands the downstream data and action reach of the grant. The control failure is authorization design, not primary authentication quality.
Open standards such as RFC 6749: The OAuth 2.0 Authorization Framework define the delegation model, while RFC 9700: Best Current Practice for OAuth 2.0 Security reflects the need to harden deployments against token misuse and weak authorization decisions.
What defenders should harden when consent, not sign-in, is the attack path
The right control focus is to reduce what a user can accidentally or deliberately delegate. That means tightening consent policy, limiting user-installed apps, preferring admin approval for high-risk scopes, and reviewing whether each scope is truly necessary for the business function. For resource servers, scope design should be narrow enough that a single grant does not become a durable broad foothold.
In practice, the most useful verification question is not “Did the user authenticate strongly?” but “What authority did the app receive after authentication, and can that authority be abused outside the user’s original intent?” If the answer is yes, consent governance needs to be treated as a separate security control family.
Guidance in NIST SP 800-63 Digital Identity Guidelines reinforces strong authenticator choices, but the grant problem remains an authorization and delegation issue. For application-side controls, RFC 8707: Resource Indicators for OAuth 2.0 helps narrow where tokens can be used, which reduces the blast radius of a granted token.
Risk and Threat Considerations
OAuth consent abuse is risky because it converts a successful sign-in into a durable delegated foothold. An attacker does not need to bypass MFA if they can persuade a legitimate user to approve a malicious or overbroad application, then use the resulting token or grant to access mail, files, profile data, or downstream APIs.
Failure mechanism: The attack succeeds when the consent prompt is more permissive than the organisation’s security intent, allowing a legitimate user to authorize an application with excessive or poorly understood scopes.
Impact: The resulting delegation can enable persistent data access, lateral abuse of connected services, and token-based activity that looks legitimate unless consent events and application grants are monitored closely.
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 and risk surface, while NIST SP 800-63, NIST SP 800-53 Rev 5 and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-63 | Digital Identity Guidelines | Strong authentication must be paired with secure delegation decisions in OAuth flows. |
| Recommendation — Use phishing-resistant authenticators, but separately govern consent and delegated access. | ||
| NIST SP 800-53 Rev 5 | AC-6 — Least Privilege | Consent abuse is amplified when applications receive more access than needed. |
| IA-5 — Authenticator Management | Passkeys and MFA strengthen login, which is only one half of the OAuth trust chain. | |
| Recommendation — Restrict delegated access to the minimum scopes required for the task. Maintain strong authenticators while enforcing separate authorization checks for consent. | ||
| OWASP API Security Top 10 | API5 — Broken Function Level Authorization | Broad delegated scopes can expose functions a user should not be able to hand out. |
| API6 — Unrestricted Access to Sensitive Business Flows | Consent abuse often unlocks sensitive workflows through legitimate-looking grants. | |
| Recommendation — Verify that token-granted functions remain constrained to approved roles and scopes. Limit delegated tokens from reaching sensitive business flows without extra approval. | ||
| CIS Controls v8 | CIS-6 — Access Control Management | Consent policy is an access control problem, not just an authentication problem. |
| CIS-8 — Audit Log Management | Consent events and app grants need monitoring to spot abusive delegation. | |
| Recommendation — Review and restrict application consent paths and delegated permissions. Log and alert on application consent, scope changes, and new delegated grants. | ||
Practitioner Guidance
What to prioritise: Separate “strongly authenticated” from “safe to delegate.” Review app consent policy, scope design, and tenant settings first, because those are the controls that determine whether a valid login can become an excessive grant.
What to verify: Confirm that user-consent defaults, admin-consent workflows, and app-review processes are aligned to data sensitivity. If a low-friction consent path can expose mail, files, directory data, or API write access, treat that as a high-risk control gap even when passkeys are in place.
Decision rule: If an application can request broad or persistent access without a separate approval step, do not rely on MFA strength as the compensating control. Reduce the scope, require admin consent, or remove the app from the allowed set.
Practitioner takeaway: MFA and passkeys harden authentication, but OAuth consent abuse is won or lost at authorization time, so the real security question is how much portable authority a successful login is allowed to create.