Token Service Berlin Group v1.3 - SMBC Group v1.0.2

About this service

SMBC Group uses three main types of OAuth2 tokens:

1. TPP Access Token: Used by the TPP to interact with the consents service to:

• create a consents resource that the payment service user (PSU) must authorise; and
• retrieve the status of a consents resource
• delete an existing consents resource.

Also used by the TPP to interact with this service to exchange the PSU's authorisation code for a PSU access token this service (both described below). This TPP access token service adopts the OAuth2 client credentials grant flow.

2. PSU Access Token: Used by the TPP to access protected account information and payment services on behalf of the PSU.

This PSU access token service adopts the OAuth2 authorisation code grant flow and is supported by use of a delegated web service at a OAuth2 authorisation endpoint whereby, following strong customer authentication (SCA), the authorisation service provides the PSU with an authorisation code which explicitly authorises the TPP to access payment services on its behalf.

3. Refresh Token: Used by the TPP to renew the PSU access token when it periodically expires. Refresh tokens are not issued for TPP access tokens since the OAuth v2 client credentials grant suffices to obtain a new TPP access token.

To enhance security over the authorisation code flow, the Bank also implements proof key for (authorisation) code exchange (PKCE) on top of the standard OAuth2 authorisation code flow.

Authorisation Codes - Production versus Sandbox

In the production environment, the SMBC Group authorisation service issues the authorisation code to the PSU following SCA against an online web portal that is capable of receiving and issuing HTTP redirection requests.

In the sandbox environment we simulate this authentication step using a dedicated authorisation service, exclusive to the sandbox, which responds to PSU authorisation code requests. The sandbox authorisation service:

• does not require PSU authentication credentials;
• requires adherence to the semantics of the authorisation request operation in the OAuth2 specification; and
• accepts one of the consents pre-configured in our sandbox dataset.

The query parameters required for authorisation code requests are as follows:

• response_type=code
• client_id=<TPP Client ID>
• scope=<Consent ID returned in POST /consents>
• state=<unique opaque value used to maintain state between authorisation code request and callback>
• redirect_uri=<TPP Redirect URI>
• code_challenge=<PKCE SHA256 hashed value of a unique code_verifier generated by you, the TPP>
• code_challenge_method=S256