FAPI OAuth2 Authentication and Consent flow for UK Open Banking
© 2020 TESOBE GmbH
Customer
Third
Party
Provider
ASPSP
Authorization
Server
ASPSP
Internet
Banking
Site
ASPSP
Token
Endpoint
ASPSP
Resource
Server
Open
Banking
Directory
Token
Endpoint
Open
Banking
Directory
JWKS
FAPI Read/Write (Hybrid) Flow Overview
This diagram shows the end-to-end flow
expected when implementing the UK open
banking standards
Note that we'll use account info
as an example so the requested URLs are
meaningful
Part 1: Obtain Customer Consent
In the parlance of the UK standards consent
isn't consent until it's authorized - hence
the label "intent" is used
Indicate wish to share data
Display "Intent"
i.e. data to be accessed
or payment to be made
Confirm intent
Show bank selection screen
Confirm bank selection
Part 2: Create "Intent"
With the consent of the Consumer in the bag
the TPP can now call the Consent API at the
correct ASPSP.
Create Intent payload
Lookup Token endpoint
from well-known configuration
This request will be made using Mutual TLS with the eIDAS
QWAC or equivalent, pre-eIDAS OB WAC (I believe ASPSPs in the
UK are still accepting OB WACs).
Access Token request
Response
POST /account-access-consents
Response including
ConsentId
("Intent ID")
Part 3: Customer Redirected to Authorization Server
As exemplar the flow shows a web journey
but the mobile journey (app-to-app) still
implements Hybrid Flow -
this
is the guidance
from OBIE
FAPI mandates the use of the
Request object parameter
which is defined in
Section 6
of OpenID Connect Core.
This is a signed JSON Web Token where the payload contains
parameters normally found in the URL (redirect_uri, state, nonce, etc)
Create Request parameter
The Signing Key can realistically be a QWAC, QSEAL or OB equivalents.
The primary constraint is that the public certificate can be referenced
in the JSON Web Key Set maintained by the Directory i.e. the key ID
matches one of the TPPs JSON Web Keys.
Sign Request parameter with Signing Key
Create redirect URL including Request parameter
Redirect customer
Follow redirect
Obviously this is indicative - an ASPSP wouldn't
go to the Directory for the JSON Web Key Set every
time... or would they...
It isn't 100% clear from the documentation available
whether access to the JWKS is open, through MTLS
or Access Token. I would imagine it'd be a
Client Credentials Access Token as this would
follow other patterns.
Get Access Token
Response
Get JSON Web Key Set
Response
Match Request parameter
kid
Verify Request parameter signature
Note that this will include verifying the "Intent ID".
Obviously the Authorization Server will need a source
of truth for this, which I haven't drawn as it'll vary
across implementations.
Verify Request parameter properties
Part 4: Customer Authenticates and Authorizes Consent
The following steps aren't in the standards - other than the
Customer Experience guidelines - but is pretty typical i.e.
the "internet banking" site will be hosted at a different
domain to the Authorization Server - the user will therefore
need to be redirected. Some might serve an iframe from
within an Authorization Server webpage... it just depends
on the architecture of the ASPSP.
The Customer Experience guidelines on these steps can
be found
here
Redirect Customer
Follow Redirect
Verify redirect
Show login screen
Submit credentials
Verify credentials
Get "Intent" properties
Response
Show Account Selector and Consent
Send Account Selection
and Consent Authorization
Store Account IDs Customer consented to share
Update Consent to
Authorized
status
Response
Redirect Customer
Follow Redirect
Verify Redirect
Mint Authorization Code
and ID Token
Redirect Customer
Follow Redirect
Part 4: Swap Authorization Code for Access Token
Verify redirect including
ID Token signature, nonce and s_hash value
Get ID, Access and Refresh Tokens
Response
Part 5: Get Data from Account
Strictly speaking this is nothing to do
with FAPI Read/Write Flow but for the sake of completeness...
It should be noted that due to the adoption of
the Mutual TLS profile for OAuth 2.0 in FAPI
(here)
many ASPSP will bind Access Tokens to the client certificate
presented when they were created. This is indicated at the
well-known endpoint through by the value of the
tls_client_certificate_bound_access_tokens
property
GET /accounts
Response
loop
[For each authorized endpoint]
GET /{{Resource URI}}
Response
