Auth0 Home Blog Docs

Why do I only get a subset of id_token where I should get more info?

id_token
golang

#1

I have followed Go quick start guide from here https://auth0.com/docs/quickstart/webapp/golang

and I am trying to get as much info about user as possible from id_token but somehow I am only getting a subset, namely:

decoded profile JSON from https:// + domain + /userinfo return only identity providers ID together with location (which I have programmed in Rules)
So something like:

mapsub:github|73XXXX https://example.com/country:$COUNTRY https://example.com/timezone:$TIMEZONE

while id_token (after decoding) gives only this:

exp - 1511508312.000000
https://example.com/country - $COUNTRY
https://example.com/timezone - $TIMEZONE
iss - https://DOMAIN.eu.auth0.com/
sub - github|73XXXX
aud - ZXXXXXXXXXXXXXXXXXXXXXXXXXX
iat - 1511472312.000000

yet I am authenticating with the following URL:

 https://DOMAIN.eu.auth0.com/authorize?audience=https%3A%2F%2FAPI_DOMAIN&client_id=ZXXXXXXXXXXXXXXXXXXXXXXXXXX&redirect_uri=http%3A%2F%2Flocalhost%3A3000%2Fcallback&response_type=code&scope=openid+profile+email&state=4%2Fs6vCKUD%2BgCBqEO5Db4j2eXjHAOCfkTIOj%2BAcG7w3Y%3D

#2

There are a few possible explanation for something like that, in particular:

  1. the end-user in question does not have the associated properties in its user profile.
  2. you have a rule that is overriding the granted scopes and removes the email and profile scopes from the set of scopes granted as part of the authentication/authorization transaction.
  3. you customized the hosted login page in such way that the scopes sent in the initial request are being lost when continuing the authentication process. For example, not configuring Lock correctly in terms of consuming the config.internalOptions that are injected to the hosted login page.

Given you showed that you were trying with a GitHub end-user then that pretty much rules out option one as IIRC GitHub will return email information and other OIDC profile properties.

You can also quickly rule out option two by either ensuring no rule sets context.accessToken.scope or simply doing a quick test with all rules disabled.

Since the information you’re obtaining is consistent with the authentication request being completed as if only the openid scope had been requested and it’s unlikely that you set a rule that forces only the openid scope and would not remember of it I would say that option three would be the most likely.


#3

Not setting config.internalOptions correctly was my case. Thanks again for brillitant support!


#4