Version Control

UK Open Banking OIDC Security Profile

Introduction

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

Notational Conventions

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.

Financial Services – Open Banking API Security Profile

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 

5. Read and Write API Security Profile

5.2  OB API Security Provisions

5.2.1 Introduction

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.

5.2.2 Authorization Server

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.
  
  

5.2.3 Public Client

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.

5.2.4 Confidential Client

 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; 

6. Accessing Protected Resources

6.2 Access provisions

6.2.1 Protected resources provisions

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;

6.3 Client provisions

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; 

7. Request object endpoint

7.1 Introduction

• 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.

8. Security Considerations

8.1 TLS Considerations

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.

8.2 Message source authentication failure and message integrity protection failure

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.

8.3 Message containment failure

8.3.1 Authorization request and response

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.

It is possible to leak the information through the logs if the parameters were recorded in the logs and the access to the logs are compromised. Strict access control to the logs in such cases should be enforced.

8.3.2 Token request and response

It is possible to leak the information through the logs if the parameters were recorded in the logs and the access to the logs are compromised. Strict access control to the logs in such cases should be enforced.

8.3.3 Resource request and response

Care should be taken so that the sensitive data will not be leaked through the referrer.

If the access token is a bearer token, it is possible to exercise the stolen token. Since the access token can be used against multiple URIs, the risk of its leaking is much larger than the refresh token, which is used only against the token endpoint. Thus, the lifetime of the access token should be much shorter than that of the refresh token. Refer to section 16.18 of OIDC for more discussion on the lifetimes of access tokens and refresh tokens.

Security Architecture

OAuth 2.0, OIDC and FAPI

OAuth 2.0 will be the foundational framework for API Security in OpenBanking.  The process of requesting a token is standards based - the question is, which standards.  OAuth 2.0 itself is a framework which can be deployed in many ways, some of them completely incompatible with financial models. In order to securely use the OAuth 2.0 framework, a profile must exist by which both TPP and ASPSP participants are certified to have correctly configured their clients and servers.  The Financial API working group in the OpenID Foundation has created a draft standard for configuration of financial grade API security regimes, and it is strongly recommended that OpenBanking follow that standard.  If any FAPI-compliant vendor can participate in the OpenBanking ecosystem, it means that vendors can work to the standard and reach many customers, rather than having to create different solutions for different banking platforms. 

Consuming PSU owned Resources from an ASPSP

Open

Overview

See:  http://openid.net/specs/openid-connect-core-1_0.html#JWTRequests (OpenID Connect Core Section 6)

The OpenID Connect Request object uses exactly the same claims object for specifying claim names, priorities, and values, however if the request object is used, the claims object becomes a member in an assertion that can be signed and encrypted, allowing the ASPSP to authenticate the request from the TPP and ensure it hasn't been tampered with.  The OpenID Connect request object can either be passed as a query string parameter, or can be referenced at an endpoint that could theoretically be protected by MATLS. OpenBanking, in conjuction with major IAM vendors, is ruling out the use of JWT Request objects by reference due a number of delivery risks and remaining security concerns.

In addition to specifying a ticket, the TPP can optionally require a minimum strength of authentication context or request to know how long ago the user was actually authenticated.  Multiple tickets could be passed if necessary.  Everything is fully specified. Vendors who implement this feature are not creating a one-off proprietary feature, they are simply supporting the OpenID Connect standard.

Full accountability is available as required by all participants. Not only can the ASPSP prove that they received the original request from the TPP, but the TPP can prove that the access token that comes back was the token that was intended to be affiliated to this specific payment.

Hybrid Flow Request with Intent Id

This section describes parameters that should be used with an hybrid grant flow request so that an intent id can be passed from the TPP to an ASPSP.

Prior to this step, 

1. The TPP would have already registered an intent with an ASPSP. This is achieved by using one of the account information or payment initiation APIs.

2. The ASPSP would have responsded with an intent id.

Hybrid Grant Parameters

Minimum Conformance

Overview

This section describes the bare minimum set of Authorization Request parameters that an ASPSP must support for the Jan, 2018 release. The technical definitive reference is specified in OpenID Connect Core Errata 1 Section 6.1 (Request Object). All standards and guidance MUST be followed as per the specification.

All ASPSPs MUST support the issuance of OIDC ID Tokens, a TPP MAY request that an ID token is issued. 

Example for minimum conformance

Examples are non-normative

HTTP Request

Request JWS (Without Base64 encoding)

Note that "essential" is an optional required OPTIONAL. Indicates whether the Claim being requested is an Essential Claim. If the value is true, this indicates that the Claim is an Essential Claim. For instance, the Claim request:

"auth_time": {"essential": true}

can be used to specify that it is Essential to return an auth_time Claim Value.If the value is false, it indicates that it is a Voluntary Claim. The default is false.By requesting Claims as Essential Claims, the RP indicates to the End-User that releasing these Claims will ensure a smooth authorization for the specific task requested by the End-User. Note that even if the Claims are not available because the End-User did not authorize their release or they are not present, the Authorization Server MUST NOT generate an error when Claims are not returned, whether they are Essential or Voluntary, unless otherwise specified in the description of the specific claim. OIDC Core

id_token returned - Sub being populated with an EphemeralId of the IntentId - Non Normative

id_token returned - Identity Claims and IntentId With sub being populated with an UserIdentifier - Non Normative

 ID Token Claims Details: Where appropriate please follow the JWT Good Practice Guides http://self-issued.info/docs/draft-sheffer-oauth-jwt-bcp-00.html#rfc.section.3.1