Claims

Identity tokens are encoded in JSON Web Token format.

They contain specific claims to provide authenticated information about the user. Claims are also returned from the User Info endpoint.

In other words, an app can request one or more claims to get information about the user.

The following standard JWT claims are returned in the Identity Token when openid is included as a scope in the authorization request. See the scopes topic for more details on scopes.

• sub (required)
  • The unique subject identifier for the user. This value can be used where API calls use the placeholder {userId} in API path definitions.
• aud (required)
  • The audience for this Identity Token
• iat (required)
  • The time at which this Identity Token was issued
• exp (required)
  • The time at which this Identity Token expires
• iss (required)
  • The identifier for the issuer of the Identity Token claims

Additional Standard claims

OpenID Connect defines a set of Standard claims. See the RFC for more information.

These claims are generally supported and are publicly available, but some are not supported for all types of users.

The additional claims must be specifically requested utilizing the claims parameter. (See the RFC for details on the claims parameter.) The claims parameter is constructed as a JSON object which then must be encoded. Claims can be returned in these ways:

1. In the Identity Token
2. From the UserInfo Endpoint
3. In both the Identity Token and from the UserInfo Endpoint

This provides options for handling personally identifiable information (PII).

Imagine a situation where it is undesirable for Identity Tokens to contain PII data since those tokens are being stored by your service, yet it is still desirable to retrieve PII data on-demand via the User Info Endpoint.

Enterprise Users (Employees of a financial institution)

In addition to the standard JWT claims listed above, the following claims are available when requested for an enterprise user:

• department - Only for users whose domain is configured for Active Directory. profile scope required.
• email - User’s email address. email scope required.
• family_name - User’s last name. profile scope required.
• given_name - User’s first name. profile scope required.
• middle_name - User’s middle name. profile scope required.
• name - User’s full name. profile scope required.
• phone_number - User’s primary phone number. phone scope required.
• picture - User’s profile picture URL. profile scope required.
• preferred_username - User’s username. profile scope required.
• title - Only for users whose domain is configured for Active Directory. profile scope required.
• institution_id - Institution Universal ID, a Jack Henry identifer that is not from the OIDC standard list. profile scope required.

Products defining additional or custom claims is not supported.

Consumer Users (Customers or members of a financial institution)

In addition to the standard JWT claims listed above, the following claims are available when requested for a consumer user.

• https://api.banno.com/consumer/claim/address - User’s mailing address. address scope required.
• https://api.banno.com/consumer/claim/birthdate - User’s birthdate.
• https://api.banno.com/consumer/claim/email - User’s email address. email scope required.
• https://api.banno.com/consumer/claim/family_name - User’s last name. profile scope required.
• https://api.banno.com/consumer/claim/given_name - User’s first name. profile scope required.
• https://api.banno.com/consumer/claim/middle_name - User’s middle name. profile scope required.
• https://api.banno.com/consumer/claim/name - User’s full name. profile scope required.
• https://api.banno.com/consumer/claim/phone_number - User’s primary phone number. phone scope required.
• https://api.banno.com/consumer/claim/picture - User’s profile picture URL. profile scope required.
• https://api.banno.com/consumer/claim/preferred_username - User’s username. profile scope required.

Additional claims for Consumer Users

There are additional claims supported for consumer users. Some are publicly available for any client to request, and others require specific configuration due to potentially sensitive data. More information can be found here.