Articles

OpenID Connect: Request parameters via JWT

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 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.

requestjwt

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.

Here is 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

 

Click here to rate this article

Rate this article :

Software Engineer - IBM Security Access Manager

More Articles stories
By Carsten Hagemann on June 20, 2022

Getting started with the IBM Verify SDK

The IBM Verify SDK is a library available for Android and iOS and provide classes to create rich native client mobile applications that interact with IBM Security Verify and IBM Security Verify Access, so that enterprises can easily integrate flexible and intelligent multi-factor authentication into their applications. Multi-factor authentiation (MFA) verifies an indiviual’s identity by […]

Continue reading

By Martin Schmidt on July 11, 2019

Modernizing your B2C Portal Security – LDAP Proxy Deep Dive

In this part of our series we are taking a deeper look on how the LDAP reverse proxy works and what is needed to be done to make it work. Enable CI In this part we look at what needs to be done on the CI side and what information needs to be collected. We […]

Continue reading

By Martin Schmidt on May 4, 2019

Modernizing your B2C Portal Security – Desired End State

Proposition: As we have seen in part one of this series, managing customer identities for a portal can be a challenge and distraction for the business.  In this part of the series we will outline how a modernized solution for a portal security can simplify operations and free your team up to focus on the […]

Continue reading