How To
ForgeRock Identity Platform
Does not apply to Identity Cloud

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

Last updated Jan 16, 2023

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

2 readers recommend this article


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 Manage 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 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.

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

Saved consents behavior

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.


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 require a new consent to be saved.

See Also

FAQ: OAuth 2.0 in Identity Cloud and AM

OAuth 2.0 and OIDC in AM

OAuth 2.0

Related Training

ForgeRock Access Management Deep Dive (AM-410)

Related Issue Tracker IDs


Copyright and Trademarks Copyright © 2023 ForgeRock, all rights reserved.