Open Banking Brazil DCR Request Validation

Open Banking Brazil DCR Request Validation

architect

Financial-grade and Open Banking systems have high security requirements. The technical requirements commonly rely on a Public Key Infrastructure implemented by an authority that ensures and monitors the compliance of all actors. Therefore, mutual TLS and asymmetric JWTs are widely adapted user and client authentication methods within Open Banking or Financial-grade systems. It is of great importance to only allow trusted and verified clients to integrate with the system and finally access sensitive data. For the latter the user normally needs to consent to. However, before any client can integrate and benefit from Open Banking it needs to get approved by the authority and become certified. Only then it can also register at the Account Servicing Payment Service Provider (ASPS), e.g. the bank. This is commonly implemented via the Dynamic Client Registration protocol, DCR.

Dynamic Client Registration in Open Banking

As mentioned above the client commonly authenticates using a mechanism based on public key cryptography such as mutual TLS or asymmetric JWTs. Client authentication alone does not guarantee that the data presented by the client is the same that it provided during its certification through the common authority. The Open Banking Brazil Dynamic Client Registration Profile addresses this issue.

The OAuth 2.0 Dynamic Client Registration specification defines the software statement as follows:

A software statement is a JSON Web Token (JWT) [RFC7519] that asserts metadata values about the client software as a bundle. [] When presented to the authorization server as part of a client registration request, the software statement MUST be digitally signed or MACed using JSON Web Signature (JWS) [RFC7515] and MUST contain an “iss” (issuer) claim denoting the party attesting to the claims in the software statement.

The software_statement is used within the Open Banking Brazil Dynamic Client Registration to provide the Authorization Server of the ASPS the data that the client is certified for. As a result, the Authorization Server can verify that the data included in the DCR request matches the data included in the software statement that is signed by the authority. In particular the specification states that:

  • shall validate that the request contains software_statement JWT signed using the PS256 algorithm issued by the Open Banking Brazil directory of participants
  • shall validate that the software_statement was issued (iat) not more than 5 minutes prior to the request being received;
  • shall require and validate that the jwks_uri matches the software_jwks_uri provided in the software statement;
  • shall require and validate that redirect_uris match or contain a sub set of software_redirect_uris provided in the software statement;
  • shall validate that requested scopes are appropriate for the software’s authorized regulatory roles;
  • should where possible validate client asserted metadata against metadata provided in the software_statement;

Advanced Request Validation in an API Gateway

The Curity Identity Server supports the Dynamic Client Registration and even the Dynamic Client Registration Management protocol. It does not, however, support software statements as part of the DCR request and will ignore any as specified by the DCR standard. Read the blogpost on the Open Banking Brazil Status Update for more insight. As for now, an API gateway or reverse proxy needs to intercept the DCR request to comply with the Open Banking Brazil Dynamic Client Registration Profile. In that way the gateway can verify the software statement, validate the data and populate defaults from values within the software statement. In other words, it is within the gateway’s responsibility to implement the requirements listed above.

Signature validation operations are resource-intensive and limitations in the cryptographic capabilities of the gateway will eventually lead to an external validation service. This service checks the signing algorithm, lifetime, expected issuer and signature of the software statement and returns the validation result to the gateway.

The approach presented in this article contains the following roles:

  • An authority that governs a directory of trusted clients and manages the Public Key Infrastructure that is the foundation of the trust in technical terms. Among others, it publishes the key for verifying any software statement. This key is required by the software-statement-validation service to verify the signature of the software statement.
  • A software-statement-validation service that takes the software statement, checks the lifetime of the JWT, validates the expected issuer and verifies the signature with the key of the authority.
  • A client that gets certified by the authority for one or several roles within the ecosystem. The client retrieves a certificate for client authentication as well as a software statement from the authority.
  • A gateway that validates the DCR request from the client, extracts the software statement that it forwards to the validation service. If the statement is valid, the gateway then performs further validation checks, populates any default values from the software statement and forwards the request together with the client certificate to the Curity Identity Server.
  • The Curity Identity Server that processes the DCR request and responses accordingly to the client.

Open Banking Brazil DCR Request Validation Approach

The client starts with requesting a software statement from the authority. The software statement is a simple JWT that is signed by the authority and included in the DCR request to the bank’s Authorization Server. Then the client needs to authenticate via mutual TLS to the DCR endpoint. The DCR endpoint in turn is protected by an API gateway or reverse proxy. Thus, the TLS session is terminated at the gateway. Only client certificates issued by the authority are accepted.

The gateway will parse the data in the DCR request, retrieve the software statement and forward it to an external service to validate the signature. If the statement is valid and verified, the gateway will decode it.

The gateway will also verify claims presented in the DCR request against the claims in the software statement and perform other simple validation checks. It will if necessary populate default values based on the software statement.

At the end the gateway forwards the request to the Curity Identity Server that processes it further and returns the DCR response. The Curity Identity Server is configured to support mutuals TLS client authentication with proxy termination (mutual-tls-by-proxy).

This approach requires configuration and customization of the API gateway or reverse proxy using technologies such as a LUA script. Also, the software-statement-validation service will most likely be a custom implementation. Checkout the example implementation for Open Banking Brazil compliant DCR request validation for technical insight.

Let’s Stay in Touch!

Get the latest on identity management, API Security and authentication straight to your inbox.

Keep up with our latest articles and how-tos using RSS feeds