Get user info

Help
, , ,
1

I followed this tutorial The Complete Guide to React User Authentication with Auth0 to setup a webpage and I’m trying to print to console the user info however all I am getting is :

{ iss: 'https://nepherius.eu.auth0.com/',
  sub: 'google-oauth2|109132913184186845247',
  aud:
    'https://nepherius.eu.auth0.com/api/v2/',
     'https://nepherius.eu.auth0.com/userinfo' ],
  iat: 1511513452,
  exp: 1511520652,
  azp: 'pwawvou4mnNJuMuV5Glx2a0Vz4X7imup',
  scope: 'openid profile email' }

This is my config, let me know if you need extra info:

server.js
const authCheck = jwt({
  secret: jwks.expressJwtSecret({
        cache: true,
        rateLimit: true,
        jwksRequestsPerMinute: 5,
        // YOUR-AUTH0-DOMAIN name e.g https://prosper.auth0.com
        jwksUri: 'https://nepherius.eu.auth0.com/.well-known/jwks.json'
    }),
    // This is the identifier we set when we created the API
    aud: 'https://nepherius.eu.auth0.com/api/v2/',
    iss: 'https://nepherius.eu.auth0.com',
    algorithms: 'RS256']
});
app.get('/api/jokes/celebrity', authCheck, (req,res) => {
  console.log(req.user);
})

AuthService.js
const ID_TOKEN_KEY = 'id_token';
const ACCESS_TOKEN_KEY = 'access_token';

const CLIENT_ID = '345dfsdfsdf234sdfsdfsdf4gfhf';
const CLIENT_DOMAIN = 'nepherius.eu.auth0.com';
const REDIRECT = 'http://localhost:3000/callback';
const SCOPE = ' openid profile email identities';
const AUDIENCE = 'https://nepherius.eu.auth0.com/api/v2/';

No rules have been added and nothing has been modified, all the default settings on auth0 dashboard.

2

There are a couple of things worth mentioning, the most relevant is that the output you showed is consistent with an access token using the JWT format. You’re using an audience value of https://nepherius.eu.auth0.com/api/v2/ which is associated with the Auth0 Management API v2 and at this time the access tokens issued for that API are indeed JWT’s.

However, the user information claims requested through OIDC scopes like profile and email are included, if available, in the ID token; not in the access token. In addition, the client application should treat the access token as an opaque value and not do any assumptions on its format. The only thing the client applications does with the access token is to send it to the API(s) to which the token is applicable to.

In conclusion, you should be outputting the contents of the ID token which is guaranteed, by specification, to always be a JWT and then if you still don’t see the information requested we’ll need at other possible issues.

Also have in mind that the use of the Auth0 Management API v2 identifier as an audience is a bit unexpected and that including identities as one of the scope values will have no effect because that’s not a scope value contemplated in the OIDC specification and as such it could only have some effect if the API specified in the audience value did specify it; which is not the case.

3

So the data is saved on local storage under id_token however it’s still incomplete as app_metadata and user_metadata are missing.

Also in almost every example of auth0 setup I’ve seen client_secret is used but not in the blog post I linked to in my main post. How is it secure if the secret is not used?

4

Is it a good idea to add user’s email / data as custom claim in access token?

5

So the data is saved on local storage under id_token however it’s still incomplete as app_metadata and user_metadata are missing.

Also in almost every example of auth0 setup I’ve seen client_secret is used but not in the blog post I linked to in my main post. How is it secure if the secret is not used?

6

Is it a good idea to add user’s email / data as custom claim in access token?

7

The link you posted is for a React.js application which runs in the browser so it’s considered an OAuth 2.0 public client. The secret if included would be available to anyone which is useless so no point in including it.

As hinted in the answer, only OIDC standard claims will be included in the ID token depending on the scopes requested. Custom data needs to be included explicitly; see: OpenID Connect Scopes

8

Provided a more detailed answer in the question you posted about this, but the short answer is that it can be an acceptable approach depending on the overall system.