Authorization Code Grant and remote consent setup

To configure the Authorization Code Grant for STET, go to the authorization server settings in Loginapp >> OAuth 2.0/OIDC Authorization Servers >> <some AS> >> OAuth 2.0 Grants/OIDC Flows and add an OAuth 2.0 Authorization Code Grant plugin.

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 using 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 a call-back (as seen from the browser) and not an internal URL.
    3. Airlock Gateway Role for Remote Consent Site: we strongly recommend protecting the bank's consent application with a Gatewayrole. In the description of the Airlock Gateway configuration, we used "psd2_consent" as an 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.