The document discusses security recommendations for OAuth SCA mode authentication in PSD2 open banking. It recommends adhering to OAuth 2.0 security best practices and using mutual TLS client authentication and certificate bound access tokens to protect against replay and authentication attacks. It also recommends measures like CSRF tokens, nonce values, and checking redirect URIs to prevent attacks like cross-site request forgery, code injection, mix-up attacks, and session fixation. Detailed checks and validations are described to secure the authorization request, response, token request and API requests in the OAuth flow.

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 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

11. Security Recommendations in Detail

12. 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 Consent
Consent ID

13. 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 Consent
Consent ID

14. Resource Creation
● Mix-up attack* detection: TPP shall set up a redirect URI with the ASPSP
which uniquely identifies the ASPSP
Example: https://aisp.com/authok?aspsp=2
● ASPSP needs to authentication TPP using eIDAS certificate and check TPP’s
authorization to perform desired services
*Mix-up attack: a malicious or compromised ASPSP confuses the TPP in order to learn an authorization code

15. 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 Consent
Consent ID

16. 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-265
value will be conveyed to the ASPSP in the “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

17. Authorization Request
The ASPSP upon receiving this request must perform these checks:
● TPP impersonation detection: “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.

18. 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 Consent
Consent ID

19. 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.

20. 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 Consent
Consent ID

21. 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 was sent to exactly
the redirect URI conveyed in the “redirect_uri” request parameter, is still valid,
and is bound to the TPP.
3. Code injection detection: “verifier” value, when hashed, matches the
“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

22. 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 Consent
Consent ID

23. Token Response (Scope swap detection)
● 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.

24. 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 Consent
Consent ID

25. API Requests (access token replay detection)
● On every API request, the TPP shall be authenticated 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).
● 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.

26. Q&A!
Latest Drafts & Publications
OAuth 2.0 Security Best Current Pracice
https://tools.ietf.org/html/draft-ietf-oauth-security-topics
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
Transaction Authorization or why we need to re-think OAuth scopes
https://cutt.ly/oauth-transaction-authorization
JWT Secured Authorization Response Mode for OAuth 2.0 (JARM)
https://openid.net/specs/openid-financial-api-jarm-ID1.html
OAuth 2.0 Demonstration of Proof-of-Possession at the Application Layer
https://tools.ietf.org/html/draft-fett-oauth-dpop
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

27. Mix-Up Attack

28. 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!

29. 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