Authentication and Authorization

oAuth 2.0 in conjunction with OpenID Connect are recommended as authentication protocols because they provide a more comprehensive and extensible approach to security than some of the basic authentication and authorization mechanisms. Based on security tokens, it can be used for delegated authority such as enabling a mobile application to act on behalf of its user.

oAuth 2.0 is appropriate where there is a requirement for third-party applications to access restricted resources. This should help mitigate the risks relating to:

• Third party applications storing user credentials (username and password)
• Resource servers having to support user stores and password authentication
• Resource owners not being able to define granular access to resources, including duration
• Revoking credentials that are compromised

When securing APIs, authentication is required to identify the consumers and/or consuming applications that want to access or consume an API. Authentication enables the API provider to identify all consumers of an API and to confirm that the consumer requesting access is who they say they are. This doesn’t automatically authorize them to access the APIs or the underlying resources.

It is highly recommended to use OAuth 2.0 with multifactor authentication variants.

API Key Authentication

API keys should be used for every system-to-system interaction with a production level API. API Keys are a digital authentication mechanism, with the API key taking the form of a long string of generated characters. API keys are usually unique and can be assigned to an application, developer or user. The usual practice is for an application developer to obtain a key for their application from the bank and utilize the key within their application.

To obtain an API key, the developer must undergo a registration process with the bank. The steps involved in the registration process are dependent on the level of risk associated with the API. API Keys should be used wherever system to system authentication is needed. They are suitable for simple public APIs which do not need more complex authentication models. API Keys should be used in preference to username and passwords because:

1. More secure - greater entropy than passwords – a random long string of characters
2. Speed – API keys do not involve any hashing process, i.e. the hashing process required for passwords

However, the risk is that anyone with a copy of the API key can use it as though they were the legitimate consuming application. Hence all communications should be over TLS 1.2 or higher, to protect the key in transit.

Certificates (Mutual) Authentication

Use this model when the API requires stronger authentication than offered solely by API Keys, and the overhead of certificate management is warranted.

In Certificate (Mutual) Authentication, internal and external parties are authenticated with each other. Both the consuming application and the API provider hold a digital certificate. The digital certificate (extended validated) can be trusted because it was issued by a mutually trusted Certificate Authority (CA). When the consuming application makes a request to the API, the server hosting the API presents its certificate to the consuming app. The app verifies the server’s certificate then sends its own certificate to the server. The server verifies the client certificate and mutual trust is achieved, allowing the consuming application to use the API.

Authorization is the act of performing access control on a resource. Authorization does not just cover the enforcement of access controls, but also the definition of those controls. This includes the access rules and policies, which should define the required level of access agreeable to both provider and consuming application. The foundation of access control is a provider granting or denying a consuming application and/or consumer access to a resource to a certain level of granularity.

Confidentiality and Integrity

Confidentiality and integrity cover the handling of request and response data, both in transit and at rest. The aim is to protect the payload content from unauthorized access, manipulation or faking. An API request needs to be received intact by the API, with validation as to the source of the request. Untampered API responses need to be received by the consuming application, with confirmation that they are legitimately from the API.

All communications to or from an API must be over TLS 1.2 or higher. Other versions of TLS and SSL should be disabled. This provides a recognized level of confidentiality that covers all communications between all components.

The consuming application must validate the TLS certificate chain when making requests to protected resources, including checking the Certificate Revocation List (CRL).

Note: State is used to provide a level of integrity when using the standard format of bearer tokens. The confidence in the level of integrity can be increased in JWT tokens are used for bearer tokens. (See Integrity sections below).