How To

How does OAuth 2.0 Saved Consent work in AM/OpenAM (All versions)?

Last updated May 1, 2019

The purpose of this article is to provide information on how OAuth 2.0 Saved Consent works in AM/OpenAM, including details about the relationship between the Saved Consent Attribute Name and scopes.


Overview

The scope attribute in the authorization request lists the scopes that specify what type of access has been granted by the user. When a user is presented with a consent page and selects "Save consent", an entry will be added to the user profile containing the requested scope. See OAuth 2.0 Guide › Managing OAuth 2.0 Consent for further information.

Saved consent attribute

When you configure the OAuth 2.0 Authorization Service, you should specify the Saved Consent Attribute Name (which is the profile attribute used for saving authorization consent decisions). See OAuth 2.0 Guide › Consent for further information.

When you first access the authorize endpoint, the consent page is shown and your consent will be saved in this attribute if you allow it:

  • If you make a subsequent request from the same client with the same scopes, you will not see the consent page again.
  • If you make a subsequent request from a different client and/or with different scopes, you will be prompted for consent again.

The way consent is handled has changed between versions as a result of OPENAM-8479 (OAuth2 Scriptable/policy-driven Scopes). In essence, consent for each scope is saved separately in AM 6 and later to give more flexibility, whereas consent was saved for the scope combination in pre-AM 6. This is explained in more detail with examples in the following sections:

Note

There is a known issue in AM 5.5.1 and 6: OPENAM-12997 (Consent for default scopes are not saved). This is fixed in AM 6.5.

Saved consents behavior in AM 6 and later

 A user's decision to save consent is specific to each scope in the authorization request and consent for each scope is saved separately. If subsequent requests contain a different scope combination, consent will not be required if the scopes within that combination can be found across multiple saved consents. If part of the scope cannot be found, consent is required.

Example

You have created a profile attribute called oAuth2SavedConsent and specified this in the Saved Consent Attribute Name field.

  • User.1 authorizes with scopes CONTACTS.READ,LOCATION.READ and chooses to save their consent. Consent for each scope (CONTACTS.READ and LOCATION.READ) is saved separately in the oAuth2SavedConsent attribute. 
  • User.1 makes another request with just the CONTACTS.READ scope; they are not prompted to save their consent because consent for this scope has already been saved.
  • User.1 then makes another request with scope EMAIL.READ; they are prompted to save their consent because this is a different scope.
  • User.1 makes a final request with scopes LOCATION.READ,EMAIL.READ; they are not prompted to save their consent because consent for these scopes has already been saved. 

At this point, requests with CONTACTS.READ, LOCATION.READ and/or EMAIL.READ scopes (and any combination of them) will not require consent as consent has already been saved for each of these scopes; however any further requests with different scopes will required a new consent to be saved.

Saved consents behavior in pre-AM 6

A user's decision to save consent is specific to the scope(s) in the authorization request and consent is saved for the scope combination presented. If subsequent requests contain a different scope combination, consent will not be required if the matching scope(s) are found in a saved consent entry. If part of the scope cannot be found, consent is required.

Example

You have created a profile attribute called oAuth2SavedConsent and specified this in the Saved Consent Attribute Name field.

  • User.1 authorizes with scopes CONTACTS.READ,LOCATION.READ and chooses to save their consent. Consent for this scope combination (CONTACTS.READ,LOCATION.READ) is saved in the oAuth2SavedConsent attribute. 
  • User.1 makes another request with just the CONTACTS.READ scope; they are prompted to save their consent because this is considered a different scope.
  • User.1 then makes another request with scopes CONTACTS.READ,LOCATION.READ; they are not prompted to save their consent this time because this consent has already been saved.

At this point, requests with either CONTACTS.READ,LOCATION.READ or CONTACTS.READ scopes will not require consent as consent has already been saved; however any further requests with different scopes will required a new consent to be saved.

See Also

FAQ: OAuth 2.0 in AM/OpenAM

How do I bypass the OAuth 2.0 Authorization Consent page in AM/OpenAM (All versions)?

OAuth 2.0 in AM/OpenAM

OAuth 2.0 Guide

Related Training

ForgeRock Access Management Core Concepts (AM-400)

Related Issue Tracker IDs

OPENAM-14683 (Update AM 6.5 Release Notes to document OAuth2 saved consent behaviour changes)

OPENAM-14633 (User is not prompted for consent when requesting different scopes to those previously requested and saved)

OPENAM-8479 (OAuth2 Scriptable/policy-driven Scopes)



Copyright and TrademarksCopyright © 2019 ForgeRock, all rights reserved.
Loading...