Design the Permission Consent Screen

Security & Access · permissions, authentication, trust

Updated 2026-08-04

Treat the consent screen as the most consequential screen in a connection flow. It is where someone hands one product access to their data in another, usually over OAuth, and it is usually the least designed page in the whole sequence.
Translate every scope into what it lets the app do. Read your files is understandable, and a raw scope identifier is not.
Separate reading from writing, and separate both from deleting. Users judge those very differently and most consent screens flatten them into one list.
Say what is being connected, in both directions. The name of the requesting app, the account it will use, and the organization it belongs to all belong above the fold.
Let the user decline part of it where the system allows. All or nothing consent trains people to accept everything without reading.
Show how long the access lasts and how to end it. A connection that is permanent until revoked needs to say so, and the revoke path needs to exist before the connect button does.
List existing connections somewhere permanent, with what each one can do and when it was last used. Consent granted once is a decision the user should be able to revisit.
Warn on unusual requests rather than styling them identically. An app asking for full account access should not look like one asking to read a calendar.
Confirm what happened afterwards. A short summary of what was granted, sent by email, is what makes an unauthorized connection noticeable.

Consent that was not understood is not consent, and the screen is the only place the understanding can happen.