Userinfo procedures#

OpenID Connect UserInfo script procedures are a subtype of token script procedures and return a set of Claims about a user authenticated by a given access token.

The openid scope is required to access endpoints of this type. The claims returned to the requesting client depend on the scope of the access token.

Common API#

UserInfo procedures have access to all the Common Procedure API .

Claims#

OpenID Connect defines a set of Standard Claims returned by the UserInfo endpoint:

Attributes of the address claim:

For a more detailed description of each claim, please consult Section 5. of the OpenID Connect Core specification.

The returned claims are filtered based on the scopes of the access token before they are passed to the requesting client. The sub claim is not covered by a scope and is always returned.

A note on the email_verified and phone_number_verified claims. These are currently mapped to true only if the type attribute on the e-mail address or phone number in the account attributes is set to “verified”. This is currently only set for the phone number when number is registered using SMS OTP authenticator and not set for the email address (for example when registering through the e-mail authenticator) but is planned for a future release.

Common API#

Userinfo procedures have access to all of the Common Procedure API .

Function#

The result function takes one argument, the context object which provides it with all information and helpers it may require.

The context object has type OpenIdConnectUserinfoTokenProcedureContext.

result(context)#

The main function of a transformation procedure

Parameters:

• context - The context object for transformations.

Returns: claims to be returned to the client.

Return Value#

The procedure must return the claims that it wants to be returned to the client.

These are filtered by the Curity Identity Server based on the scopes of the access token before they are actually returned to the client.

Examples#

The trivial procedure#

function result(context) {
  var responseData = context.getDefaultResponseData();
  return responseData;
}

Claims filtering#

function result(context) {

  var defaultData = context.getDefaultResponseData();

  var responseData = {
    sub: defaultData.sub,
    preferred_username: context.accountAttributes.userName,
    zoneinfo: context.accountAttributes.timezone,
    email: getPrimarySignificantValue(context.accountAttributes.emails),
    phone_number: getPrimarySignificantValue(context.accountAttributes.phoneNumbers),
    extra: 'bonus'
  };
  return responseData;
}

function getPrimarySignificantValue(multivalued) {
  var primary = null;
  if (multivalued && multivalued.length > 0) {
    multivalued.forEach(function(element) {
      if (primary == null || !!element.primary) {
        primary = (typeof element === 'object' ? element.value : element);
      }
    });
  }
  return primary;
}

The claims returned by the procedure are filtered based on the scope of the access token before sent to the requesting client:

• Scope openid gives the claims: sub

• Scope openid profile gives the claims: sub, name, given_name, family_name, middle_name, nickname, preferred_username, profile, picture, website, gender, birthdate, zoneinfo, locale, updated_at.

• Scope openid email gives the claims: sub, email, email_verified.

• Scope openid phone gives the claims: sub, phone_number, phone_number_verified.

• Scope openid profile phone gives the claims: sub, name, given_name, family_name, middle_name, nickname, preferred_username, profile, picture, website, gender, birthdate, zoneinfo, locale, updated_at, phone_number, phone_number_verified.

• Other scopes are looked up for claims that are mapped to the userinfo sink in the claims mapper.