Version Control

UK Open Banking OIDC Security Profile

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

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 

JSON Security Suite Information v1.0

General Guidance for JWT Best Practice: To Be Followed Where Appropriate

http://self-issued.info/docs/draft-sheffer-oauth-jwt-bcp-00.html#rfc.section.3.1

Algorithms to be supported: All Asymmetric Algorithms listed below

• TLS_DHE_RSA_WITH_AES_128_GCM_SHA256
• TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
• TLS_DHE_RSA_WITH_AES_256_GCM_SHA384
• TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384

JWKS Endpoints

All JWKS endpoints will be hosted by OpenBanking Ltd. Upon issuance of a certificate a JWK Set will be created or updated for a given TPP.

All participants should include "kid" and "jku" of the key that was used to sign the payloads. The JKU should be considered a hint only and relying parties should derive and then validate wherever possible the appropriate JWKS endpoint for the message signer.

https://tools.ietf.org/html/draft-ietf-jose-json-web-signature-41#section-4.1

example:

https://keystore.openbanking.org.uk/tpp/12345678.jwks

As certificates are added and removed by Participant Technical Contacts the jwks endpoint will be updated automatically.

General outline for creating a JWS

Step 1: Select the certificate and private key that will be used for signing the JWS

As the JWS is used for non-repudiation, it MUST be signed using one of JWS issuer's private keys.

The private key MUST have been used by the issuer to get a signing certificate issued from OB. 

The signing certificate MUST be valid at the time of creating the JWS.

Step 2: Form the JOSE Header

The JOSE header is a JSON object consisting of three fields (claims):

   The "kid" (key ID) Header Parameter is a hint indicating which key
   was used to secure the JWS. 

Step 3: Form the payload to be signed

The JSON payload to be signed must have the following claims:

The payload to be signed is computed as:

Where:

JOSEHeader: is the header created in Step 2 and

json: is the message the original data to be sent

Step 4: Sign and encode the payload

The signed payload is computed as:

Where:

privateKey: is the private key selected in step 1

payload: is the payload computed in Step 3

encrypt: Is an encryption function that implements the `alg` identified in Step 2.

Step 5: Assemble the JWS

The JWS is computed as

Where:

payload: is the payload computed in Step 3

signedAndEncodedPayload: is the signed element computed in Step 5.

Implementation Guide

Overview

This page provides an implementation perspective of the OB Security Profile aligned to the accepted OB Read/Write APIs for Payments and Accounts Specifications.

Specified Behaviour

The implementation of both the Payments and Accounts API are based on the following known configurations:

Client Types

• As per the OAuth 2.0 specification, the Confidential Client Type is illustrated for both Accounts and Payments API as it has the ability to maintain its own credentials.

Grant Types

OIDC Hybrid Flow (response_type=code id_token)

• Both the Payments and Accounts APIs illustrate the use of request_type=code id_token for the OIDC Hybrid Flow implementation.    
• The ASPSP may optionally choose to return Refresh Tokens for the Hybrid Flow when issuing an Access Token

Client Credentials Grant Type using multiple scopes (scope=accounts payments)

• The Client Credentials Grant Type is used across both Payments and Account APIs only when the TPP (AISP/PISP) requires an Access Token (on behalf of itself) in order to access a Payment or Accounts API resource e.g.
  

  • Payments:

  • Accounts: 

• Where an ASPSP enables the same Confidential Client  (ClientId) access to both Payments and Accounts APIs, a TPP may therefore choose to request for either a single scope e.g. accounts or for multiple scope(s) e.g. accounts payments as the TPP may want to use the same Access Token across both APIs. 
• Only valid API scopes will be accepted when generating an Access Token (accounts payments). 
• Access tokens generated by a Client Credentials grant may not return any refresh tokens (as per the OAuth 2.0 specification)

Access Tokens

• For the Payments and Accounts APIs, the Access Token must be obtained within a Secure, Server Side Context between the TPP (AISP / PISP) and the ASPSP. 
• Access Tokens must be validated by the TPP (AISP/PISP) as outlined within the OIDC Errata 1 Specification

Refresh Tokens

• ASPSPs may optionally return a Refresh Token when an Authorization Request is successfully processed at the Token endpoint. The Hybrid flow supports the provisioning of Refresh Tokens.
• The Accounts API implementation below cites an example for AISPs requesting a Refresh Token to refresh an expired Access Token prior to invoking the /accounts resource.
• Refresh Tokens must be validated as outlined in the OIDC Errata 1 Specification

ID Tokens 

• ID Tokens must be validated by the TPP (AISP/PISP) as outlined within the OIDC Errata 1 Specification
• TPPs must use the openbanking_intent_id claim to populate and retrieve the IntentID (PaymentID for Payments API and AccountRequestId for the Accounts API) for any required validation.
• The full set of claims that can be represented within an ID Token are documented in the Request Object and ID Token Section of the Security Profile.

Authorization Codes

• Authorization Codes must be validated by the TPP (AISP/PISP) as outlined within the OIDC Errata 1 Specification

Un-Specified Behaviour

The implementation of both the Payments and Accounts API are un-specified for the following configurations: 

Client Types

• As per the OAuth 2.0 specification, the Public Client Type has not been illustrated for both Payments and Accounts APIs.
  
  

Grant Types

OIDC Hybrid Flow (response_type=code id_token token or response_type=code token)

• Forces an Access Token to be returned from the ASPSP Authorization endpoint (instead of a token endpoint). This is not illustrated in the Payments and Accounts API Specifications.

OIDC Implicit Flow (response_type=id_token token or response_type=id_token)

• The Implicit Flow does not authenticate the Client that is invoking the request. This is not illustrated in the Payments and Accounts API Specifications.

Client Credentials Grant Type(scope=openid email profile address phone)

• Requesting OIDC specific scopes or any un-specified scopes when using the Client Credentials grant. 

Validity Lengths (Authorization Code, Access Token, ID Token, Refresh Token)

These are to be managed in the competitive space; Each ASPSP's Authorization / Resource Server will be configured independently to comply with internal ASPSP Security Policies and Guidelines. The Accounts and Payments API Specifications do not mandate validity lengths. 

Authorization Code

•  OAuth 2.0 Specification suggests an Authorization Code should be short lived to a maximum of 10 minutes. Any codes exceeding this limit to be rejected.

ID Token

• ID Token claims (exp and iat) determine its validity.

• Returned with the Authorization Code when the Hybrid flow (code id_token) is initiated.

Access Token

• The expires_in attribute returned by the Authorization Server when an Access Token is generated determines its validity.
• Access Tokens are generally short lived, and where they expire, are then exchanged for another using a longer lived Refresh Token.
• Refer to Section 16.18 of the OIDC Specification  - Lifetimes of Access Tokens and Refresh Tokens.

Refresh Token

• The expires_in attribute returned by the Authorization Server when a Refresh Token is generated determines its validity.
• Refresh Tokens are generally longer lived in comparison to Access Tokens.
• Refer to Section 16.18 of the OIDC Specification  - Lifetimes of Access Tokens and Refresh Tokens.

Success Flows

Payment API Specification

The sequence diagram below highlights the OAuth 2.0 Client Credentials Grant and OIDC Hybrid flow that are used by the Payments API. 

Client Credentials Grant Type (OAuth 2.0)

Summary

This grant type is used by the PISP in Step 2 to setup a single payment with the ASPSP.

1. The PISP initiates an Authorization request using valid Client Credentials Grant type and scope(s)
2. The ASPSP Authorization Server validates the Client Authentication request from the PISP and generates an Access Token response where the request is valid
3. The PISP uses the Access Token to create a new Payment resource against the ASPSP Resource Server
4. The ASPSP Resource server responds with the PaymentId for the resource it has created. 
5. The Client Credentials Grant may optionally be used by the PISP in Step 5 to retrieve the status of a Payment or Payment-Submission where no active Access Token is available.
   
   
   

OIDC Hybrid Flow

Summary

• The Hybrid flow is the recommendation from the OB Security Profile and the FAPI Specification for R/W. The Hybrid flow prevents IdP mixup attacks as documented by Nat Sakimura - Cut and Paste OAuth 2.0 Attack
• This is initiated at the end of Step 2 by the PISP after the PaymentId is generated by the ASPSP and returned to the PISP.
• This is used in a redirect across the PSU and ASPSP in Step 3 in order for the PSU to authorize consent with the ASPSP - for the PISP to proceed with the Payment.
• This is used across the PISP and ASPSP in Step 4 by exchanging the Authorization Code for an Access Token in order to create the Payment-Submission resource.
  
  

Non-Normative HTTP Request and Response Examples

Step 1 - Request Payment Initiation

There are no Requests and Responses against the Payments API in this Step for the PSU, PISP and ASPSP.

Step 2 - Setup Single Payment Initiation

1. PISP obtains an Access Token using a Client Credentials Grant Type. The scope payments must be used. When an Access Token expires, the PISP will need to re-request for another Access Token using the same request below. 

2. PISP uses the Access Token (with payments scope) from the ASPSP to invoke the Payments API.  This example is sourced directly from the Payment API Specification

Step 3 - Authorize Consent

1. PISP receives a PaymentId from the ASPSP. The PISP then creates an Authorization request (using a signed JWT Request containing the PaymentID as a claim) for the PSU to consent to the Payment directly with their ASPSP. The request is an OIDC Hybrid flow (requesting for Code and id_token)

2. The PSU is then redirected to the PISP. The PISP will now possess the Authorization Code and ID Token from the ASPSP. Note at this point, there is no Access Token. The PISP will now introspect the ID Token and use it as a detached signature to check:

• The hash of the Authorization Code to prove it hasn't been tampered with during redirect (comparing the hash value against the c_hash attribute in ID Token)
• The hash of the State to prove it hasn't been tampered with during redirect (comparing the state hash value against the s_hash attribute in the ID Token)

3. Once the state and code validations have been confirmed as successful by use of the ID token, the PISP will proceed to obtain an Access Token from the ASPSP using the Authorization Code they now possess. The PISP will present its Authorization Code together with the private_key_jwt. The Access Token is required by the PISP in order to submit the Payment on behalf of the PSU. The payments scope should already be associated with the Authorization Code generated in the previous step.

Step 4 - Create Payment-Submission

1. The PISP has an Access Token which can be used to Create a Payment-Submission (Step 4). The PISP must obtain the PaymentId (Intent-ID) so that the Payment request is associated with the correct PaymentId. This can be sourced from either:

1. The PaymentId claim from the signed ID Token (default). The PISP will need to decode the ID Token JWT and locate the claim attribute associated with the PaymentId.
2. The PaymentId claim from the /userInfo resource endpoint of the ASPSP (optional for ASPSPs to implement) .

The example below provides an illustration of the PISP requesting the /userInfo endpoint of the ASPSP in order to get the PaymentID (returned as openbanking_intent_id)

2. The PISP can now invoke the /payment-submissions endpoint to commit the Payment using the Access Token and PaymentId in the payload of the request. This example is sourced from the Payment Initiation API Specification

Step 5 - Get Payment-Submission Status

1. The PISP can query for the status of a Payment-Submission by invoking the /payment-submissions using the known PaymentSubmissionId. This can use an existing access token with payments scope or the PISP can obtain a fresh access token by replaying the client credentials grant request as per Step 2 - Setup Single Payment Initiation.

2. A PISP can also optionally query for the status of a Payment resource by invoking /payments/{PaymentId}. This can use an existing access token with payments scope or the PISP can obtain a fresh access token by replaying the client credentials grant request as per Step 2 - Setup Single Payment Initiation.

Account API Specification

The sequence diagram below highlights the OAuth 2.0 Client Credentials Grant and OIDC Hybrid flow that are used by the Account and Transactions API.

Client Credentials Grant Type (OAuth 2.0)

Summary

This grant type is used by the AISP in Step 2 to register an intent for the PSU to allow the AISP to retrieve their Account information from an ASPSP.

1. The AISP initiates an Authorization request using valid Client Credentials Grant type and scope(s)
2. The ASPSP Authorization Server validates the Client Authentication request from the AISP and generates an Access Token response where the request is valid
3. The AISP uses the Access Token to create a new Account Request resource against the ASPSP Resource Server
4. The ASPSP Resource server responds with the AccountRequestId representing the resource it has created. 

OIDC Hybrid Flow

Summary

• This is initiated at the end of Step 2 by the AISP after the AccountRequestId is generated by the ASPSP and returned to the AISP.
• This is used in a redirect across the PSU and ASPSP in Step 3 in order for the PSU to authorize consent with the ASPSP - for the AISP to proceed with the requesting Account information.
• This is used across the AISP and ASPSP in Step 4 by swapping the Authorization Code for an Access Token in order to retrieve PSU Account information.

Non-Normative HTTP Request and Response Examples

Step 1 - Request Account Information

There are no Requests and Responses against the Payments API in this Step for the PSU, PISP and ASPSP.

Step 2 - Setup Account Request

1. AISP obtains an Access Token using a Client Credentials Grant Type. The scope accounts must be used. When an Access Token expires, the AISP will need to re-request for another Access Token using the same request below.

2. AISP uses the Access Token (with accounts scope) from the ASPSP to invoke the Accounts API.  This example is sourced directly from the Account and Transactions API Specification

Step 3 - Authorize Consent

1. AISP receives a AccountRequestId from the ASPSP. The AISP then creates an Authorization request (using a signed JWT Request containing the AccountRequestId as a claim) for the PSU to consent to the Account request directly with their ASPSP. The request is an OIDC Hybrid flow (requesting for Code and id_token)

2. The PSU is then redirected to the AISP. The AISP will now possess the Authorization Code and ID Token from the ASPSP. Note at this point, there is no Access Token. The AISP will now introspect the ID Token and use it as a detached signature to check:

• The hash of the Authorization Code to prove it hasn't been tampered with during redirect (comparing the hash value against the c_hash attribute in ID Token)
• The hash of the State to prove it hasn't been tampered with during redirect (comparing the state hash value against the s_hash attribute in the ID Token)

3. Once the state and code validations have been confirmed as successful by use of the ID token, the AISP will proceed to obtain an Access Token from the ASPSP using the Authorization Code they now possess. The AISP will present its Authorization Code together with the private_key_jwt. The Access Token is required by the AISP in order to access PSU Account information. The accounts scope should already be associated with the Authorization Code generated in the previous step.

Step 4 - Request Account Data

1. The AISP can use the Access Token to retrieve Accounts (bulk or specific). The following examples are from the Account and Transaction API Specification

Where the initial Access Token expires, the AISP can use the Refresh token in order to obtain a fresh Access Token.

Edge Cases

This section provides further information on potential edge cases that may arise via the implementation of Accounts and Payments API Specifications. 

PSU Consent Authorization Interrupt with ASPSP