consent screen is the page you see during an OAuth flow that asks whether you want to allow the application you're logging in to to be able to access the data it's requesting.
The idea is to provide the user with enough information to make an informed decision about what they are providing to the application, and give them the opportunity to amend / reject the request.
This is an example of a simple consent screen implemented in Dmitri Shuralyov's IndieAuth server. It displays an attempt to sign in to the https://unicyclic.com website as https://dmitri.shuralyov.com.
Jamie Tanna's IndieAuth server shows the user a choice of scopes, with information about what they allow, and allows the user to specify whether they'd like to grant a refresh token, as well as informing the user of how long tokens are valid for (with more human readable terminology):
When a client does not use Proof of Key Code Exchange (now the standard), a bold warning is presented to the user:
When a client is not requesting scopes (i.e. to just use the "authentication" flow), the scopes are not presented, and there is instead a note about what this means:
Martijn van der Ven
Martijn van der Ven's consent screen as of IWC East 2020:
The consent screen of p3k contains the following features:
At the top, identifies the application requesting permission. It will show either the plain client ID URL or the application name and logo.
If the client ID URL contains h-app markup, then the application's name and icon will appear instead of the URL.
If the app requests profile scopes (profile and/or email), the profile section appears and shows which profile scopes the app is requesting. These are checkboxes and can be enabled or disabled by the user.
If the app requests any scopes for publishing or reading (e.g. create or read), the next section appears and shows which scopes the app is requesting. Each is a checkbox and can be enabled or disabled by the user. The special scope "draft" can be turned on in which case any post the application creates will be set as a draft regardless of whether the app sets draft status in the Micropub request. This is a way to safely try out micropub clients without risking accidentally publishing posts publicly. The "media" scope is required for the app to upload to the media endpoint, and since some clients don't request it, I have to enable it when using those apps.
The "Channels" section can be expanded to enable this option. By default, posts go through an automatic filtering process to determine which channel the post appears in based on the contents of the post. (e.g. checkins go into the checkins channel, replies go into replies, photo posts that aren't replies go into the photos channel, etc). However if I choose, I can force every post this app makes to go into a certain channel bypassing the normal automatic sorting rules.
Lastly, two security features are shown. If the client included PKCE parameters in the request (recommended as of the 2020 IndieAuth spec), this is shown in green with a closed lock icon.
If the redirect URL of the application has a different host than the client ID, then a warning is shown letting the user know where they will be sent to after authorizing the application.
WordPress IndieAuth Plugin
- 2010-08-17 Template:benward Would this really be so bad? (see screenshot, one of the first sketches of an accepted OAuth UI convention today!). Original link: http://blog.benward.me/post/968515729