July 24, 2018 | Written by: Leo Farrell
Categorized: Access and Authentication | Articles
Share this post:
OpenID Connect: Request parameters via JWT
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 188.8.131.52 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
Components and Configuration
The components involved in configuring this feature are minimal.
- An OpenID Connect Provider is necessary.
- 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
jwks_uri if either exist for the client.
Here is a video of the STS chain being configured
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