STET interaction models

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.


Stands for


OAuth 2.0 Authorization Server (Airlock IAM)


OAuth 2.0 Client (the TPP)


OAuth 2.0 Access Token


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.



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.

  • OAuth 2.0 Authorization Code Flow
  • Remote Consent