The Open Banking Security Profile defines how Third Party Provider (TPP) applications shall obtain and use OAuth and OpenID Connect tokens in a secure way, suitable for financial transactions. TPP applications will need to obtain tokens from account servicing payment service providers (ASPSPs) to initiate and complete transactions once a user has provided consent and authorized the ASPSP.
As part of the process of obtaining tokens, the security profile defines what authentication methods ASPSPs must support and make available to TPPs to authenticate. The following is required by the security profile:
ASPSPs must secure the token endpoint, used by TPPs to obtain tokens, using mutually authenticated TLS.
ASPSPs must make available one of the following methods at the token endpoint:
In order to be able to authenticate at an ASPSP and request tokens, a TPP must have completed the following steps, explained in the blog about Dynamic Client Registration:
A TPP Primary Technical Contact (PTC) must have registered a TPP and a software statement with the Open Banking directory. With this registration step, a TPP will have a signing key that can be used to sign the authentication JWT and a network certificate used to establish the MTLS channel with the ASPSP token endpoint.
A TTP Primary Technical Contact (PTC) must have registered an OAuth client at the ASPSP (either via a manual or automated process).
Once a TPP has completed the above initial registration steps, it can obtain tokens from the ASPSP with the following steps:
Establish an MTLS channel with the Token Endpoint exposed by the ASPSP, using the network certificate provided by the Open Banking Directory.
Generate a JWT, signed with the signing key bound to the software statement obtained from the Open Banking Directory. The JWT must include the following claims:
"iss”. Issuer. This must contain the client_id of the OAuth client that was issued by the ASPSP to the TPP during client registration.
“sub”. Subject. This must contain the client_id of the OAuth client.
“aud”. Audience. This identifies the ASPSP and it must be set by the client to the URL of the ASPSP Token Endpoint.
“jti”. JWT ID. A unique identifier for the token defined by the TPP client application, that can be used to prevent reuse of the token.
“exp”. Expiration time of the token, defined by the TPP client.
Send the authentication JWT to the token endpoint exposed by the ASPSP.
The following example shows a private key JWT authentication request for an OAuth client credentials grant type (non URL encoded and abbreviated for clarity):
The decoded JWT is displayed below:
To demonstrate how private key JWT client authentication works, I will use a Ping Identity test environment connected to the Open Banking Multi-Party Industry Testing (MIT) Directory, where I have previously registered an ASPSP and an Account Information Service Provider (AISP) and where I have an account as a PTC.
PingFederate works as the OAuth authorization server and publishes the token endpoint. PingFederate will connect to the Open Banking directory to download the keys used to validate the authentication JWT sent by the client.
PingAccess exposes the PingFederate token endpoint enforcing MTLS.
PingDirectory stores the OAuth client data.
PingFederate OAuth configurations
To test client authentication, I start from an environment where PingFederate has already been deployed, enabled for OAuth and where an OAuth client has been created using the registration tool described in the previous blog. PingAccess has also been deployed and configured to protect the PingFederate token endpoint via Mutual TLS (MTLS).
The screenshot below displays the relevant part of the OAuth client configuration that enables private key JWT authentication. This is accessible from the PingFederate administrative UI via the “OAuth Server” menu, selecting the client created with the client registration tool.
The CLIENT AUTHENTICATION field is set to PRIVATE KEY JWT (optionally, replay prevention can be enabled to avoid that a client can reuse the same token to authenticate twice) and the JWKS URL is set to the address of the JWKS associated to the TPP client in the Open Banking directory. This value is derived from the software statement that was submitted as part of the registration request.
When PingFederate receives a private key JWT for client authentication, it validates the token according to the specification; as part of the validation it checks that the “aud” claim of the JWT matches the PingFederate token endpoint, using the PingFederate base URL. In this case, the token endpoint is published via PingAccess using a URL that differs from the PingFederate base URL (because the token endpoint must be protected via MTLS). I need therefore to modify the default configuration to set the correct token endpoint URL in PingFederate to make the “aud” check pass. The configuration is available in the PingFederate management UI in the “OAuth Server” - “Authorization Server Settings” - “TOKEN ENDPOINT BASE URL” field. This field must be set with the base URL used in PingAccess to expose the token endpoint.
Client authentication tool
To send the authentication requests, I will use a Java tool that generates an authentication JWT and submits a token request to the token endpoint of the ASPSP, using the OAuth client credential grant.
The tool uses the Jose4j library to generate the JWT with the code below:
Once the private key JWT is available, the tool sends the token request to the ASPSP token endpoint. I implemented the actual call with Unirest for convenience.