Using Curity Identity Server to handle PSD2

Using the Curity Identity Server to handle PSD2

PSD2 overview

The revised Payment Services Directive (PSD2) poses challenges for organizations seeking the most efficient and secure means of complying with the directive's requirements. As a specialist in the application of OAuth and OpenID Connect, international standards that define methods for securing APIs, Curity is perfectly positioned to help these organizations in their compliance efforts.

PSD2 is an EU directive that regulates payment services and payment service providers within the EU and European Economic Area. The purpose of the directive is to open up competition in the payments industry, allowing, for example, the participation of non-banks, while at the same time protecting consumers by making online payments safer and more secure.

This opening up of the payments industry naturally risks exposing high-value data, so the consumer protection aspects of PSD2 are essential for full compliance with the directive. Under PSD2, banks are required to share consumer information with third party providers (TPPs) but they must also ensure that a TPP has been duly authorized to access that information.

Leveraging Mutual TLS

The authentication process starts with eIDAS (Electronic Identification, Authentication and Trust Services). eIDAS oversees electronic identification and trust services for electronic transactions in the EU. As such, it is an integral part of PSD2 compliance. In order to be approved as a TPP, an organization must first register with eIDAS. When approval is granted, eIDAS issues an electronic certificate to the new TPP.

The TPP can then use the certificate with Mutual TLS (MTLS) to request that a bank register the TPP as a new client. Once the bank has verified that eIDAS is the issuer of the certificate, the OAuth and OpenID Connect protocols can be used through the Curity Identity Server to provide the TPP with a new client ID bound to a MTLS certificate.

The TPP is now in a position to access payment and account information through the banks APIs. This is the point at which the PSD2 requirement that TPPs be granted access to consumer data risks exposing that data to unauthorized entities.

Authenticating the client

To ensure that the security requirements of PSD2 are also met, the client must be authenticated before the data request can be authorized. This authentication takes the form of an access token, which the TPP can obtain using OAuth or OpenID Connect.

In this kind of high-security scenario, it is essential to ensure that the entity making the data request of the API is the same entity to which the token was issued. Otherwise, an unauthorized entity, using a stolen access token, could call the API masquerading as the authenticated client and thereby gain access to highly sensitive data.

For this reason, the access token must be tied to the client in such a way that there can be no doubt the entity that obtained the token is the same entity making the data request of the API. The key to binding a token to a particular entity involves the client proving its possession of a secret that only it has. Mutual TLS can be leveraged and a certificate is used by the client when authenticating to an OAuth server such as the Curity Identity Server in order to obtain an access token, and again when using that token to call the API.

A fingerprint (hash) of the certificate is used as a secret and is placed in the token. The API can then check for that secret in the presented token to see whether the same value was used at the time of the initial request for the token. If so, the API grants access to the requested data.

Conclusion

PSD2 calls for both greater access to sensitive data and greater protection for that data. The Curity Identity Server can meet this challenge by using the OAuth and OpenID Connect protocols to ensure the highest levels of security for data exposed through an organization's APIs.