How do I bypass the OAuth 2.0 Authorization Consent page in OpenAM 13.x?
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
Archived
This article has been archived and is no longer maintained by ForgeRock.
Overview
Note
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
The OAuth 2.0 Authorization Framework - RFC6749
Related Training
N/A
Related Issue Tracker IDs
OPENAM-5093 (OAuth2 user consent confirmation can be optional )
OPENAM-8374 (NullPointerException in OpenAMOAuth2ProviderSettings when saving consent)