Open API Security Maturity Model With an Emphasis on OPEN BANKING and Digital Payments

In the past few years, API security becomes a major concern to - pretty much - every industry using public internet to access application resources, however, i am focusing in today's article on the banking sector and digital payments, let alone, the relatively new concept of OPEN BANKING, which made APIs - specifically REST APIs- are exposed to the public internet. thus, the security architecture becomes extremely important

As a security Architect, i need to keep up with business demand for OPEN BANKING which in summary and for agreement's sake only, allowing API to be called over web developed links via public internet. when it comes to API security implementations, applying HTTPs Basic Authentication, API keys and secrets, or token-based authentication, are the easiest security controls that comes into mind. Neglecting some major concerns as identity theft, claim exposure, confidential data leakage, PII exposure. and off course OWASP top 10 API Security risks and its vulnerabilities.

Jacob Ideskog, VP at Curity invented the API Security Maturity Model, inspired by the Richardson Maturity Model, which outlines the levels of securing APIs and identifying who is calling those APIs, better yet, secure who doing what? (Authorization) and finally Applying API Zero Trust Architecture (ZTA) as stated in NIST SP 800-207. I know, I am going to explain this the APIs security model in the next few lines, this API security maturity model is presented in the following illustration.

• Level 0: API Key & Secret Basic Authentication

At Level 0, we - or developers - use Basic Authentication or API keys and secrets to identify - an only identify - who is calling our APIs. So, we basically provided information about the user and give him pre-configured static API key and secret to apply whether in the header or the body of the URI of those API requests (calls).

Security shortfalls:

1. Only provided service verification: because eventually anyone who has the API key & secret can access the service, so we actually identified the service, not the end user or the client " Yep. WOW!!"
2. if you rely only on TLS (https): session encryption then anyone who has access to your shared session key and use that to decrypt TLS communications between the server and client, then, can see the API key and secret, which grant him unauthorized access to the service your endpoints or protected resources are offering.
3. Service Authentication only - No authorization: we only asked the question " who" and trusted that the other entity didn't leak our API key and secret, but we didn't ask the " what" what can this service we provided do? is it money transfer, to which beneficiary, the maximum amount of transfer, and the allowed currencies " sound threatening?! OH YEAH!!!"
4. Back to the open banking services: Having a static pre-set API Keys and secret is a major threat to identity theft, giving such valued credentials to clients with no control over the security of how this information (API Credentials) kept. this is pretty much a concern and may result in many cases of fraudulent activities or excess data exposure.

• Level 1: Token-Based Authentication

At Level 1 we just added a layer of security - just a thin layer - which - in short - whomever have access to the token can use the service by utilize Access Tokens for authentication within a token-based architecture.

these authentication Tokens delineate the type of user (machine, app, user, etc.). As this enables privileged access but again does not control what scope of privileged access is the person or the machine is allowed to execute.

Security shortfalls:

1. Again, Only Authenticates: over one privileged gate anyone who has the token - legitimately or illegitimately - can have access never mind the sound threatening " what?" question we described earlier.
2. Token is just like a train ticket: anyone who has the token can ride your train, another words, whomever stole the token, can ride your services, or APIs.
3. Excessive Data exposure: since this level is about authentication, and not authorization, any authenticated client will have full access to protected resources and its data, therefore, excessive data exposure is a risk, Authorization - in the next level- is defining grant SCOPES for Varity of access level.

Level 2: Token-Based Authorization

Here we finally introduced the concept of SCOPES which is defined thoroughly in OAuth 2.0 framework (Please see RFC 6749)

Again, saving you form reading, in summary, SCOPES has the following specifications

• Named " permission" in a token
• Requested by the client and sometimes validated by the client
• Authorized by the OAuth Server or delegated Authorization entity

This Level 2 Requires the introduction of IdP (Identity Provider Server or IAM) which will help in creating and validating scopes. it is also called OAuth 2.0 server RFC 8414. The permission can be anything really, when it comes to scope, i - personally- would like to classify permission into 4 main categories

1. Token behavioral permission: which is more into clients NOT being abusive to our system something like rate limiting number of failed attempts of API calls by the client to five for example, and then the specific API will be suspended.
2. Business driven permission: which is more into the core of the business, in our case of OPEN BANKING, we can say transfer_ limit, allowed_ currency, maximum_ amount
3. PII permission: which identify this specific customer by his PII information, like email ID, IQAMA (social_ security) etc.
4. Card parameter permission: token that identify certain credit / debit card Parameters such as, card number, expiry date, or CVV.

Security shortfalls:

1. Information leakage: All the four token classes - described above - is a threat because these token in traversing public internet in BASE64 Encoded format, which can be decoded simply by any internet tools and revealed as clear text.
2. Who trust who? sometimes there will be more than one IdP in the picture - i mean the architecture - one at your side (the bank for example) and one at the client side. where the issue of trust comes into place, who trust who? if the client modified the token, and digitally signed it by the IdP, should i trust that token as a bank? what if their Signing keys were compromised " stolen" at any point of time. Imagine that you have 300 customer who want to introduce there IdP in your bank's architecture, you will end up of what Jacob calls Spaghetti of trust.

Back to OPEN BANKING domain, off course to secure the above types of tokens, information within the token should be encrypted and then signed- it is called payload encryption and digital signage - to prevent data leakage, insure information integrity, and to comply with the banking regulators and financial services such as PCI Security Standards Council (PCI-DSS v4.0), and GDBR, The federal regulators in USA like OCC and FDIC, and locally in KSA The Saudi Arabian Monetary Authority Cybersecurity Framework (SAMA CSF).

I will address token encryption and digital signature further on this article, keep reading!

Level 3: Centralized Trust Using Claims

in that level Jacob Ideskog has elevated the security of API calls to another level, architecturally, is this level we has the concept of Spaghetti of trust removed, as he is not going to trust any of the introduced IdP, rather than trust his own identity server, so the flow, will be as follows

• Local IdP will issue token with the specific claim (scope).
• the client should not alter the token while traversing his infrastructure
• Local IdP will be responsible for validating the token and it content (climes, scopes whatever you want to name it).

Security shortfalls:

1. Absence of Maker/Checker control: Although Level 2: Token- based Authorization will introduce a security control platform called IdP, it is still the production of Token scope relies on the IdP and validating the token scope relies on the SAME IdP, while, architecturally, making the scope should be made by a platform and validating the scope should be by another. to value the overall token security policy.
2. Forcing NOT TO INTERCEPT: there is no way to force client not to intercept the token that is passing within their infrastructure, there will introduce the next level of API security and the concept of Opaque Tokens

I would like to pause a little before explaining level 4 and take that chance to talk about token encryption and digital signing as i stated before in this article.

JWT, JWE, JWS and the difference between them.

in short, JOSN Web Tokens (JWTs) are compact, URL-safe means of representing claims or scopes to be transferred between API caller and API point of authority (IdP or IAM). The claims in a JWT are encoded as a JSON object in BASE64 format. which can be easily decoded by and BASE64 decoding tools can be found freely on the internet. decoding JWT will reveal a lot of information that could be sensitve or highly confidential specially in the OPEN BANKING domain. which reveling this information may result on lawsuits, penalties by the regulator, or even license temporarily or permanently being suspended. plus, JWT is subject to alteration, if i know JSON, i can intercept any JWT and modify it, for example as a client for Bank (A) my maximum credit limit in $5000.00 and i can change it $50,000.00. Thank God! it is not that easy.

Now, here it come JOSN Web Signature (JWS) Security experts (not me!) has developed a security control to protect for altering or modifying JWTs, i cannot longer change my credit limit. which is by digitally sign the JWT - so it becomes JWS- the digitally sign token can protect the integrity and the authenticity of token. A JWS represents content secured with digital signatures or Message Authentication Codes (MACs)

note: Digital Signature only provide integrity and authenticity of the token as described

Integrity: meaning the token payload never been changed or altered of MACs calculation will fail.

Authenticity: assurance that the issuer of the token, is what he/she/it claims to be (for example IdP). by have PKI infrastructure IdP can sign the JWT with its private key and the target endpoint can validate the signature by a shred previously public key, and if the signature failed to be validated, that it is not from the true issuer, thus, the token is market invalid. So, no one is able try A man-in-the-middle (MITM) attack.

Important note: Digital Signature has nothing to do with encryption, token payloads are in a clear text as they traverse the public internet (BASE64 encoded). so, any attack of data leakage is still can happened - witch is actually reported by 30% of the total attacks in 2024 API security market research report- see below

So, to provide confidentially (covering those sensitive 30% of excess data exposure) JSON Web Encryption (JWE) come into place as form of encrypted JWT, now, no one expect the token issuer and the entity that has the decryption key can actually read and validate the content of the JWT payload, which bring us to the final level of the API security maturity model, level 4 Claims - Highly evolved identity -based API security and the use of Opaque Token

Level 4: Claims – Highly evolved identity-based API Security?

This level is revolving on two main principles to achieve the highest security of your APIs and that is truly what you need when you are pushed by business to implement OPEN BANKING that is called Zero Trust Architecture (ZTA) which is called upon specifically for APIs by NIST SP 800-207

Trust Claims, NOT Attributes: in this first principle i would like to ease it out by giving a little example, if i may, Let's say I am " Samir Reyad " and you are a policeman who has a duty to verify my information. Let's start my me, I am subject, my name is an attribute, my age is also an attribute, my gender is also an attribute and on and on.

So, when i present to you the National ID or my Driving license you should verify claims and should not verify attributes, the claim in this example is my driving license issued by the National Traffic Bureau NOT my attributes form within. so, all they attribute within my driving license is asserted to be truthful by the police ONLY. i hope the below illustration explain this example of the first principle.

so, after the policeman checks my driving license, he can always say let go the traffic bureau main office to verify that claim in my hand, off course, that defeat the purpose of authorization and delay me as well - think of the data traversing- can you imagine for while that we reach the area which i will not be able to read my own driving license. When it was issued to me at the National Traffic Bureau, I have been instructed to just give it as is to the policeman on the street and he will take care of validating you. HOW COOL IS THAT ?! in terms of security OfCourse. this is what's happening in the Opaque Token architecture, Opaque tokens cannot be read by clients that hold them since they are undecodable strings (encrypted) clients just use them as is without knowing its content, the illustration below explain the concepts of Opaque token and level 4 of the API Security Maturity Model

Note: I have made an architecture Illustration for Level 4 only as it is the most secure and intended and recommended for OPEN BANKING services,

Important Note: it is recommended to use JWT for internal API calls within your origination and use Opaque Token for Publicly exposed API (over the Internet).

who do we trust? participants in trust: back to the API security, obviously the participants in trust are very few as listed below

• The Authoritative point: in the field of API security architecture is called PDP (Policy Decision Point) which is normally the IdP with the ultimate claims and responsibility of token issuance and token signing and encryption as well.
• Requesting point: usually the bank client who is requesting services form an endpoint or a protected resource (usually core banking system), which we agreed before in most scenarios we will not give this party access to modify or to read our token (use.
• Protected Point (Resource): the actual system or systems of applications that provide the service, and it is not recommended to have this component participate in the trust or the authorization of service, for simply two reasons, one reason: is that system should be providing pure service and should not hold any clients' databases or clients' grant scopes, the second reason: is that this system architecturally should have been placed deep into your protected zone in you network, so from the security perspective, you should not leave an attacker with invalid token all the way inside your network before validating the claim and reject him, it is like you do not want a thief to steal your safe located in your bedroom and yet, you are leaving him to enter your backyard, then the main house door, then on the stairs, before you kick him out.
• Relying Point: the component(s) also called Policy Enforcement Point (PEP) that is delegated by the Authoritative Point or IdP to check and validate the token (our policeman in the previous example). which will allow the requesting point to access the protected resource based on the given token security policy by the IdP. this component act as a first line of defense to your API security infrastructure, if the claim fails due to malicious or fraudulent activities, then the sooner the API call is being suspended or rejected is better. before reaching any further within you API infrastructure. therefore, I personally recommend the relying point to be the API gateway.

Trust No one - Zero Trust: depending on the previous information, trust should be split between the Authoritative Point and the relying point, this approach will achieve the following security controls in addition to applying ZTA (Zero Trust Architecture).

1. Defense in Depth: it takes two or more components to issue and verify the Token security policy, so you have the API getaway as fist line of defense and the IdP as the second line of defense.
2. Parameter Protection: we all know that the API gateway sets at the edge of your network (just behind your WAF device) so, if there is a token which violates your security policy, the suspected token and its client will be stopped right at the gates of your network instead of going deep with it your infrastructure.
3. Maker/Checker Control: definitely you don't want your Policy Decision Point (PDP) to validate it issued token, this defeat the whole ZTA of trusting no one also if someone (employee) did apply a token policy that is not secure or in compliance with a regulation body, how you will be able to validate it or stop it.
4. Split Responsibility Control: no one component has solely the ultimate decision on the authentication and authorization of the tokens and its claims. and better yet, in terms of human resources, if the staff responsible for configuring the PDP (Policy Decision Point - IdP) is different form the staff responsible for configurating the API gateway (Policy Enforcement Point PEP).

Conclusion

Finally, this article was made to illustrate the API security maturity model and the benefit of reaching level 4 or the top level of security. especially when we talk about financial services and OPEN BANKING. let me tell you, level 4 of the API security maturity model it is not for everyone. and Opaque Token architecture is not easy to achieve. but if you are working at a bank as a security architect it worth a while to explore thoroughly and implement such architecture for your bank API most secure API Model. however, if your organization are not involved heavily in using online digital payment or wants to become a payment hub or have a plan to develop Digital wallets, then, Level 3 or Level 2 in the API security maturity model is the one recommended for you.

References

• Curity for identity management Curity: Identity Management for APIs, Apps and Websites
• Zero Trust Architecture by NIST (NIST SP 800-207) Zero Trust Architecture
• OAuth 2.0 framework RFC 6749 RFC 6749 - The OAuth 2.0 Authorization Framework
• OAuth 2.0 Authorization Server Metadata RFC 8414 RFC8414 - OAuth 2.0 Authorization Server Metadata
• GDBR - Personal Data Protection Policy Data protection under GDPR - Your Europe
• PCI-DSS v4.0 Payment Card Industry Data Security Standard
• US office of Comptroller of the Currency OCC Regulations | OCC
• Federal Deposit insurance Corporation FDIC: Federal Deposit Insurance Corporation
• The Saudi Arabian Monetary Authority Cybersecurity Framework SAMA Cyber Security Framework.pdf
• JSON Web Token (JWT) RFC 7519 - JSON Web Token (JWT)
• JSON Web Signature (JWS) RFC 7515: JSON Web Signature (JWS)
• JSON Web Encryption (JWE) RFC 7516 - JSON Web Encryption (JWE)