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.