Verifying access_token inside API

Here are the steps i did

  1. Created a silent login URL.
  2. This successfully redirects me to the intended page with an authorization code and state.
  3. I made a POST call to /auth/token and received an access_token (the json returned also gives an id_token) .
  4. I then passed the access_token in Authorization header (with Bearer string prefixed to access_token).
  5. Used the express-jwt (as per boiler plate code in auth0 site) to verify the access_token, but i keep getting message jwt malformed.

I seem to get 64 bit encoded string as access_token. This string when i pasted in jwt.io, did not decode.

I tried passing id_token instead and it worked. However i see a note in auth0 site, that id_token should not be used for securing APIs How do I verify the access_token inside API? Have i missed some step?

You must configure your resource server (aka API) in the APIs section of the dashboard; as part of this configuration you will provide a unique identifier for the API and also currently configure the signing algorithm used in the JWT access tokens that are issued for authorization requests targeting this API.

In addition, your client application must ensure that it performs an authorization request that states that it wants to receive an access token suitable to your API. It can do this by including an audience parameter where the value is the identifier you configured previously for the API.

Having met the above requirements then the access token received by the client application will indeed be a JWT (in future other formats may be supported, but you would be able to choose at API configuration time).

As additional note, the access token you’re receiving is likely only suitable to call the /userinfo endpoint because you either did not specify an audience or specify one associated with that endpoint. In this case since it’s the /userinfo endpoint that validates the access token the actual format is unspecified; at this time is an opaque token, but again that can change without notice because both the issuer and consumer are controlled by the Auth0 service itself.

1 Like