consent screen

From IndieWeb
Jump to: navigation, search

This article is a stub. You can help the IndieWeb wiki by expanding it.


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.

Examples

Dmitri Shuralyov

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.

dmitri shuralyov consent screen.png

Jamie Tanna

  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):

A screenshot of Jamie's consent screen, listing the client's URL, the currently authenticated user, a list of scopes and what they mean, presented as a tickbox. There is a checkbox option for allowing persistent access, with a description of what it means in less technical terms - listing all scopes that are supported by the server, with the scopes that have been requested pre-ticked, and unknown scopes listed separately. There is also the option to allow the request, or deny it.

When a client does not use Proof of Key Code Exchange (now the standard), a bold warning is presented to the user:

A screenshot of Jamie's consent screen, with a bold warning showing that Proof of Key Code Exchange isn't in use

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:

A screenshot of Jamie's consent screen, with a human-readable description about only getting profile information and lack of persistent access to data

Martijn van der Ven

Martijn van der Ven's consent screen as of IWC East 2020:

Screenshot of a consent user interface with checkboxes for scopes, a disclosure triangle for custom scopes, and a set of profile fields that will be shared

Aaron Parecki

The consent screen of p3k, showing the profile and micropub and microsub scopes with checkboxes next to each

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.

screenshot of quill icon with the name quill in place of the previously shown application 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 text "If any channels below are checked, all posts created with this access token will be added to the channels checked", followed by a list of channel names

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.

green box containing a lock icon emoji and the text "This client is using PKCE with method S256!", followed by a orange warning box explaining that the redirect URL does not match the domain of the client ID

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

wordpress indieauth consent screen.png

capjamesg

capjamesg's IndieAuth server displays:

  • The name and logo of a client, with a link to the client ID.
  • A description from the client, if one is specified in a p-summary microformat.
  • A list of scopes requested by a client, if any.
  • A message telling a user whether or not PKCE is in use by the client.
  • The redirect URL to which a user will be sent after authorizing an application.
  • A button to let the user authorize their request.

A user must authenticate with the web server using RelMeAuth before they can authorize an application to log in with their domain.

Here is how capjamesg's IndieAuth consent screen appears:

Screenshot from 2021-10-20 10-52-47.png

See Also

Retrieved from "https://indieweb.org/wiki/index.php?title=consent_screen&oldid=77884"