For the last few days I’ve struggled getting AM6(Forgerock Access Management) to work with the same config as AM5. I’m trying to validate a session, after an user performed the OpenID Connect Authorization Code Flow.
My setup:
I’ve deployed an AM instance
Configured OpenID Connect from the Common tasks.
Added an OAuth2 client, from Applications -> OAuth 2.0. Setup all configs: redirect uris, scopes lifetimes etc and set “Token Endpoint Authentication Method” to client_secret_post
(OPTIONAL) Added implied consent to OAuth 2.0 Client, and then set Services -> Oauth2 Provider -> Consent -> Allow clients to skip consent = true
My token usage:
After redirecting the user to the login screen(and receiving the code), I make a POST to the token endpoint (/oauth2/access_token
) with form_params
(
[client_id] => my_client
[client_secret] => my_client_pass
[code] => a5867a21-4d5a-4285-ba07-dcbe46d53bc6
[redirect_uri] => http://localhost:3000/auth/callback
[grant_type] => authorization_code
)
The redirect_uri endpoint receives access_token
and id_token
(
[access_token] => e78569fb-e162-4e4f-ab5e-79ebeaf2ba94
[scope] => openid offline_access profile email
[id_token] => eyJ0eXAiOiJKV1QiLCJraWQiOiJiL.......
[token_type] => Bearer
[expires_in] => 35999
)
(HERE’S THE PROBLEM) I then check to see if the user’s session, with the given id_token, is still valid (he has logged out or not)
I make a POST to the sessions endpoint(/json/sessions
) with
(
'headers' => [
'Accept-API-Version' => 'resource=1.2'
],
'query' => [
'_action' => 'validate',
'tokenId' => eyJ0eXAiOiJKV1QiLCJraWQiOiJiL082T.......
],
)
When tried against AM5 I get
{"valid":true,"uid":"my-user-here","realm":"/"}
When tried against AM6.0.0.4 I always get:
{"valid":false}
Am I missing something which prevents the generated openid id_token to be available in the sessions endpoint?
If anyone stumbles across the same issue, I've found that I missed an important setting that was added in AM6: Authorized OIDC SSO Clients.
This forces your session id to be the same as your id_token from OpenID Connect.
Another solution would be to look into using the /oauth2/connect/checkSession
endpoint for validating the token