Add Additional Attribute in OAuth Code Flow When Fetching Access Token

Tagged: ,

This topic has 11 replies, 5 voices, and was last updated 3 months ago by sireeshanp.

  • Author
    Posts
  • #28052
     ray.deng83
    Participant

    In the OAuth Auth Code flow, is it possible to pass a parameter in the body and return that value in the Access Token when exchanging the Code for the Token?

    For example, the code is fetched and then the following POST body will be used to fetch the Access Token.

    {
    “grant_type” : “authorization_code”,
    “client_id” : “myClient”,
    “client_secret” : “mySecret”,
    “code” : “g5B3qZ8rWzKIU2xodV_kkSIk0F4”,
    “userId” : “user123”
    }

    In this POST body, an extra (userID) key/value is passed. Is it possible to return that key/value in the Access Token?

    I’m thinking modifying the ‘OAuth2 Access Token Modification’ script, but couldn’t find a way to retrieve the POST body. Any suggestion is appreciated. Thanks.

    Best,
    Le

    #28053
     Andrew Potter
    Participant

    AM supports the Claims Request Parameter described in the OIDC spec. Maybe that will work for you?
    AM docs: https://backstage.forgerock.com/docs/am/6.5/oauth2-guide/index.html#global-oauth-oidc-advanced-openid-connect
    OIDC spec: https://openid.net/specs/openid-connect-core-1_0.html#ClaimsParameter

    #28054
     ray.deng83
    Participant

    Thanks for the reply Andrew. There will be no id_token returned, only access token returned in our use case. So I guess we can’t use Claim Parameter in this case.

    #28055
     Jatinder Singh
    Participant

    Howdy!

    What you are attempting to do is quite similar to how NONCE in OIDC works where it can be sent along in the /authorize request and have AS return it as part of ID_TOKEN. In OIDC flow, it helps mitigate replay attacks and allows clients to validate ID Tokens. The way that implementation works is – the NONCE parameter is persisted along with authorization code in the CTS. That is the only way AS can retrieve and inject that value back in the OIDC token.

    In your case it is the OAuth2 flow as opposed to OIDC – you will have to follow the same design and persist your userId when creating authorization code. Please take a look at DefaultOAuth2TokenStoreImpl.class.

    Hope this helps!

    #28059
     ray.deng83
    Participant

    Hi Jatinder,

    Thanks for the information. We are using AM 6.5.2.1. Do we need to sign a consent to get the source code?

    Best,
    Le

    #28061
     ray.deng83
    Participant

    I’m wondering whether it is possible to retrieve the parameter directly from the request. If that’s possible, it would make things much easier.

    #28062
     Scott Heger
    Participant

    I would look into using a custom scope validator class. I did something similar where I passed a custom scope in my request and my custom scope validator processed it and did whatever I wanted with it. In your case you could pass a custom scope that was something like userId:user123 and have your scope validator process it. See: https://backstage.forgerock.com/docs/am/6.5/oauth2-guide/#sec-oauth2-scopes.

    #28063
     ray.deng83
    Participant

    Hi Scott,

    That could be a doable workaround. Let me check on that. Thanks for the suggestion!

    Best,
    Le

    #28067
     Jatinder Singh
    Participant

    I was under the impression you plan to send your userId in the /authorize request and want AS send it back in the token JWT as part of code exchange. Persisting data in CTS is the only way around that problem. If that is not the case and you are instead sending data part of token request, Scott’s answer is spot on and you can utilize additionalDataToReturnFromTokenEndpoint where you have access to OAuth2Request which encapsulates the original HttpRequest object.

    #28088
     sireeshanp
    Participant

    Hi Scott

    I have a similar requirement where I need to pass a userid attribute as a custom scope while generating the access token per user and get that userid back at the time of validation. Do you have any sample code how to do this?

    thanks
    Sireesha

    #28089
     Scott Heger
    Participant

    Hi @sireeshanp,

    You won’t need custom code for that. Just add your userid attribute to the Scope(s) configuration field of your client profile (assuming you have also added it to your Identity Store’s LDAP User Attributes list if it is not already there). See https://backstage.forgerock.com/docs/am/6.5/oauth2-guide/#configure-oauth2-client for details on Scope(s) and Default Scope(s).

    Hopefully that answers your question.

    Regards,
    Scott

    #28090
     sireeshanp
    Participant

    hi Scott, I tried using resource owner password grant type passing cn or email as scopes (curl below), I am getting access token with scopes as sting cn and email instead of actual user attributes. However I am able to get the user attribute in user_id in the response, this partially serves what I am looking for.

    curl -X POST \
    http://xxxxxxxxxx.iam.com/am/oauth2/realms/root/realms/customers/access_token \
    -u “myClientID:password”
    -H ‘Content-Type: application/x-www-form-urlencoded’ \
    -d ‘grant_type=password&username=testRegistration4%40gmail.com&password=********&scope=cn’

    However the challenge I have is I want to use a grant type where I dont need to pass user password, but still be able to generate an access token embedded with an user attribute (email/any other unique attribute)
    Which grant type supports this? If I run the introspect curl below, I want to see the user attribute in the response

    curl -X POST \
    http://xxxxx.iam.com/am/oauth2/realms/root/realms/customers/introspect \
    -H ‘Content-Type: application/x-www-form-urlencoded’ \
    -d ‘client_id=abcdxyz&client_secret=********&token=y51W-biyLmYhtrhpxZe4lcTAtr8’

Viewing 12 posts - 1 through 12 (of 12 total)

You must be logged in to reply to this topic.

©2020 ForgeRock - we provide an identity and access platform to secure every online relationship for the enterprise market, educational sector and even entire countries. Click to view our privacy policy and terms of use.

Log in with your credentials

Forgot your details?