Remote consent
AM supports OAuth 2.0 remote consent, which hands off the consent-gathering part of an OAuth 2.0 flow to a separate service.
A remote consent service (RCS) renders a consent page, gathers the result, signs and encrypts the result, and returns it to the authorization server.
Remote consent flow
During an OAuth 2.0 flow that requires user consent:
-
AM creates a consent request JWT that contains the necessary information to render a consent gathering page.
AM doesn’t send the actual values of the requested scopes. Consent request JWT example and properties
{ "clientId": "myClient", "iss": "https://am.example.com:8443/am/oauth2/realms/root/realms/alpha", "csrf": "gjeH2C43nFJwW+Ir1zL3hl8kux9oatSZRso7aCzI0vk=", "resourceOwnerSessionProperties": { "myProperty": "myValue" }, "client_description": "", "aud": "rcs", "save_consent_enabled": true, "authorization_details": [{ "type": "account_information", "actions": [ "list_accounts", "read_balances", "read_transactions" ], "locations": [ "https://example.com/accounts" ] }], "claims": {}, "scopes": { "write": null }, "exp": 1536229486, "iat": 1536229306, "client_name": "My Client", "consentApprovalRedirectUri": "https://am.example.com:8443/am/oauth2/authorizeWithConsent?client_id=MyClient&response_type=code&redirect_uri=https://application.example.com:8443/callback&scope=write&state=1234zy", "username": "bjensen" }aud-
The name of the expected recipient of the JWT, in this case, the RCS.
authorization_details-
Additional fine-grained authorization requirements, as specified in RFC 9396: OAuth 2.0 Rich Authorization Requests.
Find more information in authorization_details.
claims-
The claims the request makes.
Use the
claimsfield for additional information to display on the remote consent page. This information can help the user determine if they should grant consent. For example, Open Banking OAuth 2.0 flows might include identifiers for a money transaction. client_description-
A description of the OAuth 2.0 client making the request.
client_id-
The ID of the OAuth 2.0 client making the request.
client_name-
The display name of the OAuth 2.0 client making the request.
consentApprovalRedirectUri-
The URI to which AM directs the resource owner after they’ve provided consent. The response JWT must be sent as a
consent_responseform parameter in a POST request to this URI. csrf-
A unique string that must be returned in the response to help prevent cross-site request forgery (CSRF) attacks.
AM generates this string from a hash of the user’s session ID.
exp-
The expiration time of the JWT.
Use short expiration times (180 seconds, for example) because the JWT is intended for use in machine-to-machine interactions.
iat-
The creation time of the JWT.
iss-
The name of the issuer, configured in the OAuth 2.0 provider service.
resourceOwnerSessionProperties-
Custom properties from the resource owner’s session to include in the remote consent request. To configure the properties to send, map session properties in the Resource Owner Session Properties field in the RCS agent configuration.
save_consent_enabled-
Whether to give the user the option to save their consent decision.
If set to false, the value of thesave_consentproperty in the consent response from the RCS must also befalse. scopes-
The requested scopes.
username-
The username of the authenticated user.
If the username could be considered personally identifiable information, you must encrypt the JWT .
-
Acting as the authorization server, AM signs and encrypts the JWT.
-
The RCS does the following:
-
Decrypts the JWT.
-
Verifies the signature and other details, such as the validity of the
aud,iss, andexpproperties, and any specifiedauthorization_details. -
Renders the consent page to the resource owner.
-
Gathers the user’s consent.
-
Creates a consent response JWT.
-
Encrypts and signs the response.
-
Returns the response to AM for processing.
Consent response JWT example and properties
{ "consent_response" : { "clientId": "myClient", "iss": "rcs", "csrf": "gjeH2C43nFJwW+Ir1zL3hl8kux9oatSZRso7aCzI0vk=", "client_description": "", "aud": "https://am.example.com:8443/am/oauth2", "save_consent": true, "authorization_details": [{ "type": "account_information", "actions": [ "list_accounts", "read_balances", "read_transactions" ], "locations": [ "https://example.com/accounts" ] }], "claims": {}, "scopes": "[write]", "exp": 1536229430, "iat": 1536229250, "client_name": "My Client", "consentApprovalRedirectUri": "https://am.example.com:8443/am/oauth2/authorizeWithConsent?client_id=MyClient&response_type=code&redirect_uri=https://application.example.com:8443/callback&scope=write&state=1234zy", "username": "bjensen", "decision": true }, }iat-
The creation time of the JWT.
iss-
The name of the RCS.
Must match the value of the
audproperty received from AM. aud-
The name of the expected recipient of the JWT, in this case, AM acting as the authorization server.
Must match the value of the
issproperty received from AM. authorization_details-
The fine-grained authorization requirements sent to the RCS. Currently, if these details are valid, AM doesn’t process them in the response. There’s no way to allow the RCS to augment the
authorization_detailsin such a way as to have them become part of the authorization grant.If the authorization details are invalid, the RCS can return an
invalid_authorization_detailserror as part of the consent response JWT. AM forwards this error, along with the providederror_descriptionanderror_uri, to the client. For example:{ "iss": "rcs", "aud": "{amExampleUrl}/oauth2", "exp": 1739181167, ... "error": "invalid_authorization_details", "error_description": "The authorization details are invalid.", "error_uri": "https://docs.example.com/errors/invalid_authorization_details", "state": "xyz123" }For AM to forward the error:
-
There must be an
errorparameter and its value must beinvalid_authorization_details. -
The
error_descriptionanderror_uriparameters are optional. If included, their values must conform with RFC 6749: The OAuth 2.0 Authorization Framework. -
If the value of
erroris notinvalid_authorization_details, AM ignores theerror_descriptionanderror_uriproperties.
-
exp-
The expiration time of the JWT.
The JWT is intended for use in machine-to-machine interactions. Use short expiration times, for example, 180 seconds.
decision-
trueif consent was provided, orfalseif consent was withheld. client_id-
The ID of the OAuth 2.0 client making the request, matching the value provided in the request.
client_name-
The display name of the OAuth 2.0 client making the request.
client_description-
A description of the OAuth 2.0 client making the request.
scopes-
An array of allowed scopes.
Must be equal to, or a subset of, the array of scopes in the request.
save_consent-
trueif the user chose to save their consent decision, orfalseif they didn’t.If
save_consent_enabledwas set tofalsein the request,save_consentmust also befalse. consentApprovalRedirectUri-
The URI to which AM returns the resource owner after they’ve provided consent.
-
-
AM then does the following:
-
Decrypts and verifies the signature of the consent response and other details, such as the validity of the
aud,issandexpproperties. -
Processes the response.
For example, it could save the consent decision if configured to do so.
If the RCS compresses the consent response JWT, AM rejects JWTs that expand to a size larger than 32 KiB (32768 bytes). Find more information in Control the size of compressed JWTs.
-
RCS configuration overview
Configuring an RCS in AM includes the following high-level tasks:
| Task | Resources | ||
|---|---|---|---|
Add the details of the RCS as an agent profile in AM You can configure a single RCS in a realm, by adding the details to a remote consent agent profile. The profile defines properties for signing and encrypting the consent request and consent response, redirect URI,
and the |
|
||
Enable remote consent and specify the agent profile in AM’s OAuth 2.0 provider service. |
|||
Configure the RCS with AM’s The RCS must be able to obtain the required signature and decryption keys from AM. |
AM includes an example RCS for testing purposes. Don’t use the example in production environments. Find more information in Test the example RCS. |
Configure AM to use an RCS
To add the details of the RCS as an agent profile:
-
In the AM admin UI, go to Realms > realm name > Applications > OAuth 2.0 > Remote Consent.
-
Click + Add Remote Consent Agent.
-
Enter an agent ID, for example,
myRCSAgent. -
If you’ll use an HMAC algorithm for signing the JWTs, enter the shared symmetric key in the Remote Consent Service secret field.
This step isn’t required when using other algorithms.
-
Click Create.
-
Select the Remote Consent Agent, and configure the properties as required.
Remote consent agent properties
- Group
-
Configure several remote consent agent profiles by assigning them to a group.
Default value:
noneamsterattribute:agentgroup - Remote Consent Service secret
-
If the remote consent agent needs to authenticate to AM, enter the password it will use.
amsterattribute:userpassword - Redirect URL
-
The URL to which the user should be redirected during the OAuth 2.0 flow to obtain their consent.
The AM example RCS provides an
/oauth2/consentpath to obtain consent from the user.Example:
https://rcs.example.com:8443/am/oauth2/consentamsterattribute:remoteConsentRedirectUrl
- Pushed Consent Request URL
-
The RCS URL to which AM sends pushed consent requests.
AM sends a POST request to this endpoint containing the remote consent request JWT, for example:
{ "consent_request":"request JWT" }The RCS verifies the consent request JWT and stores the details of the consent request against an opaque token. It returns the opaque token to AM in a
consent_request_uriparameter as a response to the request. For example:{ "consent_request_uri":"consent-FVaTaZTWuQGZkQX" }AM proceeds with the usual remote consent flow, but the OAuth 2.0 client is redirected to the RCS with the
consent_request_uriparameter instead of the remote consent request JWT.For security reasons, the
consent_request_uri:-
Should contain a random element that can’t be guessed.
-
Should have a short expiry time, for example, two minutes.
-
Must be used only once.
amsterattribute:pushedConsentRequestUrl -
- Pushed Consent Authentication Method
-
The authentication method, which determines whether to send credentials to the RCS for pushed consent requests.
Options are:
-
None(default): AM sends no client credentials with the pushed consent request. -
Basic: AM sends client credentials in an HTTP Basic authentication header with the pushed consent request.The Basic authentication header exposes the agent’s credentials in an unencrypted form. If you select this option, make sure your Pushed Consent Request URL uses HTTPS to avoid exposing unencrypted credentials over insecure network channels.
amsterattribute:pushedConsentAuthenticationMethod -
- Enable consent request Encryption
-
Whether to encrypt the consent request JWT sent to the RCS.
Default:
trueamsterattribute:remoteConsentRequestEncryptionEnabled - Consent request Encryption Algorithm
-
The encryption algorithm used to encrypt the consent request JWT sent to the RCS.
AM supports the following encryption algorithms:
-
A128KW: AES Key Wrapping with 128-bit key derived from the client secret. -
A192KW: AES Key Wrapping with 192-bit key derived from the client secret. -
A256KW: AES Key Wrapping with 256-bit key derived from the client secret. -
RSA-OAEP: RSA with Optimal Asymmetric Encryption Padding (OAEP) with SHA-1 and MGF-1. -
RSA-OAEP-256: RSA with OAEP with SHA-256 and MGF-1. -
RSA1_5: RSA with PKCS#1 v1.5 padding. -
dir: Direct encryption with AES using the hashed client secret.
Default value:
RSA-OAEP-256amsterattribute:remoteConsentRequestEncryptionAlgorithm -
- Consent request Encryption Method
-
The encryption method used to encrypt the consent request JWT sent to the RCS.
AM supports the following encryption methods:
-
A128GCM,A192GCM, andA256GCM: AES in Galois Counter Mode (GCM) authenticated encryption mode. -
A128CBC-HS256,A192CBC-HS384, andA256CBC-HS512: AES encryption in CBC mode, with HMAC-SHA-2 for integrity.
Default value:
A128GCMamsterattribute:remoteConsentRequestEncryptionMethod -
- Consent response signing algorithm
-
The algorithm used to verify a signed consent response JWT received from the RCS.
AM supports signing algorithms listed in JSON Web Algorithms (JWA): "alg" (Algorithm) Header Parameter Values for JWS:
-
ES256: ECDSA with SHA-256 and NIST standard P-256 elliptic curve. -
ES384: ECDSA with SHA-384 and NIST standard P-384 elliptic curve. -
ES512: ECDSA with SHA-512 and NIST standard P-521 elliptic curve. -
HS256: HMAC with SHA-256. -
HS384: HMAC with SHA-384. -
HS512: HMAC with SHA-512. -
RS256: RSASSA-PKCS-v1_5 using SHA-256.
Default value:
RS256amsterattribute:remoteConsentResponseSigningAlg -
- Consent response encryption algorithm
-
The encryption algorithm used to decrypt the consent response JWT received from the RCS.
AM supports the following encryption algorithms:
-
A128KW: AES Key Wrapping with 128-bit key derived from the client secret. -
A192KW: AES Key Wrapping with 192-bit key derived from the client secret. -
A256KW: AES Key Wrapping with 256-bit key derived from the client secret. -
RSA-OAEP-256: RSA with OAEP with SHA-256 and MGF-1. -
dir: Direct encryption with AES using the hashed client secret.
The decryption key used depends on the selected algorithm. This table shows the secret label mapping used to decrypt remote consent responses:
Secret label Default alias Algorithms(1) am.services.oauth2.remote.consent.response.decryptiontestRSA-OAEP-256(1) If you select an algorithm other than
RSA-OAEP-256for decrypting consent responses, AM uses the value of the Remote Consent Service secret property instead of an entry from the secret stores.By default, secret labels are mapped to demo keys contained in the default keystore provided with AM and mapped to the
default-keystoresecret store. Use these keys for demo and test purposes only. For production environments, replace the secrets as required and create mappings for them in a secret store configured in AM.For details about managing secret stores and mapping secret labels to aliases, refer to Secrets, certificates, and keys.
Default value:
RSA-OAEP-256amsterattribute:remoteConsentResponseEncryptionAlgorithm -
- Consent request Signing Algorithm
-
The algorithm used to sign the consent request JWT sent to the RCS.
The signing key used depends on the selected algorithm.
This table shows the secret label mappings used to sign remote consent requests:
Secret label Default Alias Algorithms(1) am.applications.agents.remote.consent.request.signing.ES256es256testES256am.applications.agents.remote.consent.request.signing.ES384es384testES384am.applications.agents.remote.consent.request.signing.ES512es512testES512am.applications.agents.remote.consent.request.signing.RSArsajwtsigningkeyRS256
RS384
RS512
PS256
PS384
PS512(1) If you select an HMAC algorithm for signing consent requests (
HS256,HS384, orHS512), AM uses the value of theRemote Consent Service secretproperty instead of an entry from the secret stores.Because AM and the remote consent client share the HMAC secret, a malicious user compromising the client could potentially create tokens that AM would trust. To protect against misuse, AM also signs the token using a non-shared signing key configured in the
am.services.oauth2.jwt.authenticity.signingsecret label.By default, secret labels are mapped to demo keys in the default keystore provided with AM and mapped to the
default-keystorekeystore secret store. Use these keys for demo and test purposes only. For production environments, replace the secrets as required and create mappings for them in a secret store.For information about managing secret stores and mapping secret labels to aliases, refer to Secrets, certificates, and keys.
Default value:
RS256amsterattribute:remoteConsentRequestSigningAlgorithm - Consent response encryption method
-
The encryption method used to decrypt the consent response JWT received from the RCS.
AM supports the following encryption methods:
-
A128GCM,A192GCM, andA256GCM: AES in Galois Counter Mode (GCM) authenticated encryption mode. -
A128CBC-HS256,A192CBC-HS384, andA256CBC-HS512: AES encryption in CBC mode, with HMAC-SHA-2 for integrity.
Default value:
A128GCMamsterattribute:remoteConsentResponseEncryptionMethod -
- Public key selector
-
Whether the RCS provides its public keys using a
JWKs_URI, or manually inJWKsformat.If you select
JWKs, enter the keys in the Json Web Key property. If you selectJWKs_URI, complete the JWKs URI-related properties.Default:
JWKs_URIamsterattribute:remoteConsentRedirectUrl - Json Web Key URI
-
The URI from which AM can obtain the RCS’s public keys.
The example RCS uses the URI
/oauth2/consent/jwk_urito provide its public keys.amsterattribute:jwksUri - JWKs URI content cache timeout in ms
-
The period of time, in milliseconds, that the content of the JWKs' URI is cached before being refreshed. Caching the content avoids fetching it for every token encryption or validation.
Default:
3600000amsterattribute:com.forgerock.openam.oauth2provider.jwksCacheTimeout - JWKs URI content cache miss cache time
-
The period of time, in milliseconds, that AM waits before fetching the URI’s content again when a key ID (
kid) isn’t in the JWKs that are already cached.For example, if a request comes in with a
kidthat isn’t in the cached JWKs, AM checks the value of JWKs' URI content cache miss cache time. If the period of time specified in this property has already passed since the last time AM fetched the JWKs, AM fetches them again. Otherwise, the request is rejected.Use this property as a rate limit to prevent denial-of-service attacks against the URI.
Default:
60000amsterattribute:com.forgerock.openam.oauth2provider.jwkStoreCacheMissCacheTime - Json Web Key
-
If the Public key selector property is set to
JWKs, specify the RCS’s public keys, in JSON Web Key format.Example:
{ "keys": [ { "kty": "RSA", "kid": "RemA6Gw0...LzsJ5zG3E=", "use": "enc", "alg": "RSA-OAEP-256", "n": "AL4kjz74rDo3VQ3Wx...nhch4qJRGt2QnCF7M0", "e": "AQAB" }, { "kty": "RSA", "kid": "wUy3ifIIaL...eM1rP1QM=", "use": "sig", "alg": "RS256", "n": "ANdIhkOZeSHagT9Ze...ciOACVuGUoNTzztlCUk", "e": "AQAB" } ] }amsterattribute:jwkSet - Consent Request Time Limit
-
The period of time, in seconds, for which the consent request JWT sent to the RCS should be considered valid.
Default:
180amsterattribute:requestTimeLimit
- Resource Owner Session Properties
-
Properties to include in the remote consent request, if available in the resource owner’s session. Each entry maps a session property name to the name of the claim for that property in the request.
Keyis the name of the property in the session andValueis the name of the property in the RCS JWT.Properties appear in the remote consent request JWT nested under the
resourceOwnerSessionPropertiesfield. If you don’t configure any mappings here, the remote consent request JWT won’t contain aresourceOwnerSessionPropertiesfield.amsterattribute:resourceOwnerSessionProperties
-
Save your changes.
The remote consent agent profile is now available for selection in the OAuth 2.0 provider. Find more information in Add RCS agent to the OAuth 2.0 provider.
Add RCS agent to the OAuth 2.0 provider
To add the details of the remote consent agent profile to an OAuth 2.0 provider service:
-
In the AM admin UI, go to Realms > realm name > Services > OAuth2 Provider.
-
On the Consent tab:
-
Click Enable Remote Consent.
-
In the Remote Consent Service ID drop-down list, select the agent ID of the remote consent agent. For example,
myRCSAgent.
-
-
If required, modify the supported signing and encryption methods and algorithms used for the consent request and consent response JSON web tokens.
Find more information on the RCS configuration properties in Consent.
-
Save your changes.
OAuth 2.0 flows by any client in the realm will now use the RCS. OAuth 2.0 clients in other realms are unaffected.
Test the example RCS
AM includes an example RCS that lets you demonstrate and test remote consent.
|
The example RCS isn’t intended for use in production environments because you can’t configure the encryption and signing algorithms. The example is intended only to demonstrate how you can configure AM to use a custom RCS. |
The following example uses two instances of AM:
-
One instance acts as the authorization server. For example,
https://am.example.com:8443/am. -
One instance acts as the example RCS. For example,
https://rcs.example.com:8443/am.
Perform the following steps to configure your environment:
-
As an administrative user, for example,
amAdminlog in to the instance that acts as the example RCS. -
Go to Realms > realm name > Services, and click Add a Service.
-
From the Choose a service type drop-down list, select Remote Consent Service.
-
Perform the following steps to configure the RCS:
-
In Client Name, enter the agent ID given to the remote consent agent profile in AM.
In this example, enter
myRCSAgent. -
In Authorization Server jwk_uri, enter the URI where the RCS will obtain the keys that the authorization service uses to sign and encrypt the consent request. These keys include:
-
The public signing key the RCS uses to verify the signature of the consent request.
-
The public encryption key for the consent response, so that the response can be encrypted (if encryption is enabled).
The default JWKs URI for remote consent clients is
/oauth2/consent_agents/jwk_uri.For example,
https://am.example.com:8443/am/oauth2/realms/root/realms/alpha/consent_agents/jwk_uri.
-
-
Click Create.
-
Verify the configuration. Find more information about the available properties in Remote consent service.
-
-
Configure the secret labels for encrypting the consent request and signing the consent response.
You can use an existing secret store at the global or realm level, or create a new secret store. This step assumes you have a keystore secret store in the realm where the RCS is configured:
-
Go to Realms > realm name > Secret Stores, and click the name of the keystore secret store that contains the secrets you’ll use to sign and encrypt the consent response.
-
On the Mappings tab, add the following mappings if not already present:
-
am.services.oauth2.remote.consent.response.signing.RSA:rsajwtsigningkey -
am.services.oauth2.remote.consent.request.encryption:test
-
These keys must match the configuration of the RCS agent.
Find more information about mapping secrets in Map and rotate secrets.
-
-
In the AM admin UI of the instance acting as the OAuth 2.0 provider, configure an RCS agent by performing the steps in Configure AM to use an RCS.
The example RCS provides an
/oauth2/consent/jwk_uripath to provide its public keys to the authorization server. In this example, configurehttps://rcs.example.com:8443/am/oauth2/consent/jwk_uriin the Json Web Key URI field. -
Configure the authorization server to use the RCS agent by performing the steps in Add RCS agent to the OAuth 2.0 provider.
-
Test your configuration.
Performing an OAuth 2.0 flow on the AM instance that’s acting as the authorization server redirects the user to the second instance when user consent is required.
The remote consent service renders the consent page, using the decrypted information received from AM acting as the authorization server.