OpenID Connect has been the cool cat on the JSON authorization cat walk for some time. A powerful extension to the basic authorization flows in OAuth2, by adding in an id_token. The id_token is a JWT (JSON Web Token, pronounced ‘jot’ but you knew that) that is cryptographically signed and sometimes encrypted – depending on the contents.
The id_token is basically separate to the traditional access_token, containing details such as which authorization issued the token, when the user or entity authenticated and when the token will expire.
The script is basically allowing us to creatively map scopes into attribute data, either held on the user’s identity profile, or perhaps dynamically created at run time via call outs or via applied logic.
A quick edit of the of the out of the box OIDC claims script, allows me to add a users status from their profile held in OpenDJ, into the data available to presented scopes. I’ve used the inetuserstatus attribute simply as it’s populated by design. By adding “status” to the scopes list on my OIDC client profile, allows it to be called and then mapped via the script.
So pretty simply I can add in what is made available from the user’s identity profile, which could include permissions attributes or group data for example.
Another neat feature (which isn’t necessarily part of the OIDC spec), is the ability to add claims data directly into the id_token – instead of making the extra hop to the user_info endpoint with the returned access_token. This is useful for scenarios where “offline” token introspection is needed, where an application, API, device or service, wants to perform local authorization decision making, by simply using the information provided in the id_token. This could be quite common in the IoT world.
To add the claims data into the signed JWT id_token, you need to edit the global OIDC provider settings (Configuration | Global | OAuth2 Provider). Under this tab, use the check box “Always return claims in ID Tokens”