The talk gives an introduction to the NextGenPSD2 OAuth SCA mode and explains security considerations implementors should take into account when implementing it. This advice will go beyond the text of the NextGenPSD2 Spec and will be based on the latest OAuth Security Guidelines (https://tools.ietf.org/html/draft-ietf-oauth-security-topics) and work being conducted at OpenID Foundations FAPI working group.

1. NextGenPSD2 OAuth SCA Mode
Security Recommendations
Torsten Lodderstedt
@tlodderstedt
yes®

2. OAuth 2.0
● Standard for API access authorization
● Current version 2.0 published in 2012, broadly used and mature
● Updated Security Guidlines under way
Design pattern:
● Separate authentication and authorization from actual API access
● Delegate user interactions to service provider
● User credentials are only touched by the service provider and no 3rd party
● Versatile, secure and, privacy preserving

3. ASPSPUser
AIS with OAuth SCA Mode - High Level
Create Account Access Consent
Use access_token for AIS
AISP
Consent-ID
User gives authorization for Account Access with Consent-ID
access_token
OAuth
Authorization
Code Grant
Start XS2A

4. Closer Look: OAuth SCA Mode
GET /authorize?scope=AIS:<Consent-ID>&...
Redirect to ASPSP
Redirect to aisp.com/authok?code=foo42&...
POST /token,
code=foo42...
Send code=foo42
Send access_token
ASPSPUser AISP
User gives authorization for account access (incl. SCA)

5. ASPSPUser
PIS with OAuth SCA Mode - High Level
Create Payment Resource
Use access_token
PISP
Payment-ID
User gives authorization for Payment with Payment-ID
access_token
OAuth
Authorization
Code Grant
Start Payment

6. User
What happens when?
Payment Initiation
ASPSP
Use access_token
PISP
Payment-ID
User gives authorization for Payment with Payment-ID
access_token
Start Payment
Payment authorized
& executed
Payment prepared
Potential attacks!

7. ASPSPAttacker
Cross-Browser Payment Initiation Attack
Payment Initiation
PISP
Payment-ID
User gives authorization for Payment with Payment-ID
Pay my order
Redirect to ASPSP
User
Redirect to ASPSP
Attacker disguises as a merchant.
User thinks she pays for her order at
the merchant, but instead pays for
the attacker’s order at PISP!
Attacker’s
Payment executed!
Pay my order
All details: https://cutt.ly/cross-browser-payment-initation

8. Security of OAuth
● Many security features of OAuth against CSRF, Replay, … come into play
after user authorization
● Security of OAuth lies in the access token
● Therefore, any subsequent process, including payment, should be performed
with the access token, not within the user authorization process

9. User
Better Solution!
Payment Initiation
ASPSP
Use access_token
PISP
Payment-ID
User gives authorization for Payment with Payment-ID
access_token
Start Payment
Payment authorized
Payment prepared
Payment executed

10. Security Threats

11. Security Threats needed to be coped with
● TPP Impersonation
● TPP Privilege Exceedance
● Open Redirection
● CSRF
● Authorization Code Replay
● Mix-Up
● Scope Swap
● Access Token Replay
More details can be found at https://tools.ietf.org/html/draft-ietf-oauth-security-
topics

12. Security Recommendations

13. Security Advice in Detail
GET /authorize?...
Redirect to ASPSP
Redirect to aisp.com/authok?...
POST /token
Send code=foo42
Send access_token
ASPSPUser PISP
User gives authorization for account access
Use access_token
Start
Create Payment Resource
Payment ID

14. Resource Creation
GET /authorize?...
Redirect to ASPSP
Redirect to aisp.com/authok?...
POST /token
Send code=foo42
Send access_token
ASPSPUser PISP
User gives authorization for account access
Use access_token
Start
Create Payment Resource
Payment ID

15. Resource Creation
● Mix-up attack* detection: TPP shall set up a redirect URI with the ASPSP
which uniquely identifies the ASPSP
Example: https://pisp.com/authok/aspsp2
*Mix-up attack: a malicious or compromised ASPSP confuses the TPP in order to learn an authorization code

16. Example Request
POST https://api.testbank.com/v1/payments/sepa-credit-transfers
Content-Type: application/json
TPP-Redirect-URI: https%3A%2F%2Fpisp%2Ecom%2Fauthok%2Faspsp2
{
"instructedAmount": {
"currency": "EUR",
"amount": "123"
},
"creditor": {
"name": "Merchant123"
},
"creditorAccount": {
"iban": "DE23100120020123456789"
},
...
}

17. Resource Creation (ASPSP)
● TPP Impersonation and Privileges Exceedance: ASPSP needs to
authentication TPP using eIDAS certificate and check TPP’s authorization to
perform desired services.

18. Example Response
HTTP/1.x 201 Created
Location: https://api.testbank.com/psd2/v1/payments/sepa-credit-transfers/1234-wertiq-983
Content-Type: application/json
{
"transactionStatus": "RCVD",
"paymentId": "1234-wertiq-983",
"_links": {
"scaOAuth": {
"href": "https://www.testbank.com/oauth/.well-known/oauth-authorization-server"
},
...
}
}
}

19. Example oauth-authorization-server
{
"issuer": "https://as.testbank.com",
"authorization_endpoint": "https://as.example.com/authorize",
"token_endpoint": "https://as.example.com/token",
"token_endpoint_auth_methods_supported": ["tls_client_auth",”self_signed_tls_client_auth”],
"scopes_supported": ["pis","ais","offline_access"],
"response_types_supported": ["code"],
"grant_types_supported": "authorization_code",
"code_challenge_methods_supported": "S256",
...
}

20. Authorization Request
GET /authorize?...
Redirect to ASPSP
Redirect to aisp.com/authok?...
POST /token
Send code=foo42
Send access_token
ASPSPUser PISP
User gives authorization for account access
Use access_token
Start
Create Payment Resource
Payment ID

21. Authorization Request
In preparation of sending the authorization request, the TPP shall
1. CSRF protection: Create a one-time use CSRF token to be conveyed to the
ASPSP in the “state” parameter
2. Code replay protection: Create a one-time use nonce, whose SHA-256
value will be conveyed to the ASPSP in the “code_challenge” parameter
3. Bind those values to the current session in the user agent
4. Mix-Up protection: Memorize in the current session the identity of the
ASPSP the request will be sent to

22. Example Request
GET /authorise?response_type=code&
client_id=PSDES%2DBDE%2D3DFD21&
scope=pis%3A1234-wertiq-983&
state=S8NJ7uqk5fY4EjNvP_G_FtyJu6pUsvH9jsYni9dMAJw&
redirect_uri=https%3A%2F%2Fpisp%2Ecom%2Fauthok%2Faspsp2&
code_challenge_method=S256&
code_challenge=E9Melhoa2OwvFrEMTJguCHaoeK1t8URWbuGJSstw-cM
HTTP/1.1
Host: as.testbank.com

23. Authorization Request
The ASPSP upon receiving this request must perform these checks:
● Open Redirection Prevention: “redirect_uri” value must exactly match the
value sent to the ASPSP with the request used to create the payment or
consent resource in the header “TPP-Redirect-URI”.
● Otherwise, the ASPSP must refuse to process the request and must not
redirect the user agent back to the TPP.

24. Authorization Response
GET /authorize?...
Redirect to ASPSP
Redirect to aisp.com/authok?...
POST /token
Send code=foo42
Send access_token
ASPSPUser PISP
User gives authorization for account access
Use access_token
Start
Create Payment Resource
Payment ID

25. Authorization Response
The TPP upon receiving this response shall perform the following checks:
1. Mix-Up detection: Redirect URI where the response was received must
match the ASPSP the response was expected to come from.
2. CSRF detection: The “state” value is linked to the current session in the user
agent.
If any of these check fails, the TPP must refuse to process the authorization
response.

26. Example Authorization Response
HTTP/1.1 302 Found
Location: https%3A%2F%2Fpisp%2Ecom%2Fauthok%2Faspsp2?
code=SplxlOBeZQQYbYS6WxSbIA&
state=S8NJ7uqk5fY4EjNvP_G_FtyJu6pUsvH9jsYni9dMAJw

27. Token Request
GET /authorize?...
Redirect to ASPSP
Redirect to aisp.com/authok?...
POST /token
Send code=foo42
Send access_token
ASPSPUser PISP
User gives authorization for account access
Use access_token
Start
Create Payment Resource
Payment ID

28. Token Request
The ASPSP upon receiving the request shall perform the following checks:
1. TPP impersonation detection: Authenticate TPP with eIDAS certificate
2. Code leakage and replay detection: Check that code is bound to the TPP
(client_id), is still valid, and was sent to exactly the redirect URI conveyed in
the “redirect_uri” request parameter.
3. Code injection detection: “code_verifier” value, when hashed with S256,
matches the “code_challenge” value the code parameter is bound to (see
[RFC7636], Section 4.6).
If any of these check fails, the ASPSP must refuse to process the token request.
See [RFC6749], Section 10 and [OAuth 2.0 Security BCP], Section 2.1

29. Example Token Request
POST /token HTTP/1.1
Host: https://api.testbank.com
Content-Type: application/x-www-form-urlencoded
client_id=PSDES-BDE-3DFD21
&grant_type=authorisation_code
&code=SplxlOBeZQQYbYS6WxSbIA
&redirect_uri=https%3A%2F%2Fpisp%2Ecom%2Fauthok%2Faspsp2
&code_verifier=dBjftJeZ4CVP-mB92K27uhbUJU1p1r_wW1gFWFOEjXk

30. Token Response
GET /authorize?...
Redirect to ASPSP
Redirect to aisp.com/authok?...
POST /token
Send code=foo42
Send access_token
ASPSPUser PISP
User gives authorization for account access
Use access_token
Start
Create Payment Resource
Payment ID

31. Token Response
● Access Token Replay Detection: ASPSP issues access token that is bound
to the TPP’s client certificate
● Scope swap prevention
○ ASPSP must return scope values assigned to the access token
○ Upon receiving the token response, the TPP must check whether the scope assigned to the
access token is the same as requested in the authorization request.
○ If this check fails, the TPP must refuse to process the token response

32. Example Token Response
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,
"scope": "pis:1234-wertiq-983"
}

33. API Requests
GET /authorize?...
Redirect to ASPSP
Redirect to aisp.com/authok?...
POST /token
Send code=foo42
Send access_token
ASPSPUser PISP
User gives authorization for account access
Use access_token
Start
Create Payment Resource
Payment ID

34. API Requests
● Access Token Replay Detection
○ On every API request, the TPP shall authenticate using TLS client authentication and its
eIDAS certificate according to [mTLS], Section 3.
○ The resource server must check whether the certificate used for TLS Client Authentication
matches the certificate the access token is bound to (see [mTLS], Section 3).
● Authorization: The ASPSP must also check that the access token is still
valid and whether the permission associated with the access token entitles
the TPP to perform the specific request.
● If any of these checks fails, the request must be refused by responding with a
suitable HTTP Status code.

35. Security Recommendations (Overview)
● Adhere to OAuth 2.0 Security Best Current Practice
(https://tools.ietf.org/html/draft-ietf-oauth-security-topics)
● TPP authentication and access token replay protection using OAuth 2.0
Mutual TLS Client Authentication and Certificate Bound Access Tokens
● Protection against code injection through Proof Key for Code Exchange
● Protection against CSRF using session-bound state parameter values
● Protection against Mix-Up attacks using session bound ASPSP specific
redirect URIs
● Protection against session-fixation type of attacks by utilizing OAuth grant
flow as designed

36. Q&A!
Latest Drafts & Publications
OAuth 2.0 Security Best Current Practice
https://tools.ietf.org/html/draft-ietf-oauth-security-topics
OAuth 2.0 Pushed Authorization Requests (PAR)
https://cutt.ly/oauth-transaction-authorization
OAuth 2.0 Rich Authorization Requests (RAR)
https://openid.net/specs/openid-financial-api-jarm-ID1.html
JWT Secured Authorization Response Mode for OAuth 2.0 (JARM)
https://tools.ietf.org/html/draft-fett-oauth-dpop
Cross-Browser Payment Initiation Attack
https://cutt.ly/cross-browser-payment-initation
OpenID Connect 4 Identity Assurance
https://openid.net/specs/openid-connect-4-identity-assurance.html
Dr. Torsten Lodderstedt
CTO, yes.com
torsten@yes.com
@tlodderstedt
yes®
Talk to me about
- Details on OAuth Security Best Practices
- The OAuth Security Workshop
- Other emerging OAuth & OpenID stuff
- Partnering with and working at yes.com

37. Mix-Up Attack

38. Mix-Up Attack
GET /authorize...
ASPSPPISPUser
Forward
Redirect to ASPSP1
2
ASPSP
1
Redirect to aisp.com/authok?code=42&...
GET /authok?code=42&...
User gives authorization for account access
POST /token,
code=42...
Attacker learns code!

39. Mitigation
GET /authorize...
Redirect to aisp.com/authok?aspsp=2&code=42&...
GET /authok?aspsp=2&code=...
ASPSPPISP
User gives authorization for account access
User
Redirect to ASPSP1
2
ASPSP
1
PISP can detect attack here!
Mismatch between intended ASPSP (1) and
ASPSP identity in the redirect URI (2)
1
Uses unique redirect URI for each ASPSP, e.g.,
by encoding ASPSP ID into URI parameter.
Forward
2