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.
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.
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”.
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?
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.