OAuth Consent Phishing: Why Passkeys Are Not Enough
Passkeys stop credential phishing, but not malicious OAuth consent. Learn how consent phishing works and which authorization controls stop it.
Passkeys can prove that a user is signing in on the legitimate authorization-server origin. They cannot prove that the OAuth client asking for access is honest. In a consent-phishing attack, the victim authenticates correctly—including with a passkey—then approves an attacker-controlled application.
OAuth 2.1 Draft 16 now describes this boundary directly. The attack targets authorization after authentication, so a phishing-resistant authenticator does not stop it.
How consent phishing works
The attacker first registers or compromises an OAuth client. The client requests scopes that give access to useful data or actions. The attacker then sends the victim a link to a genuine authorization endpoint.
The flow looks trustworthy because much of it is trustworthy:
Attacker-controlled client
|
| authorization request with sensitive scopes
v
Legitimate authorization server
|
| user signs in with a real passkey
| user approves a misleading consent screen
v
Attacker receives authorization code and tokensThe user never enters a password on a fake site. The authorization server issues a real code. The problem is that the user granted the wrong client the requested authority.
Authentication and consent solve different problems
Authentication establishes who is present. Consent records a user’s approval of a client and requested access. Authorization policy decides whether that approval is sufficient.
Passkeys strengthen the first decision. They do not validate the client’s business identity, explain a vague scope, or determine whether exporting every customer record makes sense for this user. Treating strong authentication as universal approval protection leaves the dangerous decision untouched.
Our identity versus authorization guide for AI agents covers the same boundary in delegated automation: a valid identity and token do not prove that a particular action is appropriate.
Client registration is the first control
OAuth 2.1 Draft 16 recommends controls over client registration, including restricting which scopes a client may request and verifying developers before granting sensitive scopes where possible.
Use different registration paths for public, partner, and internal clients. Sensitive scopes should require administrative review rather than appearing automatically for every new integration. Record the organization behind the client, its redirect URIs, terms, privacy contact, and incident contact.
Dynamic registration can still be useful, but it should not mean unrestricted privilege. A newly registered client can begin with low-risk scopes and earn access to stronger capabilities through review.
Consent screens must describe the consequence
read, write, and manage are convenient protocol names and poor user explanations. The consent screen should translate a scope into the action and resource it enables.
| Weak label | Better explanation |
|---|---|
contacts.read | View names and email addresses in your customer directory |
payments.write | Create payment instructions from your account |
admin | Manage users, roles, and security settings |
Show the verified client name, publisher, requested resources, high-risk actions, and whether access continues when the user is offline. Highlight newly requested privileges during incremental authorization instead of replaying a wall of old text.
High-risk grants need policy, not another checkbox
User consent is not always enough. An organization may prohibit employees from granting third-party access to financial data. A healthcare system may require an administrator to approve a client before any user sees it. A high-value action may require a separate step-up check even after the client has a token.
Useful controls include:
- Client allowlists or verified-publisher requirements for sensitive APIs.
- Scope-to-role policies that limit who may approve each capability.
- Resource-specific consent instead of tenant-wide access.
- Short authorization lifetimes for high-risk or unattended access.
- Clear grant review and revocation in account settings.
- Alerts when a new client receives sensitive scopes.
Do not rely on a broad “I agree” event as proof that every later action was expected.
Detect suspicious grants after issuance
Monitor authorization events, not only failed logins. A consent-phishing incident may contain no failed authentication at all.
Alert on new clients receiving high-risk scopes, unusual grant volume, sudden offline access, redirect-URI changes followed by grants, and access from a client whose publisher status changed. Preserve the client ID, requested scopes, actor, tenant, decision, policy version, and correlation ID in the audit trail.
If you discover abuse, revoke the grant and affected tokens, disable the client, identify impacted resources, notify the appropriate users, and retain evidence. Rotating the user’s password alone will not revoke an attacker’s OAuth authorization.
Contact the NamoID team
NamoID can help you review client registration, scopes, consent screens, grant lifetimes, and revocation paths. The goal is not a prettier approval page; it is an authorization policy that limits what a deceptive client can obtain.
Contact the NamoID team in Slack and share your client types and highest-risk scopes. We can help you model the flow and identify gaps early.