I am just starting to work with Auth0 and SSO so forgive the probably simply question. I have successfully created a custom connection to our API so that I can have my SPA app authenticate through it and retrieve key user information.
I can successfully authenticate and get both the access_token and id_token back. But I cannot seem to retrieve the properties I returned back from my custom connection to my API. I have used various scopes “openid email profile” but I still do not get back this information. I used the JWT.IO debugger and decode both tokens and still don’t see it. Is this information located in the last section of the JWT token? And if so where I can get the key used to decode this information.
Is it possible to use console log statements in the script in order to see what’s happening? Also your connection script would be helpful, making sure to remove any sensitive info
It seems when I test it I do get back the info I was looking for in my profile. I just don’t know how that gets added to my tokens as I do not see it. Any way here is the script. I simply calls an existing API call with username&password.
=====================
function login (email, password, callback) {
var emailPassword = email + ":" + password;
var emailPasswordBase64 = new Buffer( emailPassword, "utf8" ).toString("base64");
var authString = "Basic " + emailPasswordBase64;
request.get({
url: configuration.QA + "/v1/users/info?email=" + email,
headers: {
authorization: authString
}
//for more options check:
//https://github.com/mikeal/request#requestoptions-callback
}, function (err, response, body) {
if (err) return callback(err);
if (response.statusCode === 401) return callback();
var user = JSON.parse(body);
callback(null, {
id: user.id,
email: email,
currentTenantId: user.currentTenantId,
currentOrgNumber: user.currentOrgNumber,
currentOrgName: user.currentOrgName,
currentOrgRole: user.currentOrgRole,
currentOrgType: user.currentOrgType,
culture: user.culture,
});
});
}
I made the assumption that these properties would automatically come back in the id_token. It seems not to be the case. With some experimentation I wrote a rule that included the user object in a namespace. It then came back and now I see the data once I decode the token. The documentation does not call that out at all. Hopefully this is the accepted way to retrieve this information at authentication time. Let me know if I am correct that I have to write a rule for this.
@craig jumping in here, yes you can add custom claims to your id_token via a Rule (OpenID Connect Scopes) . Please let me know if this is what you are referring to!
Yes this is what I was referring to. So I was able to get information back to my SPA front end in the idToken but more importantly I needed a few key pieces in the Access token so that my WebApi would know the current user and role through the existing claims mechanism. It took me a little sleuthing but found that if I added this to the rule
I could use my existing principle claims code to get the current user, current role and current user id from the Access token. Those namespaces where key.
