How to Implement Financial-Grade Security
On this page
Regulations such as PSD2 in Europe aim to improve electronic payment services. The goal is to create an innovative and secure market. PSD2 changed a whole branch. Banks and payment institutions now are forced to open up for third parties resulting in an Open Banking landscape. Open Banking may also be driven by branch organisations to modernize services and create competitive advantage. Whatever the reason, security is central for Open Banking. Financial-grade Security means meeting high security standards.
There are three roles defined by PSD2:
- Payment Service User (PSU)
- Account Servicing Payment Service Provider (ASPSP)
- Trusted Third Party (TTP) that acts as ** Account Information Service Provider (AISP) ** Payment Initiation Service Provider (PISP)
An Account Servicing Payment Service Provider (ASPSP) is the payment institution or bank holding the account whereas the Trusted Third Party (TTP) is a certified thus trusted party that accesses the payment services on behalf of the user. The payment service user (PSU) is the customer at the bank. There are different requirements depending on the role and context, i.e. retrieving the balance of an account as part of the role as an Account Information Service Provider (AISP) and initiating a payment of a certain amount as part of the role as a Payment Initiation Service Provider (PISP) require different security controls such as additional consent that dynamically links the transaction to an amount and payee.
Even though this article focuses on financial services, the techniques and best practices listed here are applicable for any system with high security demands like it can be found within the healthcare sector. Translate the roles defined above to your business and adapt the requirements accordingly.
Strong Customer Authentication
In a financial-grade system it is important to have strong confidence in the customer's or user's identity. Therefore, implement a "Strong Customer Authentication" method. This normally translates to Level Of Assurance 3 or higher and multi-factor authentication. There is no general answer as the method depends on the local and legal requirements. The Curity Identity Server supports many authentication methods out of the box, among others BankID for strong authentication of private citizens, and FrejaID, a mobile-based authentication of both private individuals and employees.
The following list provides resources for techniques that enable the implementation of strong authentication beyond the methods mentioned above:
Customer Consent
Sometimes it is not enough to only authenticate the user, but the user must also confirm the action triggered by the application. In other words, the user must consent to the client accessing certain data or performing an action such as creating a transaction. In the Curity Identity Server this concept is called Consentor. There are generic consentors and signing consentors. Generic consentors are the basis for collecting user consent. They tie together the client identifier, authentication attributes, consented scopes and claims. Signing consentors are used when the goal is just to sign the consented information such as an initiated transaction. They receive a text-to-display and an object-to-sign and use this information to produce a signature. The Curity Identity Server already includes a built-in signing consentor, namely BankID. New consentors can be added as plugins.
Study the following list to read up on how to request consent from a user via the Curity Identity Server in different scenarios.
Allow users to manage and eventually revoke a consent for a certain client by enabling the User Management Service in the Curity Identity Server.
Protecting Data
Protecting customer and user data is a cumbersome task. There is not one solution that solves it all but rather a combination of different techniques, frameworks and processes to mitigate the risk of fraud, leaking or manipulating data and violating privacy. For example, the implementation of the Phantom Token Approach ensures that data cannot leak through tokens on client side by using reference tokens over by-value tokens. By carefully designing the claims that are put into tokens the risk for leaking data is mitigated even further. Using Pairwise Pseudonymous Identifiers (PPID) increases user privacy by providing a unique user identifier per client. Prefix Scopes enable context specific scopes that can be used when requesting the user's consent. The following list contains resources regarding the content of tokens:
Request parameters are traditionally added as URI parameters and may leak to logs. To avoid this, use HTTP POST and send the data in the body. There are different specifications that aim to protect request and response parameters:
- Signed Request Objects: Request parameters in JWTs as defined by Core OpenID Connect
- JWT Secured Authorization Request (JAR): All request parameters in secure JWTs
- Pushed Authorization Requests (PAR): Request parameters in HTTP body
- JWT Secured Authorization Response Mode (JARM): Secure response from authorization server
Issuing tokens and collecting consent is just the beginning. Keep the whole life cycle in mind and have processes in place for customers and users to revoke tokens, update delegations and consents. A policy engine like the Open Policy Agent (OPA) allows the implementation of fine-grained and dynamic access controls.
Use encryption during transport, i.e. TLS, to avoid eavesdropping. Consider strong signing and encryption algorithms for tokens and messages. A Hardware Security Module (HSM) may be used for storing keys and related cryptographic operations.
Stay compliant with local regulations, and make sure data and users stay within regional boundaries. The following features help in adapting flows to the user's location as well as in implementing a secure multi-regional deployment.
- Geolocation: Adaptive authentication using geographical data
- Wrapped Opaque Tokens: Opaque Tokens in JWTs
Client Authentication and Authorization
Authentication is not limited to customers and users. A client also needs to prove its identity to the service provider as part of the registration process and token request. Commonly in OAuth 2.0 and OpenID Connect integrations a client secret is used to authenticate the client. However, this authentication method does not meet the requirements for a financial-grade API. There are more secure methods based on public cryptography. Check out the following resources:
- JWT Assertion: Client authentication using JWTs
- Mutual TLS (MTLS): Client authentication with certificates
Further, to prevent fraud, a rogue party must not be able to obtain or replay tokens issued to a certain client. Using any of the token binding techniques listed below, the API will be able to verify that the token it received was sent by the client that requested it at the first place. In this way token binding and sender constrained tokens prevent replay attacks.
- Demonstrating Proof-of-Possession (DPoP): Sender constrained tokens with JWTs
- Mutual TLS Sender Constrained Access Tokens: Sender constrained tokens with certificates
Note, that PSD2 and related regulatory technical standards require the use of qualified certificates for identification of servers between payment service providers. Technical standardization bodies such as the Berlin Group and FAPI emphasis or require the use of mutual TLS for client authentication and Certificate Bound Access Tokens in Open Banking.
To quickly onboard new clients use the Dynamic Client Registration protocol that provides automatic processes for registering new clients in secure manner.
System and Software Architecture
In the Open Banking the Account Servicing Payment Service Provider (ASPS) is ultimately responsible for authenticating the user when a service is requested. The Trusted Third Party (TTP) will eventually integrate with various providers. Even more, the TTP may have its own APIs to process the data retrieved from an ASPSP and thus will eventually have its own customer identity management system and create a federated system with the Account Servicing Payment Service Providers. Read more on how to share tokens and how to implement a federated App2App flow.
The payment service user may be authenticated through a redirect approach, a decoupled approach, or an embedded approach. Traditionally, the OAuth 2.0 and OpenID Connect specifications take a redirect approach and rely heavily on browser redirects. That applies even for logins via a dedicated, high-security authentication app using the App2App flow. A decoupled flow as defined by the Client Initiated Backchannel Authentication enables user authentication as part of the OpenID Connect protocol without redirects. That not only removes an attack factor but also allows strong customer authentication through a decoupled authentication device.
To address the attack factor of redirects and enable secure authentication from clients that have problems opening a browser or capture the response, Curity designed the Hypermedia Authentication API called HAAPI. Using this API, clients get control over the user experience by running flows adherent to the flows standardized by OAuth and OpenID Connect frameworks within the same application. However, the authentication flow and all related complexity is still controlled and enforced by the authorization server. HAAPI supports all kind of flows, including a decoupled approach for strong customer authentication.
References
- Payment Service Directive 2 (Directive (EU) 2015/2366, PSD2)
- Regulatory Technical Standard on Strong Customer Authentication (Commission Delegated Regulation (EU) 2018/389)
- NextGenPSD2 by The Berlin Group
- Financial-grade API
Further Reading
Judith Kahrer
Product Marketing Engineer at Curity
Join our Newsletter
Get the latest on identity management, API Security and authentication straight to your inbox.
Start Free Trial
Try the Curity Identity Server for Free. Get up and running in 10 minutes.
Start Free Trial
