Additional claims against authorization code

Troubleshooting
, , , , , ,
#1

I would like to add custom claim to the access token using Authorization Code Grant Flow.
The custom claim info is available only during the initial call to get the authorization code. This info is NOT available during the /access_token invocation.

Currently am storing authCode|customClaim in Redis during the /authorize call , and then getting this custom claim back from the Access Token Modification Script on /access_token

Just wondering if there is a better way to do this in AM, say by somehow storing custom info along with the authorization code and just using it directly in the Access Token Modification Script ?

#2

You can store this in the session object in the auth flow, and then access the session properties in the custom token script, and then add the claim to the idToken there.

#3

E.g. in groovy script node in auth tree;
action = Action.goTo(“true”)
.putSessionProperty(“myvalue”, myvalue)

and in the custom token script:

sessionProperties = session.getProperties()
sessionProperties.get(“myvalue”)

1 Like
#4

Thanks for the reply. Unfortunately I don’t have access to session on the second API invocation. Its a stateless REST API call just passing the authCode - no user involved, hence adding in Redis for now.

I was looking more at if we can store the custom value along with the authCode in the same table, DS etc…

#5

After debugging some AM code, found a way around this by using the claims in the request and setting couple of properties against the OAuth2Provider

curl -s --dump-header -
–request POST
–Cookie “iPlanetDirectoryPro=$sessionToken”
–data “response_type=code id_token”
–data “scope=xxx” –data ‘claims={“myCustomProp”:“val”}’
–data “client_id=xxx”
–data “csrf=$sessionToken”
–data “redirect_uri=xxx”
–data “state=abc123”
–data “decision=allow”
–data “nonce=1234”
“${AM}/oauth2/customer/authorize”

Later when we exchange auth code for the access token, this sticks into the Access Token.

However, per the docs - seems that this was designed for Id Token. Also, the configs in the OAuth2Provider is under the OIDC section.

I am still evaluating and testing this for any side-effects, but wanted to check if anyone else has tried this approach or are there any drawbacks that we need to be aware off.

Thank you

1 Like