OpenAM. Remote OAuth2 Consent Service
Throughout this article we use OpenAM as a synonym for ForgeRock Access Manager. At the time of writing — September 2018 — AM 6.0.0.4 was the current version. Please see ForgeRock website for differences between AM and the OpenAM-project.
OpenAM can collect the user consent in an OAuth2 flow via its built in consent collector or can call an external collector. Advantage of external collector is
- fully customizable UI (you write yr own app using whatever UI framework you like
- fully customizable reponse (you might want to have a consent decision like “accept”, “deny” and maybe “cancel” — to cancel the whole flow)
- fully customizable consent (eg if you have a paramterized scope as in PSD2 payment transaction, you don’t want to present the scope as “Do you consent to pay for transaction txID 123?” but rather want to resolve the txID via an external service so that the consent screen contain “Do you want Musicstore Inc to withdraw 965 € for certain guitar Fender Telecaster Nashville?”
When AM asks RCS for consent, it sends a signed (optionally encrypted) JWT to RCS. RCS replies by letting user-agent POST a signed JWT to AM.

Configuring OpenAM
Following the documentation in the OAuth2 guide you need to
- enable remote consent usage
- create an RCS agent configuration (to tell AM where to find the agent, what crypto keys to use etc)
Here are my settings for OAuth2 service and RCS agent.


A NodeJS RCS service
RCS needs three things
- URL from where AM can get the keys (JWK).
- Endpoint for AM to redirect user to.
- Method to collect scope user consented for. In this example the user will FORM POST the granted scope (“uid”, “mail” whatever) and RCS will then create the JWT.
A sample service (not for production) can be found here: https://github.com/steffow/RCS . This service has been designed to have only bare minimum of UI so that you can add your favourite framework.
Let’s have a look on how the RCS flow with the above NodeJS service looks like. We assume you created an OAuth2 client called test on AM. If a user wants to use a certain application, that application will redirect him via sth like
id.init8.net:8080/openam/oauth2/authorize?client_id=test&response_type=code&redirect_uri=http://localhost:3001/redirect&scope=uid%20mail%20telephoneNumber&state=1234zyAfter successful login (with standard AM try “demo/changeit”) AM will redirect the user to the remote consent service (NodeJS). The RCS will display the required scope: uid mail telephoneNumber:

When user click Sign that form will be posted to RCS app where the consented scope will be added to the JWT and signed. Note that uid has not been consented to and there is not part of the scope.
{
"clientId": "test",
"iss": "rcs",
"csrf": "8+oLdL1CIuRO3pXXCrWWGRR3hFCzhgpZaukufpnBhD4=",
"client_description": "",
"aud": "http://id.init8.net:8080/openam/oauth2",
"save_consent_enabled": false,
"claims": {},
"scopes": [
"telephoneNumber",
"mail"
],
"exp": 1536323245,
"iat": 1536323065,
"client_name": "test",
"consentApprovalRedirectUri": "http://id.init8.net:8080/openam/oauth2/authorize?client_id=test&response_type=code&redirect_uri=http://localhost:3001/redirect&scope=uid%20mail%20telephoneNumber&state=1234zy",
"username": "demo",
"decision": true
}The user-agent (browser) needs to post the signed JWT to AM’s consentApprovalRedirectUri (that paramter-name has probably been invented by a German engineer). In out sample app, we will present a FORM with hidden field:

AM replies with
http://localhost:3001/redirect?code=8hGJGaU1leCVG4fFqxgDoxNrNGg&scope=telephoneNumber%20mwhich can be traded for an access_token:

That’s it.
Need your support
Whenever you have a cunning RCS with an über-user-interface, send stuff to ForgeRock marketplace at https://backstage.forgerock.com/marketplace/catalogDisplay
