SAML as Service Provider - Missing Profile

[thecrazyroach]

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.

Please help. Thanks!

[thecrazyroach]

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

1. 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.

2. I created a rule and mapped the desired profile properties to the id token as in:

function (user, context, callback) {
//Get the user’s email from the user object
context.idToken[‘Google Workspace for Business - Google Workspace Pricing & Features - MyDomain.com’] = user.email;

//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

{
“Google Workspace for Business - Google Workspace Pricing & Features - MyDomain.com”: “test_user@mydomain.com”,
“http://mydomain.com/entity_access”: “1|2|3|4|6”,
“http://mydomain.com/custom_data”: “testvalue”
}

Good luck guys!