MagNet NextGen PSD2 OAUTH 2 specification



Last modifier person

Last modification date


Specifying the beta version of our Oauth 2 authentication and authorisation layer

Gábor Csillag



Signing basket authorisation

Gábor Csillag



Token refresh function removal

Gábor Csillag


1. Introduction

This document contains a detailed specification about MagNet NextGen PSD2 authentication and authorisation service.

Our authentication and authorisation layer based on Oauth 2 with some Berlin Group specialisations.

Our applied oauth 2 configuration:

- Flow: authorization code flow. (Using any other flow is forbidden!)

- Client registration is not neccessary. (We use PKCE extension instead of client registration mechanism.)

- Using of the client-id and scope attributes are defined in the Berlin Group NextGenPsd2 specifiaction. (See below.)

Basic OAUTH 2 RFC can be found here:

Basic bearer (access) token usage RFC can be found here:

Our detailed Oauth 2 extensions and its detailed specifications with documentation URL:



Documentation URL

Berlin Group NextGenPsd principles

This specifies the usage of OAUTH 2 client-id and scope attributes in order to the ASPSP can link the access (bearer) token to the created payment initation or consent resource.

- Implementation Guidelines

- Operation rules

Oauth 2 PKCE extension

OAuth 2.0 public clients utilizing the Authorization Code Grant are

susceptible to the authorization code interception attack. This

specification describes the attack as well as a technique to mitigate

against the threat through the use of Proof Key for Code Exchange

(PKCE, pronounced "pixy").

2. Using MagNet Oauth2 authentication and authorisation layer

The following steps required to obtain access (bearer) token.

  1. The client first creates a random string (between 43 and 128 characters) known as „code verifier”. Then using the SHA256 algorithm it calculates the „code challenge” value.

    Code challenge = SHA256(code verifier)

  2. The client posts an authorisation request by any of the following urls:

Param name

Param Description

External reference


Always „code”

RFC 6749:


Unique TPP identifier

Berlin Group – Implementation Guidelines – chapter 13.


Value AIS/PIS/SBS. We allow using a single AIS/PIS/SBS scope without any {payment_id}/{consent_id}/{basket_id}. In this case you must use consent_id query param or payment_id query param or signing_basket_id query param in order to determine which consent/payment/signing basket resource you want to authenticate.



An opaque value used by the client to maintain

state between the request and callback. The authorization

server includes this value when redirecting the user-agent back

to the client.

RFC 6749:


An URI to redirect the client in order to successful user identification.

RFC 6749:


PKCE code challange method. Its value must be s256; plain value is forbidden.

RFC 7636:


The result of:

SHA256(code verifier)

RFC 7636:


Unique identifier of a consent/payment initiation/signing basket resource posted before.

Berlin Group – Implementation Guidelines

3. Authorisation response:

The authorisation response of the ASPSP to the TPP will deliver the following data:

- code: authorisation code generated by ASPSP

- state: same state value as for the request

4. Token request:

The TPP send a POST request to the token endpoint in order to exchange authorisation code provided in the authorisation response.

Token request endpoint URL template:

Param name

Param Description

External reference


Always „authorisationCode”

RFC 6749:


Unique TPP identifier

Berlin Group – Implementation Guidelines – chapter 13.


An URI to redirect the client in order to successful user identification.

RFC 6749:


The code_verifier value generated at step 0.

RFC 7636:

5. Token response:

The ASPSPS responds with the following parameters:




Access Token bound to the scope as requested in the authorisation request and confirmed by the PSU


Always „Bearer”


Expiration time in seconds.


Refresh Token, which can be utilised to obtain a fresh access tokens in case the previous access token expired or was revoked. Especially useful in the context of AIS.

(Token refresh endpoint has been removed!)


the scope of the access token.

  • AIS:{consent_id}

  • PIS:{payment_id}

  • SBS:{basket_id}


HTTP/1.1 200 OK

Content-Type: application/json

Cache-Control: no-store

Pragma: no-cache





"refresh_token": "tGzv3JokF0XG5Qx2TlKWIA",

"scope": "AIS:1234"


You can use the access token as a bearer token authorisation. See RFC 6750.

4. MagNet NetxtGen PSD2 endpoints:

The following table contains all OAUTH2 specific endpoints.



URL template

Authorisation request endpoint

First step for obtaining access (bearer) token


Token request endpoint

For obtaining access token using authorisation code given by authorisation response.


Token configuration desriptor endpoint


Token revokation endpoint


Token revokation endpoint. It revokes the given bearer token. After revokation this token cannot be renewed.