Fine grained scope consent management

[thomasdarimont]

Motivation

I recently had the challenge of implementing a more fine grained consent screen.
The customer wanted that the users can explicitly see and select what data they want to share
based on required and optional client scopes.
Each client scopes has an associated list of logical fields with a name, and current value based on user profile data.
Scopes and fields are sorted according to their guiOrder, if not present the fields are sorted by name.

Users can now grant required scopes and may optionally add optional scopes. Those optional scopes can later be revoked again.
Every consent change updates the user consent model for the client.

I wonder if we could provide an SPI to enrich consent screens to support use-cases like below.
I think support for explicit scope selection and could be use full in the grant-consent form.

Example

Here is a small example for how that looks like:

The application is configured with the following client scopes:

email:
  mappers: ['email','email_verified']

name:
  optional:  true
  mappers: ['family_name','given_name','preferred_username', 'name']

phone:
  optional:  true
  mappers: ['phone_number','phone_number_verified']

There is an application that is configured with a set of optional and required scopes.
By default the application requests required and optional scopes openid email name phone.

When accessing the page the user must grant the consent for the required scope email.

This results in the following scopes granted:

Requested Scope: openid email name phone
Granted Scope: openid email

If the user now clients update consent, the consent screen is shown again.

Now the user can decide to share more data by selecting the optional scopes.

The application will now have access to the selected information.

The user can now decide to stop sharing certain information, e.g. phone number by clicking update consent again, and deselect the phone number.

After that the phone number information is no longer shared with the application:

[lokeshgrootan]

we have tried the same for one of the customers, but we dint show the details like phone number, first name of optional scopes instead, default will be shown and show options to select optional ones alone.I would suggest it should be included as default feature with keycloak core

[thomasdarimont]

@lokeshgrootan thanks for your feedback!
Would something like this work for you?

[lokeshgrootan]

Yes this is better !!

[Anykry]

Hi.
How you create checkboxes and this form? as I understood this form with scope selector appears before the consent screen?

[thomasdarimont]

This tweet shows this in action: https://twitter.com/thomasdarimont/status/1494701057280253960

[Anykry]

@thomasdarimont It's a great approach with limit user granted scopes to the client. Could you help with this?

[jbman]

Great that this topic is picked up again. Giving the user more fine-grained control over granted scopes was also discussed two years ago at the mailing list Allow individual grants for client scopes (according to GDPR).

This discussion also includes an additional usability aspect: It would be good if the client should declare which combination of scopes it wants to have granted so that it can provide a useful function. If users can select or deselect any combinations, the application often needs to guide the user to activate one more. You may not that pattern form android phones were bluetooth binding often needs location access granted.

With the scope identifiers being passed in as scope parameters the client can do that for one function it provides. For another function it could request another scope. What it can't do, is requesting all at once different sets of scopes on one screen:

[x] Function: 'No beer alert'
* Scope: Access to fridge camera
* Scope: Smart home alerts

[ ] Function: 'Product missing email' - If a product isn't in your fridge any more, we send you an email with a photo of it
* Scope: Access to fridge camera
* Scope: Personal data (name, firstname, email)

[lmsurpre]

@thomasdarimont this is good stuff; are you still pursuing it?
I recently learned that the ability for users to pick and choose which scopes they consent to is a requirement of the US Health and Human Services 21st Century Cures Act certification process (required to be implemented by "certified health IT vendors" by end of year in the US). If interested, there is more discussion / context at https://chat.fhir.org/#narrow/stream/179170-smart/topic/Keycloak.20for.20SMART.20authz/near/298505047

I don't have much time for it, but I've been asked by a couple different folks now whether this is possible to implement as an extension with the current Keycloak APIs, so any guidance you can offer would be great.

[javacup]

We implemented an extension using a RequiredActionProvider that would allow users to review consent every time a 3rd party application is launched to access our EHR Rest API (FHIR resource server). We went back and forth whether to put this in the authentication flow or as a required action. The authentication flow option would not allow users to review the consented client scopes on a subsequent launch (at least the work flow we are expecting for such app launches) after a successful login.

[ganeshrams]

Hi,

I am implementing some what similar to what you have done. May I know how you updated the consent for the session based on the user's choice.

[ahcamy2021]

Hi,

Is there any plan to integrate this extension in Keycloak core? If yes, could you please share the number of the ticket?

Thanks.