ID token as SSO Token for authorization endpoint

Hey All,

We would like to use the ID Token as SSO Token in certain circumstances.
I have followed the instructions here => ForgeRock Access Management 7.0.2 > OpenID Connect 1.0 Guide > Additional Use Cases for ID Tokens and configured OAuth2Provider with the client.

However, when I do

 curl --request GET -s --dump-header - \
    --header "iPlanetDirectoryPro: $id_token" \
    "${AM_HTTP_URL}/oauth2/customer/authorize?scope=openid%20my:scope&response_type=code%20token%20id_token&client_id=$1&nonce=1234"

it does not return code and id_token, rather does a 302 with OAUTH_REQUEST_ATTRIBUTES cookie.

The original ID Token was generated using the authorization_code grant flow

Just looking for any examples on similar ground.

Thanks
Josh

Hi @joshfr

Can you elaborate a bit on what you are expecting to happen here? I wouldn’t expect you to get both a code and an id token in any scenario, and in this scenario you already have an id token so I’m not sure what you would even want to get by calling the authorize endpoint.

What’s the overall use case? You have a user with a (presumably) valid id token, and based on the linked documentation you would like to use this token to access an AM endpoint without needing to reauthenticate the user. Is that accurate? If so, I’d expect that your request would go directly to the AM endpoint in question instead of the authorize endpoint, as you have already received the appropriate id token which you can use in lieu of a session token.

Thanks,
Mike

1 Like

Thanks for the reply @mwtech

our’s is a bespoke use-case whereby the customer is loggedIn to a native (Android) app (say A) and then gets redirected to third party in webview(say B - with the id token) and from the third party website B - would like to pull the data from the original domain A
I was evaluating if third party can invoke /authorize with the ID Token, to trigger the RCS and the consent flow.

Cheers
Josh

sounds like the Hybrid flow to me

In an abstract manner, perhaps. But this is going about it improperly.
As @mwtech eludes, /authorize is there to “authorize” the issuance of an OAuth2 token.

And /json/sessions/$SESSIONID?_action=validate will validate a “legacy” AM session, thus confirming a valid AM authenticated session.
(Of course, you now have to consider an “agent profile” for the alternate domain accessing AM)
If you wanted /json/sessions?_action=getSessionProperties… to reference the valid session properties

If you need to “share” properties within the context of an id_token, we really need to set up additional “claims”.

Hi @joshfr

The 302 that you reference in the response in your original post - what is the value of the Location header in the response? Are you being redirected to a URL to the RCS you’ve configured? Or is your concern here that you are being redirected to a login page and you believe the id token is being ignored as a session token?

If I understand correctly, App A has its own client configured and has already requested and received an id token for the user. App B is set up as its own client and has somehow received the id token from App A and would like to use that during a request to the authorize endpoint to request their own id token and an auth token, but bypass the authentication and move straight to the consent step of the flow. Is that accurate? Or am I misunderstanding the use case?

Thanks for all the replies, appreciate the same!

I agree invoking /authorize seems bit weird considering ID Token is already issued and have decided to pursue an alternate path to go about this use case.

Cheers
Josh

1 Like