Implementing a Claims Source

Claims Sources are consulted after the Token Endpoint has verified the information in the Token Grant to be true and is proceeding with the creation of a new token. All information the Token Endpoint was given, minus passwords, will be passed to the Claims Source, which will typically be username and password, client_id and client_secret or the refresh token. They hold the username and client_id from the original password grant. The TAG will pass this information to the Claim Source:

  • grant_type: will be password if a password grant is in progress or refresh if a refresh grant is in progress

  • username: the username as presented in a password grant or taken from the refresh token if a refresh grant is in progress

  • client_id (optional): the id of the client if presented in the password grant or taken from the refresh token if a refresh grant is in progress

The Claim Source can use this information to decide what claims (key/value pairs) it would like to offer for inclusion in the final JWT. Though a Claim Source offers claims for potential inclusion in the JWT, it is the OAuth 2.0 Security Profile that makes the final decision what is actually included in the final JWT.

An exampĺe of the usage of these information within the Claim Source, is using the client_id to filter roles in a LDAP Claim Source. The client_id could represent the application id and ldap filter would only bring back the roles that are for a specific application.

Also this applies to the other properties where the Claim Source would have them to filter out what should be brought back to be added to the JWT.