Downsides to using `userinfo` endpoint instead of express-jwt?

I am using the auth0-spa-js SDK for our SPA, which also makes calls to our API.

The Auth0 QuickStart documentation recommends using the express-jwt and jwks-rsa libraries to parse the token on the backend.

However, that middleware only populates an object with the standard JWT fields and does not include the user’s profile information. Since authorization is handled via application logic, I need to at least know the user’s email.

To get that email, I am using Auth0’s /userinfo endpoint. That endpoint returns essentially the same info provided by the express-jwt and includes the user’s email address.

Do I need to use the express-jwt and jwks-rsa middleware if I’m just going to send the token to the userinfo endpoint? Are there any security implications of not those libraries? What is the value of those libraries if its just as easy to send the token to the userinfo endpoint?

Thank you.

1 Like

Hi studsterkel, and welcome to the community! :tada:

If you add “email” to the list of requested scope you should receive the email back in the JWT id token.

The id token is really just provided as a convenience so you don’t have to make an additional request to the /userinfo endpoint.

However, you do not want to use the JWT id token for authorization. It is just a cache for the authentication event. What you want to do is validate the JWT access token with the middleware, and use that for authorization. The JWT access token is self-verifying, meaning the libraries can verify it without making an external request. This is different than the opaque access token (which can only be used on the /userinfo endpoint) and cannot be verified using the libraries.

Does that make sense? Please let me know if you have any questions about that.

1 Like

Hi Thomas,

Thanks for your response. I’m sorry but I don’t understand. You advise that I should not use the JWT id token for authorization, but I am not. I am making a “GET” request to the /userinfo endpoint with the access token in the Authorization Header.

Given that I am using the access token and not the id token, is this OK from a security perspective? Thank you for the suggestion of adding “email” to the list of requested scope, but assume for this case that we do not want to do that.

Thanks again for your time.


Sorry, I misunderstood what you are doing.

Yes, it is fine to use the access token to call the /userinfo endpoint. Since you are using the full JWT access token, you want to use those libraries to verify it is valid on your backend.

However, are you using the token only to access the /userinfo endpoint? If you are only using it to access the user info endpoint, then you can remove the audience param from your /authorize call and simply get an opaque access token back. This token does not need to be verified like a full JWT access token does.

If however you’re using the access token for anything other than hitting /userinfo, then you need to use those libraries to verify the full JWT access returned.

Please let me know if you have any questions about that.