Last Updated: Nov 14, 2024
Overview
Currently Auth0’s OpenID Connect Enterprise Connection is being used to integrate customers’ IdPs with Auth0.
During testing, when integrating with Okta and using OpenID Connect Enterprise Connection’s “back channel” connection type, “thin” id_tokens from Okta are being recieved(“thin” id_tokens are id_tokens with most of the claims stripped out). This is because according to OIDC specs, an IdP can return a “thin” id_token when both id_token and access_tokens are requested. The rationale is that the user would then call the userinfo endpoint to get the remaining claims. While “thin” id_tokens are technically part of the OIDC specs, many IdPs do not follow this pattern. Since Auth0’s OpenID Connect Enterprise Connection does not call the userinfo endpoint on our behalf, this leads to inconsistencies in user attributes between IdPs that do send complete id_tokens vs IdPs that send “thin” id_tokens.
After testing it was decided to switch all of the OpenID Connect Enterprise Connections to “front channel” connection type to get around the “thin” id_token issue., This connection type only requests id_tokens, which now results in longer receiving “thin” id_tokens.
Applies To
- OIDC
- Enterprise Connection
Cause
Okta only returns a “thin” ID token when an access token is also requested, as per an Authorization Code flow. The intention is that the access token will be used to call Okta’s /userinfo endpoint to get the full “fat” ID token with all claims, including custom claims the IdP using Okta may have added.
For more information, see: Okta Groups or Attribute Missing from ID Token
Solution
Changing OIDC connection to front channel will change to using an implicit flow and the full ID token will be returned. This is is the simplest fix. However if the front channel solution is not preferred the back channel may be used to resolve the issue.
To use the back channel to resolve, a Custom OAuth2 connection can be created which will be able to call userinfo automatically after receiving the Okta tokens. This can then be used to map the full profile into Auth0 as required.
Additional information can be found here: Connect Apps to Generic OAuth2 Authorization Servers
Sample script:
function fetchUserProfile(accessToken, context, callback) {
request.get(
{
url: 'https://XXXX.okta.com/oauth2/v1/userinfo';,
headers: {
'Authorization': 'Bearer ' + accessToken,
}
},
(err, resp, body) => {
if (err) {
return callback(err);
}
if (resp.statusCode !== 200) {
return callback(new Error(body));
}
let bodyParsed;
try {
bodyParsed = JSON.parse(body);
} catch (jsonError) {
return callback(new Error(body));
}
const profile = {
user_id: bodyParsed.sub,
email: bodyParsed.email,
zoneinfo: bodyParsed.zoneinfo,
name: bodyParsed.name
};
callback(null, profile);
}
);
}
There are plans to enhance the OIDC connections to support calling userinfo for example, but the Expected Delivery Timeline is not available yet. We will keep you updated once further information is available.