Calling webAuth.client.login does not include user_metadata in the ID token

When I use Lock like this:

var lock = new Auth0Lock('clientId', 'domain', {
    auth: {
        params: {
            scope: 'openid email user_metadata'
        },
        redirect: false
    }
});

in the response I receive id_token with user_metadata in it.

However, when I use Auth0.js like this:

webAuth = new auth0.WebAuth({
    clientID: 'clientId',
    domain: 'domain',
    responseType: 'id_token',
    scope: 'openid email user_metadata'
});

webAuth.client.login({
    realm: 'clientDb',
    username: 'username',
    password: 'password'
}, function(err, authResult){
    console.log(authResult)
});

there is no user_metadata in the id_token from the response.

Am I dong something wrong? Is there a way to get user_metadata in id_token provided by webAuth.client.login or do I have to use Lock?

TL;DR The approaches mentioned use different underlying authentication endpoints/methods that result in the different behavior. See the docs about the introduction of OIDC conformant authentication.


When using non-OIDC conformant authentication (aka legacy and the one being used with the Lock configuration you mentioned) then including user_metadata as one of the requested scopes would lead to the user metadata being included in the issued ID token.

When using OIDC conformant authentication (aka new and the one being used with the Auth0.js configuration you mentioned) then the contents of the ID token will not include the user_metadata as a claim even if you request it as part of the scope. This is due to the fact that user_metadata is not a standard OIDC claim.

In the OIDC mode you can include custom claims in the issued token. For reference information on how to include custom claims see:

1 Like

But, in OIDC mode (which is automatic with Auth0.js v8 AFAICT?) we can’t access the user_metadata in that rule because it’s been stripped from the user object before the rule gets called.

But, in OIDC mode (which is automatic with Auth0.js v8 AFAICT?) we can’t access the user_metadata in that rule because it’s been stripped from the user object before the rule gets called.

OIDC mode is automatic when doing API authorization (aka audience parameter) requests. Auth0.js v8 supports API authorization, but does not impose it to you so you can still make requests without the audience parameter and as such that request may not be using OIDC mode. The problem you describe also seems unrelated to OIDC mode as it’s happening on a rule which should have access to user metadata in both modes.