OAuth consent: what the screen should say, and how consent phishing abuses it

OAuth consent is the moment a user authorizes an application to act on their behalf. The consent screen is where that decision becomes visible: which app is asking, what it wants to access, and where it will send the user afterward.

It is also one of the weakest points in an otherwise well-designed identity system. Users click through consent screens the way they click through cookie banners, and attackers have learned to turn that habit into account takeover.

What the user is actually approving

A consent screen summarizes an authorization request. Behind the screen, the client is asking for:

• Identity. The client ID and, in a good implementation, a verified application name and logo.
• Scopes. The specific permissions the token will carry, such as reading a profile, sending email or accessing files.
• A redirect URI. Where the authorization code or token will be sent after approval.
• Offline access. A refresh token, if the app wants to keep acting after the user leaves.
• A duration. How long the grant lasts, and whether the user can revoke it later.

The screen is not authentication. It does not prove who the user is; that happens at the identity provider. It records the user's decision to delegate access to a specific client.

Anatomy of a useful consent screen

Scope copy is a security control

Most OAuth incidents are not caused by a broken signature. They are caused by a user granting more access than they intended.

Good scope copy says what the app will do in the user's language:

• Bad: "files:write"
• Better: "Create, edit and delete files in your Drive"
• Bad: "admin"
• Better: "Manage users and settings for your organization"

Show scopes incrementally. Ask for the minimum needed at sign-in, and request additional scopes when the user first uses the feature that needs them. A wall of permissions at first login trains users to approve without reading.

Do not bundle marketing consent, terms acceptance and OAuth scopes into one checkbox. Each is a separate decision, and bundling makes the security decision meaningless.

Consent phishing

Consent phishing is an attack where the victim is tricked into granting a malicious application access to their account through a legitimate OAuth flow. The attacker does not need the password or a second factor; the user hands over a token by clicking "Accept".

The pattern is consistent:

1. The attacker registers an app with a trusted-sounding name and, sometimes, a lookalike logo.
2. The victim receives a link to the real identity provider's consent page.
3. The victim signs in normally, including MFA, and approves the requested scopes.
4. The attacker receives a refresh token and keeps access until the grant is revoked.

Because the sign-in and MFA are genuine, MFA does not stop this attack. The control is at the consent and application-governance layer.

Mitigations that work:

• Restrict user consent to verified publishers or to low-risk scopes, and require admin approval for the rest.
• Verify publishers and show a verified badge on the consent screen.
• Review third-party grants regularly and revoke stale or unknown apps.
• Alert on new grants of high-risk scopes, especially mail, files and directory access.
• Use conditional access so a risky sign-in cannot silently obtain a persistent grant.
• Teach users what a consent screen is and why the redirect domain matters.

Microsoft and Google both document consent phishing as a first-class threat, and both now offer tenant-level controls to restrict user consent. If you run an identity provider for an organization, those controls are part of your product, not an optional extra.

Consent and the OAuth security best practices

RFC 9700, the OAuth 2.0 Security Best Current Practice, tightened several parts of the flow that affect consent:

• Exact redirect URI matching. No wildcards or partial matches; a mismatch should fail before the user sees the screen.
• PKCE for public clients. The authorization code is bound to the client that started the flow.
• No implicit grant for new apps. Tokens in the fragment are easier to leak and harder to bind to a client.
• Short-lived authorization codes. A code should be useless if it is replayed later.

Consent screens should reflect these decisions. If a request fails because consent has not been given, return a clear error such as consent_required rather than a generic failure.

Designing consent into your product

A practical checklist for teams building an OAuth provider or a third-party integration:

1. Ask for the minimum scopes at the moment they are needed.
2. Write scope descriptions for humans, not for the API reference.
3. Show the client identity and redirect domain clearly.
4. Make the grant revocable from the user's account settings.
5. Log consent events with the client, scopes, user and time.
6. Expire grants that have not been used, and re-prompt when scopes change.
7. Separate consent from authentication in your UI and in your audit logs.
8. Test the deny path. A user who clicks "Cancel" should end up somewhere sensible, with no token issued.

Consent in Casdoor

Casdoor supports per-application scopes with a name, a display name and a description. The display name and description are what the user sees on the consent screen, so they are the place to write the human-readable permission text.

When a user has not yet approved the requested scopes, Casdoor returns the consent_required error, and the consent page keeps the original request parameters, including the resource indicator, through the redirects. Applications can therefore ask for additional scopes later without losing the context of the original authorization.

See the scopes documentation for the field definitions and the OAuth documentation for the consent flow. Casdoor is open source, and Casdoor Cloud starts at $6.67/month billed yearly for a dedicated instance.

FAQ

Is a consent screen required by OAuth? The OAuth specification describes obtaining the user's authorization; it does not prescribe a particular screen. In practice, every major provider implements that step as a consent screen.

Does MFA prevent consent phishing? No. The attacker never needs the password or the second factor; the victim signs in legitimately and grants access. Restricting user consent and reviewing grants are the effective controls.

Can users revoke access later? They should be able to. A provider that does not offer revocation leaves users stuck with a grant they no longer want; an app that cannot be revoked is a security incident waiting to happen.

Should first-party apps show consent? It depends on your risk model. Many providers skip consent for first-party apps they own, but showing it still helps users understand what the app can access. For third-party apps, consent should always be explicit.