In the following, we illustrate the interaction between the end-user, the TPP and the bank when asking the end-user for a consent within an Authz Code Flow.
The consent step is initiated by the TPP after the TPP finds out, that a user consent is required (e.g. in AISP but no valid RT* is available).
Note that this interaction is identical to the standard Authz Code Flow with the TPP being the OAuth Client and IAM being the OAuth Authorization Server (AS).
When asking for the user consent, IAM hands over control to the bank's consent application, because the consent step involves banking specific information (see also Remote consent applications with OAuth).
Step | Name | Component | Description |
|---|---|---|---|
1 | Process Authz Code Request | IAM | IAM's AS* (OAuth 2 Authorization Server) processes the request from the TPP (forwarded to IAM via the PSU's browser). The AS checks the requested scopes, requested token type and more. |
2 | Check if PSU is authenticated | IAM | Check if the PSU (end-user) is authenticated and has enough roles to proceed. If not start the interactive authentication process. |
3 | Interactive Login Process | IAM | If required, IAM authenticates the end-user interactively. This is typically done by responding with "login page" to check username and password but is generally open for any other type of authentication. Note that the 2nd authentication factor (SCA) is typically not part of this authentication process: it will be triggered by the bank's consent application in a later step only if necessary. |
4 | Start Remote Consent | IAM | After successful authentication, IAM starts the "remote consent" protocol: it redirects the browser to the bank's consent application and prepares a JWT bearing the required information to do so. The bank's consent application is protected by a Airlock Gateway (WAF) role. |
5 | Store Role | Airlock Gateway (WAF) | The Airlock Gateway (WAF) stores the role received by IAM and required to access the bank's consent application in the session store. It is used for access control in the next request. |
6 | Access Control and Filtering | Airlock Gateway (WAF) | Filter request to bank's consent application and do access control (ensure role). |
- | Remote Consent | Bank's Consent Application | The bank's consent application can now interact with the PSU (end-user) in order to get a consent. It confirms (or declines) the consent back to IAM by sending back another JWT token. See also Remote consent applications with OAuth. |
7 | Verify Consent JWT | IAM | Verify the consent JWT received from the bank's consent application. If no consent has been given, the process is aborted at this point. |
8 | Generate Authz Code and store in DB | IAM | Generate Authz Code and store it in the OAuth 2 session database. |
9 | Issue Authz Code | IAM | Send Authz Code back to TPP (using a HTTP redirect via the PSU's browser). |
10 | Verify Client Certificate and Client ID | IAM | After the TPP received the Authz Code, it will send it to IAM in order to get an AT* and RT*. IAM verifies the TPP's client certificate, its Client ID and the Authz Code. |
11 | Issue AT* and RT* | IAM | IAM issues an AT* and RT* and sends it back to the TPP. |