Good Afternoon,
We are looking to use Auth0 for IdP initiated flow. I have set up Auth0 as SP as well as Auth0 as an IdP (for testing) in another tenant. Everything is going great except when i get the id_token back in my application, it is missing profile, email, etc. The token does contain iss, sub, aud, iat, exp, ar_hash, which is great.
The issue is that even when i specify the query string in the IdP-Initiated Flow query string box as “redirect_uri=http://localhost:3000&response_type=token id_token&scope=openid profile email” no profile or email information exists in the token. When I look at the user’s raw JSON data in the dashboard, email, given name, etc. is in there.
I did create a workaround by getting an access token using Auth0 API (/oauth/token) using client secrets and then calling (/api/v2/users/samlp|samlconnectionhere|auth0|5ce5451b5cbc491139e73ede) and the profile information is returned no problem.
I was hoping to avoid this extra workaround call and simply parse the claims out of the token.
I will answer my own question with a few options.
We do have (response_type=token id_token&scope=openid profile email&audience=https://mydomain.auth0.com/userinfo) in the SAML connection query string settings
We are getting at least “sub” in the token as in (“sub”: “samlp|mysamlconnection|auth0|5ce5b64543e1b31106e56992”) so we can use this in a call to the API /api/v2/users/samlp|mysamlconnection|auth0|5ce5b64543e1b31106e56992 from our app and get the full profile of the user. This extra call is really not too big of a deal.
I created a rule and mapped the desired profile properties to the id token as in:
//gets a specific custom attribute from our SAML that we mapped into token
//this is a custom piece of data specific to our needs, you will not likely have this one
context.idToken[‘http://mydomain.com/entity_access’] = user.entity_access;
//As a test, created a a key value pair in Rules Settings and added to token
context.idToken[‘http://mydomain.com/custom_data’] = configuration.custom_data;
callback(null, user, context);
}
these mapped properties are now available in the returned jwt token