Authorization Code Grant and remote consent setup (in OAuth 2.0 settings)

To configure the "Authorization Code Grant" for STET, add the plugin "OAuth 2.0 Authorization Code Grant" in the "OAuth 2.0 Settings".

Configure it as follows:

  1. As "Consent" use the plugin "OAuth 2.0 Remote Consent" with the following configuration (see also Remote consent applications with OAuth):
    1. Request Settings:
      1. must be configured in accordance with the bank's consent application.
      2. for security reasons we recommend to use asymmetric signing algorithms (EC or RSA)
    2. Response Settings: 
      1. must be configured in accordance with the bank's consent application. 
      2. Make sure to use the external URL as call-back (as seen from the browser) and not an internal URL.
    3. Airlock Gateway (WAF) Role for Remote Consent Site: we strongly recommend to protect the bank's consent application with a Gateway (WAF)role. In the description of the Airlock Gateway configuration, we used "psd2_consent" as example.
  2. Use the following plugins in the list of "Granted Scope Processors":
    1. Plugin "OAuth 2.0 Granted Scope Whitelist" with allowed scopes: "aisp", "extended_transaction_history", "cbpii" (the scope "pisp" is only used in the client credentials grant and therefore not in this list)
    2. Plugin "STET PSD2 OAuth 2.0 Scope Filter" (no detail configuration necessary)
  3. Access- and Refresh Token Validity: Choose sensitive values considering the following points.
    • STET specifies that the scope "extended_transaction_history" is not "re-granted" on token refresh. 
    • This implies that the scope is lost for the user when refreshing the first time. 
    • This may be a reason to increase the access token validity. 
    • Note that STET specifies that the scope "extended_transaction_history" must not be granted for more than 90 days (STET specification at the time this documentation was written)

      • Note that valid access tokens are accepted even if the corresponding technical client is locked on the database. Increasing the access token validity thus implies that technical client locking becomes effective later.

  4. For all other properties, the default values should be ok.