Strong Customer Authentication (SCA)

Strong Customer Authentication (SCA) is an important part of trusted and secure APIs. Many authorities across different industries describe and require SCA as e.g. the European Banking Authority.

SCA is not a standardized term but is mostly referred to the following core requirements:

• Users must authenticate with at least two factors (something you know, something you have, something you are)
• Each sensitive action has to be legitimated by an authentication code (derived from the above authentication) which is cryptographically linked to the essential details of the action: e.g. payment amount, origin-URI, …

Common APIs approach for future proof Strong Customer Authentication:

1. Separation of Business & Access Control API to reduce complexity and increase flexibility
2. Use of FAPI (Financial Grade API) as a technical specification for high risk use cases
3. Use of Pushed Authorization Requests (PAR) to add a additional layer of security
4. (added back channel for authentication information)

Separation of Business & AuthN/AuthZ API

It is a fundamental decision whether or not to integrate the AuthN, AuthZ logic into the Business API. The trend is towards the use of separation by using e.g. FAPI.

TBG (The Berlin Group) uses a hybrid approach where business logic is mixed with access management components. But there are discussions going on, which could lead to TBG also using FAPI.

Common API currently focuses on the separating approach.

Use of Financial Grade API (FAPI)

OpenID Financial-grade API (FAPI) is a hardened version of OAuth 2.0 (& therefore OpenID Connect) for high risk use cases. New features (next to others):

• JWT Secured Authorization Response Mode (JARM): Encrypted / signed authorization response parameters along with additional data to protect e.g. from replay attacks
• Token Binding: Making the token unusable for connections established by a client other than the legitimate one (access or id token is binded to the original client e.g. with help of MTLS)

https://fapi.openid.net/ : Financial-grade API (FAPI) is an industry-led specification of JSON data schemas, security and privacy protocols to support use cases for commercial and investment banking accounts as well as insurance and credit card accounts. FinTech developers can accelerate Secure Open Banking.

Common API pushes a FAPI Swiss Finish definition, which defines among others the following specialities with regard to the Swiss data protection law:

• Security Policy (JWT)
• Discovery Standards
• Central authority to manage the back channel authentication (Privat, Public)

The proposed FAPI Swiss Finish must of course be discussed intensively with the authorities and the banking association.

Remark: If parties want to start before a central authority is established, they can build up their own authority or uses the peer to peer approach.

Use of Pushed Authorization Requests (PAR)

Latest PAR specification draft: https://tools.ietf.org/html/draft-ietf-oauth-par-04 (work in progress) which is the basis of the following descriptions.

OAuth 2.0 Pushed Authorization Requests (PAR) introduces the „pushed authorization requests“ endpoint (PAR). This new endpoint allows clients to push authorization requests through an authorization server instead of sending them via redirect through the browser.

RAR (Rich Authorization Request) introduces the request parameter „authorization_details“ that will carry authorization data for a certain API or resource.

Common API: tbd how suitable PAR is for the Swiss market (e.g. need of central authority)

Why?

In OAuth authorization request parameters are typically sent as URI query parameters via redirection in the user-agent. This yields security challenges in the area of confidentiality and integrity.

Solutions for that as JWT Secured Authorization Request (JAR) provides solutions for the security challenges by allowing OAuth clients to wrap authorization request parameters in a request object, which is a signed and optionally encrypted JSON Web Token (JWT).

But PAR allows the authorization server to authenticate the client before any user interaction happens and therefore to refuse illegitimate requests much earlier in the process, which can prevent attempts to spoof clients or otherwise tamper with or misuse an authorization request.

How?

Back-channel submission of authorization parameters: PAR complements JAR by providing an interoperable way to push the payload of an authorization request directly to the authorization server in exchange for a "request_uri" value usable at the authorization server in a subsequent authorization request.

Example

“Traditional”

 GET /authorize?response_type=code
   &client_id=s6BhdRkqt3&state=af0ifjsldkj
   &redirect_uri=https%3A%2F%2Fclient.example.org%2Fcb HTTP/1.1
 Host: as.example.com

PAR

 POST /as/par HTTP/1.1
 Host: as.example.com
 Content-Type: application/x-www-form-urlencoded
 Authorization: Basic czZCaGRSa3F0Mzo3RmpmcDBaQnIxS3REUmJuZlZkbUl3
 response_type=code
 &client_id=s6BhdRkqt3&state=af0ifjsldkj
 &redirect_uri=https%3A%2F%2Fclient.example.org%2Fcb
 
 The authorization server responds with a request URI:
    
 HTTP/1.1 201 Created
 Cache-Control: no-cache, no-store
 Content-Type: application/json
 {
   "request_uri": "urn:example:bwc4JK-ESC0w8acc191e-Y1LTC2",
   "expires_in": 90
 }
 
 The client uses the request URI value to create the subsequent
 authorization request by directing the user-agent to make an HTTP
 request to the authorization server's authorization endpoint like the
 following:
 
 GET /authorize?client_id=s6BhdRkqt3
   &request_uri=urn%3Aexample%3Abwc4JK-ESC0w8acc191e-Y1LTC2 HTTP/1.1
 Host: as.example.com

Challenges?

Establish a secure connection between the TPP and the FI to post the authentication request (e.g. RAR - rich authentication request).

A trusted, central authority may be needed.