Right now there is quite some movement in the financial sector towards APIs and “collaboration” scenarios. The OpenID Foundation started a dedicated working group on securing Financial APIs (FAPIs) and the upcoming Revised Payment Service EU Directive (PSD2 – official document, vendor-based article) will bring quite some change to how technology is used at banks as well as to banking itself.

Googling for PSD2 shows quite a lot of ads and sponsored search results, which tells me that there is money to be made (pun intended).

We have a couple of customers that asked me about FAPIs and how IdentityServer can help them in this new world. In short, the answer is that both FAPIs in the OIDF sense and PSD2 are based on tokens and are either inspired by OpenID Connect/OAuth 2 or even tightly coupled with them. So moving to these technologies is definitely the first step.

The purpose of the OIDF “Financial API Part 1: Read-only API security profile” is to select a subset of the possible OpenID Connect options for clients and providers that have suitable security for the financial sector. Let’s have a look at some of those for OIDC providers (edited):

• shall support both public and confidential clients;
• shall authenticate the confidential client at the Token Endpoint using one of the following methods:
  • TLS mutual authentication [TLSM];
  • JWS Client Assertion using the client_secret or a private key as specified in section 9 of [OIDC];
• shall require a key of size 2048 bits or larger if RSA algorithms are used for the client authentication;
• shall require a key of size 160 bits or larger if elliptic curve algorithms are used for the client authentication;
• shall support PKCE [RFC7636]
• shall require Redirect URIs to be pre-registered;
• shall require the redirect_uri parameter in the authorization request;
• shall require the value of redirect_uri to exactly match one of the pre-registered redirect URIs;
• shall require user authentication at LoA 2 as defined in [X.1254] or more;
• shall require explicit consent by the user to authorize the requested scope if it has not been previously authorized;
• shall return the token response as defined in 4.1.4 of [RFC6749];
• shall return the list of allowed scopes with the issued access token;
• shall provide opaque non-guessable access tokens with a minimum of 128 bits as defined in section 5.1.4.2.2 of [RFC6819].
• should provide a mechanism for the end-user to revoke access tokens and refresh tokens granted to a Client as in 16.18 of [OIDC].
• shall support the authentication request as in Section 3.1.2.1 of [OIDC];
• 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 optional acr value in ID Token.

So to summarize, these are mostly best practices for implementing OIDC and OAuth 2 – just formalized. I am sure there will be also a certification process around that at some point.

Interesting to note is the requirement for PKCE and the removal of plain client secrets in favour of mutual TLS and client JWT assertions. IdentityServer supports all of the above requirements.

In contrast, the “Read and Write Profile” (currently a working draft) steps up security significantly by demanding proof of possession tokens via token binding, requiring signed authentication requests and encrypted identity tokens, and limiting the authentication flow to hybrid only. The current list from the draft:

• shall require the request or request_uri parameter to be passed as a JWS signed JWT as in clause 6 of OIDC;
• shall require the response_type values code id_token or code id_token token;
• shall return ID Token as a detached signature to the authorization response;
• shall include state hash, s_hash, in the ID Token to protect the state value;
• shall only issue holder of key authorization code, access token, and refresh token for write operations;
• shall support OAUTB or MTLS as a holder of key mechanism;
• shall support user authentication at LoA 3 or greater as defined in X.1254;
• shall support signed and encrypted ID Tokens

Both profiles also have increased security requirements for clients – which is subject of a future post.

In short – exciting times ahead and we are constantly improving IdentityServer to make it ready for these new scenarios. Feel free to get in touch if you are interested.