OAuth2.0

When PSU (Payment Service User) authorisation is required, OAuth2.0 redirect flow is used. The TPP redirects the user to the BNG Bank OAuth2.0 endpoint by using the following URI structure (line breaks are to clarify the example, the actual redirect URI should not contain line breaks).

https://web.xs2a-sandbox.bngbank.nl/authorise?response_type=code&
	client_id=client_id&
	state=state&
	scope=scope&
	code_challenge=code_challenge&
	code_challenge_method=code_challenge_method&
	redirect_uri=redirect_uri

Parameter	Description
response_type	Must contain the value "code" since implicit grant is not supported.
client_id	The client as present in the TLS certificate used to perform the original action (for example, initiate the payment). When using the Sandbox TLS certificate, the value for client_id should be "PSDNL-AUT-SANDBOX"
scope	The combination of the scope and scope identifier. For example, when creating a OAuth2.0 redirect url for a payment initiation, the scope could look like this "PIS:ec48fa69-1e09-4b0f-9ef7-76159e196356". In this example "PIS" (Payment Initiation Service) is the scope and "ec48fa69-1e09-4b0f-9ef7-76159e196356" is the id of the payment created by the payment initiation service.
state	This is a random value that can be sent in a redirect to the authorisation endpoint. When a redirect is done back to the TPP using the Redirect URL, the same state value is returned. This can be useful for the TPP, to keep track of some state, e.g. a reference to an action for which this redirect was performed.
code_challenge	This is a value that is send in a redirect to the authorization endpoint. Where it will be stored with the authorization code if the operation was successful. This same code verifier also has to be send when exchanging an authorization code for an access token. They have to match.
code_challenge_method	A code challenge method determines how the code verifier is send in a redirect to the authorization endpoint. If plain is chosen, the code verifier is sent as is. If S256 is used, the code verifier is hashed using SHA-256 and this hash is send to the authorization endpoint. In the request for exchanging an authorization code for an access token, the code verifier always has to be sent in plain. When the code challenge method S256 is chosen, the code verifier sent in plain is hashed using SHA-256 and compared against the hashed code verifier send in the redirect to the authorization endpoint. S256 provides an extra security layer, because in the redirect to the authorization endpoint, the code verifier is visible as query parameter. When using plain, the same code verifier could be used to retrieve the access token. When using S256, you have to know the code verifier value that was hashed with SHA-256.
redirect_uri	This is the URL that is send in the redirect to the authorisation endpoint as a query parameter. When the action at the authorisation endpoint succeeds, it uses this redirect URL to return the user back to the TPP including an authorization code.

In OAuth2 an authorisation code is given when a user allows a third party to access resources of the user. For allowing the TPP to access payment details and status of a user, the TPP redirects the user to the OAuth2 authorisation endpoint. The PSU can review the information at the authorisation endpoint (also known as the XS2A Confirmation Site). E.g. the PSU can review, save and confirm a payment or an account information consent. After this is done by the PSU, an authorisation code is generated and send back to TPP, by redirecting the PSU back to the TPP.