Access token not a JWT after SAML IDP initiated SSO

[hspeeters]

Hi

I’ve set up a SAML IDP initiated SSO scenario with a customer of ours, and we can successfully authenticate. I now want to use the result of this to authenticate users of our SPA client with our API. We were using the access_token that get sent back after de OIDC “handshake” when using a username/password login flow, so I tried the same with the SAML flow.

I’ve added the following query string in the IDP initiated SSO settings of the SAML connection: response_type=token id_token&scope=openid. That way the right information is sent back to the application. However, the access_token that is sent to our application, is not a JWT token. It looks like this: damxXRX2j8aPxN_v78NaBfbD1vP0Ro06.

I think this has something to do with the fact that I need to specify an audience when requesting a token, as suggested here: Strange access token returned by SAML. But I have no idea how to accomplish this. Is this possible in any way? Or is there another way to get the access_token?

The id_token that is sent back to the application is valid, and I can read the user information etc. I could use that one to send to the API to figure out which user is logged in, but then the API audience can’t be checked and using the id_token instead of the access_token is apparently not recommended (Access Tokens).

Anyone able to point me in the right direction? Thanks!

[jmangelo]

When using a SAML IdP-Initiated flow and you configure the connection to respond with an OpenID Connect response to a specific client application there is no support for API authorization so in other words you won’t be able to receive an access token suitable to call one of your own custom API’s that you configured in the dashboard.

However, as part of processing the response form the IdP-Initiated flow the client application may consider to perform a subsequent OIDC/OAuth 2.0 request that uses prompt=none so that an immediate response is provided and an additional audience parameter for the API in question. Depending on API configuration this could allow the application to now obtain an access token suitable to the API in a transparent way for the end-user (although with a slight overhead of an additional request).