OpenID Connect Reconcile
OpenID Connect Reconcile lambda
When an OpenID Connect identity provider is used to complete a federated login request FusionAuth will use well known OpenID Connect claims to reconcile user.
It is common that the claims returned from the Userinfo endpoint during an OpenID Connect login request will contain custom claims defined by your identity provider. In order to utilize these custom claims you may wish to use a lambda assist FusionAuth during the login request to reconcile these claims to the FusionAuth user.
When you create a new lambda using the FusionAuth UI we will provide you an empty function for you to implement. If you are using the API to create the lambda you will need to ensure your function has the following signature:
function reconcile(user, registration, jwt) {
// Lambda code goes here
}
This lambda must contain a function named reconcile
that takes three parameters. The parameters that the lambda is passed are:
-
user
- the FusionAuth User object -
registration
- the FusionAuth UserRegistration object -
jwt
- the JSON payload returned from the OpenID Connect Userinfo endpoint
The two FusionAuth objects are well documented here in the User API and Registration API documentation. The JWT object that contains the payload from the Userinfo endpoint may contain well known OpenID Connect registered claims as well as any custom claims defined by the identity provider.
Assigning the lambda
Once a lambda is created, you may assign it to one or more OpenID Connect IdPs in the IdP configuration.
Navigate to
and select your existing an OpenID Connect configuration or click and select OpenID Connect if it has not yet been configured.Example lambda
Here is an example of a simple Lambda that assists FusionAuth to reconcile the User from a successful GitHub login request.
function reconcile(user, registration, jwt) {
// This is an example lambda function reconcile the GitHub login
// Set GitHub Avatar URL to the FusionAuth imageURL
user.imageUrl = jwt.avatar_url;
// Update the registration username to the GitHub short name
registration.username = jwt.login;
// Store the company and location returned from GitHub in custom user data.
user.data = user.data || {};
user.data.company = jwt.company;
user.data.location = jwt.location;
// Create an event log of type 'Debug' when the lambda has Debug enabled
console.debug('FusionAuth reconciled a User from GitHub and I helped!');
}
During development if you want to get a better idea of what your IdP is returning in the jwt
object, you may print the contents of this object to the Event Log to help you write the lambda. Add the following line of code to your lambda to dump the entire object to an informational event log.
// Pretty print the jwt object to the Event Log
console.info(JSON.stringify(jwt, null, 2));
Workarounds
If the JWT from the OIDC identity provider does not come back with an email claim you can add your own. This claim is email
by default but may be changed with the oauth2.emailClaim
as documented in the API docs.
If the Userinfo response available to you in the lambda has unique user information, you can build a fake email address from it.
Here, the sub
claim is the unique user id, and we’re building an email address:
function(user, registration, jwt) {
// The user's unique Id is the 'sub' claim.
user.email = jwt.sub + '@no-email-present.example.com';
}
Make sure you pick an email address for a domain you control to avoid malicious attacks. This will run your lambda twice.
This workaround only is available if you are on version 1.18.7 or greater and if no claim is returned.
Limitations
The user.email
field on the user will be ignored if modified by the lambda function. This is to protect the integrity of the email
claim returned by the identity provider. The user.username
field on the user will be ignored if modified by the lambda function. This is to mitigate the risks of an account takeover due to a non globally unique identifier.