In many cases, Fintech services such as aggregation services use screen scraping and store user passwords. This model is both brittle and insecure. To cope with the brittleness, it should utilize an API model with structured data and to cope with insecurity, it should utilize a token model such as OAuth [RFC6749, RFC6750].

Financial API aims to rectify the situation by developing a REST/JSON model protected by OAuth. However, just asking to use OAuth is too vague as there are many implementation choices. OAuth is a framework which can cover wide range of use-cases thus some implementation choices are easy to implement but less secure and some implementation choices are harder to implement but more secure. Financial services on the internet is a use-case that requires more secure implementation choices. That is, OAuth needs to be profiled to be used in the financial use-cases.

The OpenBanking Profile detailed below outlines the differences between the FAPI R+W profile with clauses and provisions necessary to reduce delivery risk for ASPSPs OP

The key words "shall", "shall not", "should", "should not", "may", and "can" in this document are to be interpreted as described in ISO Directive Part 2. These key words are not used as dictionary terms such that any occurence of them shall be interpreted as key words and are not to be interpreted with their natural language meanings.

This document is based on the OpenID Foundations Financial API Read+Write specification document which in turn is based on the Read only specification document. The OpenBanking profile will further shape these two base profiles in some cases tightening restrictions and in others loosening requirements using key words 

Open Banking's API Profile does not distinguish between the security requirements from a technical level between "read" and "write" resources. The security requirements for accessing PSU resources held at ASPSPs requires more protection level than a basic RFC6749 supports. 

As a profile of The OAuth 2.0 Authorization Framework, this document mandates the following to the OpenBanking Financial APIs.

The Authorization Server

• shall support confidential clients;

• shall not support public clients;

• shall support user authentication at appropriate level as defined in PSD2 be that LoA 3 or 2 or other.

• shall require the response_type values code or code id_token or code id_token token;

• shall authenticate the confidential client at the Token Endpoint using one of the following methods:

  1. TLS mutual authentication [MTLS] https://tools.ietf.org/id/draft-ietf-oauth-mtls-02.xml; or (Recommended)

  2. client_secret_basic or client_secret_post provided the client identifier matches the client identifier bound to the underlying mutually authenticated TLS transport session; or (Allowed)

  3. JWS Client Assertion using the client_secret or a private key as specified in section 9 of [OIDC]; (Recommended)

• shall issue an ID Token in the token response when openid was included in the requested scope as in Section 3.1.3.3 of OIDC with its sub value corresponding to the "Intent Ticket ID"  and optional acr value in ID Token.

• may support refresh tokens.

Further, if it wishes to provide the authenticated user's identifier to the client in the token response, the authorization server

• shall issue an ID Token in the token response when openid was included in the requested scope as in Section 3.1.3.3 of [OIDC] with its sub value corresponding to the authenticated user and mandatory acr value in ID Token.

• must support Request Objects passed by value as in clause 6.3 of OIDC.
  
  

OpenBanking OPs can support Public Clients at their discretion.

Should an OP wish to support public clients all provisions of the FAPI Read Write API security profile will be adhered too with exceptions below;

• shall request user authentication at appropriate level as defined in PSD2 be that LoA 3 or 2 or other.

 A Confidential Client

• may use separate and distinct Redirect URI for each Authorization Server that it talks to;

• shall support the following methods to authenticate against the Token Endpoint:

  • TLS mutual authentication [MTLS]; or

  • JWS Client Assertion using the client_secret or a private key as specified in section 9 of [OIDC]; or

  • client_secret_basic or client_secret_post provided the client identifier matches the client identifier bound to the underlying mutually authenticated TLS transport session

• shall accept signed ID Tokens; 

The resource server with the FAPI endpoints

• shall mandate mutually authenticated TLS 1.2 or later as defined in RFC5246 with the usage following the best practice in RFC7525;

• shall verify that the client identifier bound to the underlying mutually authenticated TLS transport session matches the client that the access token was issued to;

The confidential client supporting this document

• shall use mutually authenticated TLS 1.2 or later as defined in RFC5246 with the usage following the best practice in RFC7525;

• shall supply the last time the customer logged into the client in the x-fapi-customer-last-logged-time header where the value is supplied as ** w3c date **, e.g., x-fapi-customer-last-logged-time: Tue, 11 Sep 2012 19:43:31 UTC; and

• shall supply the customer’s IP address if this data is available or applicable in the x-fapi-customer-ip-address header, e.g., x-fapi-customer-ip-address: 198.51.100.119; and

• shall send x-fapi-financial-id whose value is the unique identifier of the financial institution assigned by OpenBanking.

Further, the client

• may supply the customers authentication context reference (ACR) or applicable in the x-fapi-customer-acr header, e.g., x-fapi-customer-acr; 

• OPs may not support request_uri, OIDC Request Object by Reference.

• OPs must support Request Objects passed by value as in clause 6.3 of OIDC.

Since confidential information is being exchanged, all interactions shall be encrypted with TLS/SSL (HTTPS) in accordance with the recommendations in RFC7525. TLS version 1.2 or later shall be used for all communications.

It is not mandated that the Authorization request and response are authenticated. Use of request object for the Authorization request and returning an ID token in the Authorization response should be considered to provide message source authentication and integrity protection.

In this document, the authorization request is not encrypted. Thus, it is possible to leak the information contained if the browser was infected with virus, etc.

Authorization response can be encrypted if an ID token is returned as ID tokens can be encrypted.