Financial-grade security refers to a cybersecurity approach that deals with high-security requirements. These requirements are often the result of compliance with data regulations. Many data protection regulations now exist around the globe, such as Europe’s General Data Protection Regulation (GDPR), Australian Privacy Principles (APPs), Brazil’s General Personal Data Protection Act (LGPD), and South Korea’s Personal Information Protection Act (PIPA). Industry-specific initiatives such as the revised Payment Services Directive (PSD2) in Europe or the Open Banking Implementation Entity (OBIE) in the UK may add further security requirements.
Financial-grade security is not limited to financial services. Instead, it can apply to any service with high-security requirements. The practice involves building an elevated security model based on international standards — preferably from the family of OAuth and OpenID Connect specifications. These standards have a wide range of use cases and can be used in any type of client application. Consequently, they ensure easy interoperability and integration. For example, The Financial-grade API (FAPI) group is actively constraining the OAuth framework into several profiles that provide guidance to meet particular sets of regulatory requirements.
In this article, I will cover three aspects that are essential for building out a financial-grade security model. It is important to note that all these vectors must be managed across all components of a system to ensure that your users, data and apps are effectively protected.
Protect Identity
The first essential aspect of financial-grade security is to protect identities from being stolen. An attacker might try to sign in using a genuine user’s credentials obtained through phishing or password leaks. The risk of identity theft can be mitigated by establishing strong customer authentication (SCA). In addition, a careful token design reduces the risk of unintended disclosure of the user’s identity.
How?
- One of the most effective methods to avoid identity theft is to provide multifactor authentication. In other words, require users to sign in with at least two factors. This makes it more difficult for an attacker to steal credentials and take over a user’s identity.
- The second method is to detect the use of stolen tokens with the help of an authentication policy based on contextual information. In addition to validating credentials, the login process should evaluate contextual details of the authentication. For example, an authentication workflow can consider the user’s current geolocation, the number of prior login attempts or the current overall threat status.
- A third step to protect the user’s identity is to use pairwise pseudonymous identifiers (PPIDs). PPIDs limit the exposure of personal user information. This way, the app (or a group of related apps) can only receive a generated identifier for the user and store any app-specific data against that ID. Consequently, the user’s identity is protected as a user cannot easily be identified over several apps.
Secure OAuth Tokens
When implementing financial-grade security, it is vital to mitigate the risk of a malicious client accessing data with stolen access tokens. Since access tokens are typically bearer tokens, a stolen token can be successfully sent to your APIs by a malicious client. To prevent this, bind the token to a specific client. This can be accomplished with sender-constrained tokens.
Sender-constrained tokens contain data that allow the API, together with a proof of possession presented by the client, to verify that the client is the party for whom the token was issued. If an access token is ever stolen, the malicious client will not be able to present the proof of possession that matches the data in the token and will receive an access denied response if they attempt to send the token to your API.
How?
- Implementing the sender-constrained tokens approach can be achieved using Mutual TLS and X509 client certificates via certificate-bound access tokens described in RFC8705. This approach relies on public key infrastructure (PKI) and is suitable for confidential client scenarios, such as API calls between companies.
Tokens are sent through a Mutual TLS tunnel, and the access token claim includes a confirmation claim containing the certificate thumbprint. The Mutual TLS tunnel serves as proof of possession. Only if the client possesses the corresponding private key for a given certificate will the Mutual TLS tunnel be established. Then the API verifies that the claim in the token corresponds to the certificate from the TLS handshake.
- In a public client setup, as for mobile apps, it is not practical to use client certificates. In this case, implementing sender-constrained tokens is done through a technique called Demonstrating of Proof-of-Possession (DPoP), as described in the DPoP draft standard. The client must prove the possession of a private key that corresponds to the public key in the token. It adds this proof in an HTTP header when sending the API request. The API verifies the proof and checks that it matches the data in the token.
- Use a reverse proxy or API gateway and implement the Phantom Token pattern. Combine the pattern with sender-constrained tokens. This minimizes data exposure through stolen access tokens and avoids them being reused.
With this approach implemented, the reverse proxy verifies proof of possession for either Mutual TLS or DPoP clients and then forwards the public key to APIs. APIs can also securely call each other inside the cluster when required, and with every API request, the access token’s scopes and claims will be verified. For financial-grade security, this includes verifying the “cnf” (confirmation) claim against the received public key.
Address Browser Vulnerabilities
The final aspect of financial-grade security involves dealing with the risks of malware exploiting potential browser weakness. Traditionally, public clients rely on the system browser to manage logins. Vulnerabilities in the browser may result in an attacker intercepting and tampering with authentication requests and response messages. Luckily, the family of OAuth and OpenID Connect specifications is rich in solutions for mitigating the risks.
How?
- One helpful solution is using JWT secured authorization request (JAR) or JWT secured authorization response (JARM). These specifications are particularly useful for mitigating the risk of a man-in-the-browser (MITB) attack when malware intercepts or tampers with OAuth request and response messages. JAR and JARM provide message-level security via additional JWTs and ensure that highly sensitive data and operations are secured.
- When dealing with mobile apps, it is important to follow OAuth best practices and use Proof Key for Code Exchange and Dynamic Client Registration. This way, you can prevent malicious apps from intercepting a login response or using the app’s client ID to impersonate the genuine app. To improve the security of public clients authentication, it is recommended to implement attestation to enable the additional check against the client application before allowing an authentication attempt.
- Finally, consider using a browser-less authentication method to make financial-grade implementations of web and mobile apps more seamlessly integrated and mitigate browser vulnerabilities risks. The Hypermedia Authentication API solution available in the Curity Identity Server offers direct HTTP calls for authentication without involving the browser.
In Summary
In summary, the good, the basic and the ultimate aspects of financial-grade security are:
- Multifactor authentication
- Pairwise pseudonymous identifiers
- Sender-constrained tokens (certificate-bound access tokens, DPop)
- Message-level security with JAR and JARM
- OAuth best practices
- The Hypermedia Authentication API
Following these recommendations will allow any organization — financial services or not — to protect user data, ensure the safety of essential transactions, and achieve a very high level of security.
