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 the email or username 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 the id_token when available. This parameter may not be provided and will be undefined in that case. This is read-only.

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 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) {
  // 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.

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.