Client authentication with a JWT is a requirement of the UK OpenBanking standard, as per Section 5.2.2 of the Open Banking Security Profile V1.1.2 It is considered a stonger and safer method of authentication than client_id and client_secret. This method does not require the client_secret to be sent in the request at all.

When accessing /token, /introspect, /revoke, or any other OAuth API endpoint the client may be required to authenticate. This authentication is usually achieved in one of three ways:

• client_id and client_secret in an Authorization: Basic header
• client_id and client_secret being provided as POST parameters.
• Client access token in a Authorization: Bearer header

This article shows an alternative to these methods by using a  JWT as a mechanism of authentication. Security Access Manager, in 9.0.4.0 supports client authentication via JWT.

Below is an example token request using a JWT as authentication:

POST_DATA='grant_type=password&
username=testuser&
password=*******&
client_assertion=eyJhbGciOiJIUzI1NiJ9.
eyJzdWIiOiJ0ZXN0X2NsaWVudCIsImlzcyI6Imh0dHBzOi8vd3d3Lm15c3AuaWJtLmNvbSIsImV4cCI6MTU1NzQ3NDE0OCwiYXVkIjoiaHR0cHM6Ly93d3cubXlpZHAuaWJtLmNvbSJ9.
wQjZqJgx4Qd-X8eStoSe307OthxLCPUUCqnMr0D7RvU&
client_assertion_type=urn:ietf:params:oauth:client-assertion-type:jwt-bearer'

curl https://www.myidp.ibm.com/mga/sps/oauth/oauth20/token -d "$POST_DATA"

The two parameters to take note of are the client_assertion, and the client_assertion_type these replace the client_id and client_secret which is usually presented.

Unpacking the JWT shows:

{
  "alg": "HS256"
}
{
  "sub": "test_client",
  "iss": "https://www.mysp.ibm.com",
  "exp": 1557474148,
  "aud": "https://www.myidp.ibm.com"
}

These checks are made during JWT validation:

• The sub claim must be present and be the client_id of the client.
• The iss claim must be present and needs to appropriately identify the creator of the JWT.
• The aud claim must be present and should be a value which appropriately identifies the authorization server. This is commonly the issuer identifier of the authorization server.
• The exp claim must be present and in the future.

Client Authentication Using JWT on Security Access Manager

Security Access Manager doesn’t need any direct configuration or modification of an API protection definition in order validate client assertions. Instead support is achieved via an invocation of Security Token Service(STS). When an assertion is presented in a request to /token the client_assertion value will be sent to the STS for validation. To route the request to the correct chain well-known and predicable AppliesTo and Issuer addresses are used. After the JWT has been validated the claims which were included in the JWT will be added to the STSUniversalUser attribute list.

The AppliesTo used will always be https://localhost/sps/oauth/oauth20.

The sub claim in the JWT and a well known prefix are used to makeup the the Issuer address. The prefix is urn:ietf:params:oauth:client-assertion-type:jwt-bearer:. Using the sub of test_client would produce the issuer value of urn:ietf:params:oauth:client-assertion-type:jwt-bearer:test_client.  STS Chain addresses may make use of regexes to match many sub values t one chain the most noteworthy of these is REGEXP:(urn:ietf:params:oauth:client-assertion-type:jwt-bearer:.*) which matches all sub values to the one chain.

This video shows a chain configured for such a verification:

JWT Verification

The chain configuration does not need any properties configured for the JWT validate phase as usually the properties are sourced from the client instance configuration. The client secret will be used to populate the signing symmetric key for for validating HMAC signed JWTs(Eg HS256) and the client JWKS URI will be used as the signing JWKS URI for verifying asymmetrically signed JWTs(Eg RS256) presented. The chain may have module properties set but the client instance values will override them.

Debugging

For debugging any issues encoutered there are two pieces of trace to enable:

• com.tivoli.am.fim.trustserver.sts.modules.*=ALL – Using this trace will show information on JWT validation.
• com.tivoli.am.fim.oauth20.*=ALL – Using this trace will help to identify any claim validation issues.

When developing if encountering issues looking up claims from the JWT check that the attribute list is being used and not the context attributes. The attribute list contains the details of the identity used in the request. This is true in other cases  like if the POC performed the authentication, then iv-creds will be present in this attribute list. Where as the context attributes contain the overall oauth request like the grant_type or response_type values

Documentation for this feature is available here.

#ISAM