How To

How do I bypass the OAuth 2.0 Authorization Consent page in OpenAM 13.x?

Last updated Jan 5, 2021

The purpose of this article is to provide information on bypassing the OAuth 2.0 Authorization Consent page in OpenAM when you are using the Authorization Code Grant flow. There are other OAuth2 grant flows where bypassing consent is unnecessary because the OAuth2 spec does not require consent to be sought.

1 reader recommends this article

This article has been archived and is no longer maintained by ForgeRock.



You can bypass the Authorization Consent page for (trusted) application-to-application or service-to-service interaction.

As of OpenAM 13.5, you can make the Authorization Consent page optional by enabling both of these options:

  • OAuth2 Provider - Allow Clients to Skip Consent option.
  • OAuth 2.0 Client (Agent) - Implied consent option.

See Administration Guide › Allowing Clients To Skip Consent for further information.

Bypassing the Authorization Consent page (OpenAM 13)

In OpenAM 13, you can choose to save user consent, so that the Authorization Consent page is only presented once. 

You can save user consent by setting the Saved Consent Attribute Name parameter with the name of the profile attribute you want OpenAM to use for saving authorization consent decisions. This should be a multi-valued attribute on the resource owner profile.

See: Administration Guide › Configuring the OAuth 2.0 Authorization Service for detailed instructions.

The salient points are:

  • Add a multi-valued string syntax profile attribute to your identity repository. OpenAM stores resource owners' consent to authorize client access in this profile attribute. On subsequent requests from the same client for the same scopes, the resource owner no longer sees the authorization page.
  • You are not likely to find a standard profile attribute for this. For evaluation purposes only, you might try an unused existing profile attribute, such as description.
  • When moving to production, you should use a dedicated, multi-valued, string syntax profile attribute that is obviously not used for other purposes. For example, you might call the attribute oAuth2SavedConsent.
  • Adding a profile attribute involves updating the identity repository to support use of the attribute, updating the AMUser Service for the attribute, and optionally allowing users to edit the attribute. The process is described in Developer's Guide › Customizing Profile Attributes which demonstrates adding a custom attribute when using OpenDJ directory services to store user profiles.

See Also

FAQ: OAuth 2.0 in Identity Cloud and AM

How do I perform common OAuth 2.0 tasks using curl commands with the standard endpoints in AM (All versions)?

How do I request further information (such as client_id or uid) for an OAuth 2.0 access token in OpenAM 13.x?

The OAuth 2.0 Authorization Framework - RFC6749

Related Training


Related Issue Tracker IDs

OPENAM-5093 (OAuth2 user consent confirmation can be optional )

OPENAM-6192 (For OAuth 2.0 don't expect the default Shared Consent Attribute to contain a value on first use)

OPENAM-8374 (NullPointerException in OpenAMOAuth2ProviderSettings when saving consent)

OPENAM-8375 (OAuth consent page shows 'save consent checkbox' although service property 'Saved Consent Attribute Name' of service 'OAuth Provider' has not been set)

OPENAM-8376 (Info text of service property 'Saved Consent Attribute Name' of service 'OAuth Provider' inaccurate)

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