This section explains how Airlock protects interactions between the end-user, the TPP and the bank and shows how this can be achieved with the Airlock components.
Used OAuth abbreviations:
We use the following OAuth 2.0-related abbreviations to keep the texts more readable.
Abbreviation | Stands for |
|---|---|
AS* | OAuth 2.0 Authorization Server (Airlock IAM) |
Client* | OAuth 2.0 Client (the TPP) |
AT* | OAuth 2.0 Access Token |
RT* | OAuth 2.0 Refresh Token |
Authz Code Flow | OAuth 2.0 Authorization Code Flow |
Authz Code | OAuth 2.0 Authorization Code |
Client Creds Flow | OAuth 2.0 Client Credentials Flow |
Client ID | OAuth 2.0 Client Identifier |
OAuth 2 Usage in STET
STET makes use of the following OAuth 2.0 concepts:
- Dynamic Client Registration: for Client registration
- Client Creds Flow: to authorize the Client for payment-related calls (PISP)
- Authz Code Flow: to authorize the Client for account-related (AISP) and similar (e.g. CBPII) calls. This may involve the end-user for giving consent.
- OAuth 2.0 client authentication: the Client's OAuth 2.0 client(s) are authenticated using client certificates
The interactions can be classified in the following types. Details for each type can be found in the following sections.
Interaction | Description | Airlock Concepts |
|---|---|---|
STET uses OAuth 2.0 for TPP authentication and access delegation. Therefore, each TPP's OAuth client(s) must register using IAM's OAuth 2.0 client registration API in order to be able to use the bank's APIs. | OAuth 2.0 Dynamic Client Registration | |
All REST API calls from the TPP to the bank's REST services. Examples: Requests on REST resources /accounts, /payments, /consents, etc. | One-Shot Authentication Flow (HTTP request authentication) | |
The end-user communicates directly with the bank in order to give the consent, that a TPP may access the end-user's bank account(s). The bank authenticates the end-user and asks for the required consents. |
|