Auth0 Home Blog Docs

Strange access token returned by SAML

saml
sso
access_token
login
access-token

#1

So I’ve set up and configured an SAML identity provider connection which connects to the system of a customer of ours. Using the “try it” button shows that it is correctly configured.

We are using the /authorize endpoint (with response_type=token), which correctly redirects to the login page. Entering credentials then redirects the browser to: https://server/#access_token=3fqP9byYBzZS_WGF&expires_in=86400&token_type=Bearer

I don’t understand the access token value. Isn’t it supposed to be a JWT? How am I supposed to use this token? Or is the identity provider incorrectly configured?


Access token not a JWT after SAML IDP initiated SSO
SAML login, invalid_token for SPA application
#2

The access token format is an implementation detail between the authorization server (in this case your Auth0 account) and the resource server. This means that different formats can be used as long as both of the intervening parties agree with the format and support it.

Also have in mind that even though an additional actor (the client application) receives this access token, the client application should treat it as an opaque value and make no assumptions about the format. In this case, given you received a non-JWT access token it likely implies that you only requested an access token that allows you to get user information about the authenticated user.

In this scenario the resource server is the Auth0 user information endpoint and one of the formats supported by that endpoint is a short opaque access token.

If you want to receive a JWT token that contains within itself information about the end-user then you need to perform a request following the OpenID Connect (OIDC) specification an include a response type that also requests an ID token and in addition include the openid scope. An ID token will always use the JWT format because the OIDC specification mandates it. In addition, an ID token can be parsed and processed directly by the client application.

If you want to receive an access token that can be used to authorize calls to resource servers (aka API’s) that you implement yourself then you need to include the audience parameter for the respective API as part of the request. Currently, for a request with an audience associated with your own API, a JWT access token will be issued because that will allow your API to validate the token without additional calls. See API Authorization for more on this subject.


#3

I believe the problem is that the audience is ignored when it’s the SAML Identity Provider that initiates the request. The default user info audience is used instead of an API identifiers, which generates the short JWT. Can you provide a workaround for this case (SAML Identity Provider initiated auth for an access token with API audience)? Thanks


#4