The OpenID Connect specification has an optional section which goes into details of how a client can provide (via the browser) a claims and OAuth parameters to /authorize in an alternative manner to query string or post parameter. This is of note as it allows the client to provide a trusted set of claims to the OpenID Connect provider.  This parameter can be provided in one of two ways, pass by value where the object is a set of claims encapsulated in a actual JWT, or pass by reference, where the parameter value is a URL which the claims are served from. These request parameters can be one or many of the traditional OAuth / OIDC request parameters (in some instances you duplicate the values in the query string or post body so that the request is still well formed) or an extension parameter

The OpenBanking security profile makes heavy use of a request object in a pass-by-value  manner for the relying party (or in open banking case, the Third Party provider) to provide additional claims via this JWT.

IBM Security Access Manager version 9.0.4.0 added support for request parameters to be provided by JWT. This article is going to go over how this can be configured.

Note: In an earlier article I spoke about clients being able to authenticate using a JWT which is also needed for OpenBanking, this is different than what is being done in this article. In this article the request is being performed by a browser to /authorize, but in the earlier article the request was being made by an OAuth Client to /token


Components and Configuration

The components involved in configuring this feature are minimal.

1. An OpenID Connect Provider is necessary.
2. A STSUU -> JWT chain is needed.

The OpenID Connect Provider(OP) implementation ships with logic to call out to the security token serivce(STS) and verify the JWT, then the claims are passed back and the processing of the OpenID Connect request continues.

In order to know which STS chain to call the OP follows some simple rules for the Issuer and appliesTo addresses. The applies to which will be used will always be: https://localhost/sps/oauth/oauth20. The issuer uses a well known prefix of urn:ibm:ITFIM:oauth20:client_request:and then the client_id in the incoming request. Because the STS supports regex matching of the issuer and applies to, a chain which matches all clients can also be configured. To make a chain to catch ever client use the issuer value of REGEXP:(urn:ibm:ITFIM:oauth20:client_request:.*).  The request mode validate is always used. When the STS chain is invoked. Some WS-Trust claims will be provided by the  OP to validate the JWT, these will be the clients client_secret and  jwks_uri if either exist for the client.

Watch a video of the STS chain being configured:

At Runtime

During runtime the parameters in the JWT will be added to the request as if they’d been provided via query string or POST, only they’ll have the type urn:ibm:names:ITFIM:oauth:jwt:param in the STSUniversalUser. These claims will also be available in Access Policy.

This video shows how the JWT is consumed by the OpenID Connect provider and included in the request parameters: