OpenID Connect Reconcile Lambda
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, id_token) {
// Lambda code goes here
}
This lambda must contain a function named reconcile
that takes at least three parameters, a fourth parameter is optional. The parameters that the lambda is passed are:
-
user
- the FusionAuth User object. You can modify this, except theemail
orusername
attribute may not be modified after the user has been linked. -
registration
- the FusionAuth UserRegistration object. You can modify this. -
jwt
- the JSON payload returned from the OpenID Connect Userinfo endpoint. This is read-only. -
id_token
- the JSON payload returned in theid_token
when available. This parameter may not be provided and will beundefined
in that case. This is read-only.
The id_token
parameter has been available since 1.31.0.
The two FusionAuth objects are well documented in the User API and Registration API documentation.
The jwt
object contains the payload from the Userinfo endpoint. It may contain well known OpenID Connect registered claims as well as any custom claims defined by the Identity Provider.
The id_token
will be provided to the Lambda only:
-
when it is returned by the Identity Provider and
-
it has been signed using the
client_secret
and an HMAC algorithm
In particular, if the id_token
is signed using an asymmetric key-pair, it will not be available to the Lambda.
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, id_token) {
// 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;
// The id_token may be available depending upon your IdP configuration.
// - Ensure the value is defined before accessing it.
if (id_token) {
user.data.companyName = id_token.companyName;
}
// 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));
Modifying Email and Username Claims
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.
This capability is available beginning in version 1.31.0
. It was also available from 1.17.3
to 1.28.0
.
If the Userinfo or Id Token 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. Modifying the username or email address may cause your lambda to be run two times. It will be run again if you modify the linking strategy claim and an existing user is found that matches.
You can’t modify an email claim if the linking strategy is username or the username claim if the linking strategy is email. Modifying the claim that is not being linked on will be ignored because doing so could cause collisions if you were to change the linking strategy later.
Feedback
How helpful was this page?
See a problem?
File an issue in our docs repo
Have a question or comment to share?
Visit the FusionAuth community forum.