MagNet NextGen PSD2 OAUTH 2 specification
Version |
Description |
Last modifier person |
Last modification date |
---|---|---|---|
1.0 |
Specifying the beta version of our Oauth 2 authentication and authorisation layer |
Gábor Csillag |
2019.03.14. |
1.1 |
Signing basket authorisation |
Gábor Csillag |
2019.07.24. |
1.2 |
Token refresh function removal |
Gábor Csillag |
2019.08.28. |
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:
https://tools.ietf.org/html/rfc6749
Basic bearer (access) token usage RFC can be found here:
https://tools.ietf.org/html/rfc6750
Our detailed Oauth 2 extensions and its detailed specifications with documentation URL:
Extension |
Description |
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. |
https://www.berlin-group.org/nextgenpsd2-downloads
- 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"). |
https://tools.ietf.org/html/rfc7636
|
The following steps required to obtain access (bearer) token.
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)
The client posts an authorisation request by any of the following urls:
{proto}://{host:port}/NetBankOAuth/psd2-authorize.xhtml?response_type=code&client_id={client-id}&scope=AIS&state={state}&redirect_uri={redirect-uri}&code_challenge_method=S256&code_challenge={code-challenge}&consent_id={consent-id}
{proto}://{host:port}/NetBankOAuth/psd2-authorize.xhtml?response_type=code&client_id={client-id}&scope=PIS&state={state}&redirect_uri={redirect-uri}&code_challenge_method=S256&code_challenge={code-challenge}&payment_id={payment-id}
{proto}://{host:port}/NetBankOAuth/psd2-authorize.xhtml?response_type=code&client_id={client-id}&scope=SBS&state={state}&redirect_uri={redirect-uri}&code_challenge_method=S256&code_challenge={code-challenge}&signing_basket_id={basket-id}
{proto}://{host:port}/NetBankOAuth/psd2-authorize.xhtml?response_type=code&client_id={client-id}&scope=AIS:{consent-id}&state={state}&redirect_uri={redirect-uri}&code_challenge_method=S256&code_challenge={code-challenge}
{proto}://{host:port}/NetBankOAuth/psd2-authorize.xhtml?response_type=code&client_id={client-id}&scope=PIS:{payment-id}&state={state}&redirect_uri={redirect-uri}&code_challenge_method=S256&code_challenge={code-challenge}
{proto}://{host:port}/NetBankOAuth/psd2-authorize.xhtml?response_type=code&client_id={client-id}&scope=SBS:{basket-id}&state={state}&redirect_uri={redirect-uri}&code_challenge_method=S256&code_challenge={code-challenge}
Param name |
Param Description |
External reference |
response_type |
Always „code” |
RFC 6749: |
client_id |
Unique TPP identifier |
Berlin Group – Implementation Guidelines – chapter 13. |
scope |
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. |
- |
state |
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: https://tools.ietf.org/html/rfc6749#section-4.1.1
|
redirect_uri |
An URI to redirect the client in order to successful user identification. |
RFC 6749: |
code_challenge_method |
PKCE code challange method. Its value must be s256; plain value is forbidden. |
RFC 7636: |
code_challenge |
The result of: SHA256(code verifier) |
RFC 7636: |
consent_id/payment_id/signing_basket_id |
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:
{proto}://{host:port}/NetBankOAuth/psd2/token?grant_type=authorisationCode&code={authorisation_code}&client_id={client_id}&redirect_uri={redirect_uri}&code_verifier={code_verifier}
{proto}://{hosT:port}/NetBankOAuth/psd2/token
In
this case the neccessery params are to send in http body with
application/x-www-form-urlencoded HTTP content type.
Example:
POST
/token HTTP/1.1
Host: https://api.testbank.com
Content-Type:
application/x-www-form-urlencoded
client_id="PSDES-BDE-3DFD21"
&grant_type=authorisationCode
&code=SplxlOBeZQQYbYS6WxSbIA
&redirect_uri=
https%3A%2F%2Fclient%2Eexample%2Ecom%2Fcb
&code_verifier=7814hj4hjai87qqhjz9hahdeu9qu771367647864676787878
Param name |
Param Description |
External reference |
grant_type |
Always „authorisationCode” |
RFC 6749: |
client_id |
Unique TPP identifier |
Berlin Group – Implementation Guidelines – chapter 13. |
redirect_uri |
An URI to redirect the client in order to successful user identification. |
RFC 6749: |
code_verifier |
The code_verifier value generated at step 0. |
RFC 7636: |
5. Token response:
The ASPSPS responds with the following parameters:
Attribute |
Description |
access_token |
Access Token bound to the scope as requested in the authorisation request and confirmed by the PSU |
token_type |
Always „Bearer” |
expires_in |
Expiration time in seconds. |
refresh_token |
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!) |
scope |
the scope of the access token.
|
Example:
HTTP/1.1
200 OK
Content-Type:
application/json
Cache-Control:
no-store
Pragma:
no-cache
{
"access_token":"SlAV32hkKG",
"token_type":"Bearer",
"expires_in":3600,
"refresh_token":
"tGzv3JokF0XG5Qx2TlKWIA",
"scope":
"AIS:1234"
}
You can use the access token as a bearer token authorisation. See RFC 6750.
https://tools.ietf.org/html/rfc6750
The following table contains all OAUTH2 specific endpoints.
Endpoint |
Description |
URL template |
Authorisation request endpoint |
First step for obtaining access (bearer) token |
{proto}://{host:port}/NetBankOAuth/psd2-authorize.xhtml |
Token request endpoint |
For obtaining access token using authorisation code given by authorisation response. |
{proto}://{host:port}/NetBankOAuth/psd2/token |
Token configuration desriptor endpoint |
|
{proto}://{host:port}/NetBankOAuth/psd2/.well-known/oauth-authorization-server |
Token revokation endpoint |
{proto}://{host:port}/NetBankOAuth/psd2/token/revoke |
Token revokation endpoint. It revokes the given bearer token. After revokation this token cannot be renewed. |