Replace /userinfo call with the existing JWT info

[hexedpackets]

The response from auth0 when authorizing returns both a token and an id_token. The id_token seems to have the same information as the /userinfo endpoint, making the extra call unnecessary.

Would you be open to a PR that decodes the id_token JWT for creating the user struct? The reason I want to do this is if an Auth0 API is using HS256 as its signing algorithm, there's no way to get an access token for both the API and the /userinfo endpoint.

[achedeuzot]

Hi @hexedpackets, thanks for your other pull-request :)

I'd be happy to remove the call to /userinfo under two conditions:

• there's a documentation on auth0 website confirming that the id_token contains exactly the same content than what is returned by the /userinfo endpoint (including metadata etc.) and hopefully, it will continue to be the case in the future so we don't need to rollback or have a bad surprise,
• there's documentation on auth0 website confirming that every OAuth2 call to auth0 will include a JWT id_token and not an opaque token. I believe in the first versions of my usage of auth0, I didn't have any id_token and was receiving an opaque token but it was a long time ago. I just want to make sure we're not leaving some users behind that wouldn't have this enabled and have broken systems on upgrading (or we need to plan a major release).

Thanks very much for your contribution !

[hexedpackets]

So as far as documentation, the most explicit page I've found is the OpenID Connect Scopes description which states:

Once the user authorizes the requested scopes, the claims are returned in an ID Token and are also available through the /userinfo endpoint.

The ID Token Structure page also describes the token in more detail, although it doesn't mention /userinfo, just the OIDC claims in general.

I can't say if it was always the case or when it might have changed, but the current OAuth code exchange will always return the ID token. The Authorization Code Flow doc states this:

8. Your Auth0 Authorization Server responds with an ID Token and Access Token (and optionally, a Refresh Token).

It might not be the case for other flows, but unless I'm mistaken the code exchange is the only OAuth flow this library uses.

Does that evidence sound reasonable to you? I actually already have the JWT decoding on a branch in my fork, so it would be pretty quick to put together a PR for it.

[achedeuzot]

Hey :)

This evidence sounds reasonable indeed. Let's try this. Let's create the PR and I'll do some tests on a live auth0 system to check if I always get a JWT ID token even when changing the auth0 options and if it works, we'll use it instead of the /userinfo endpoint. Do you think it would be interesting to add an option to allow users to choose which method to use ? I'n not sure there is but you may have an idea.
Also, please include some tests if possible to ensure we have proper testing of this new way of doing things.

Thank you very much !

[taj]

Hello!

We are running into Rate Limit errors because of this, Auth0 support suggested we use the id_token as well.
I'll take a stab at implementing this in the next few days!

[taj]

@achedeuzot Draft PR here: #235

What do you think? :)