Logo/Docs

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, tokens) {
  // 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:

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 was returned by the IdP and the signature can be verified. The id_token will be returned by the Identity Provider when the openid scope was requested.

The signature can be verified in one of two ways:

Please note that prior to version 1.48.0, this parameter was only available if it had been signed with the client_secret using an HMAC algorithm.

The tokens parameter will always be present and will contain the encoded version of the access_token. When the id_token is present and the signature has been verified, this object will also contain the id_token in the encoded form. These tokens may be useful if you need to use the HTTP Lambda Connect feature to make an external API call using either of these tokens.

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 Settings -> Identity Providers and select your existing an OpenID Connect configuration or click Add provider 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, tokens) {
  // 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

FusionAuth will require an email or username to create a user. However, if the response from the Userinfo endpoint, or the id_token does not return an email claim you can optionally create a unique value to satisfy this requirement. This claim is email by default but may be changed with the oauth2.emailClaim as documented in the OpenID Connect Identity Provider API.

This capability is available beginning in version 1.31.0. It was also available from 1.17.3 to 1.28.0.

In this example, we will assume the the jwt or id_token objects contain unique user information such as the sub claim. This unique value can be used to fabricate an email address.

function(user, registration, jwt, id_token, tokens) {
  // 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.