apidays Paris 2022 - Securing APIs in Open Banking, Takashi Norimatsu, Hitachi

December 14, 15 & 16, 2022

Securing APIs in Open Banking - FAPI and its implementation to OSS
Takashi Norimatsu, Senior Engineer at Hitachi, Ltd.
------

Check out our conferences at https://www.apidays.global/

Do you want to sponsor or talk at one of our conferences?
https://apidays.typeform.com/to/ILJeAaV8

Learn more on APIscene, the global media made by the community for the community:
https://www.apiscene.io

Explore the API ecosystem with the API Landscape:
https://apilandscape.apiscene.io/

Deep dive into the API industry with our reports:
https://www.apidays.global/industry-reports/

Subscribe to our global newsletter:
https://apidays.typeform.com/to/i1MPEW

Transcript

1. © Hitachi, Ltd. 2022. All rights reserved. Securing APIs in Open Banking - Financial-grade API security profile implementation to open-source software APIdays Paris 2022@Cité des sciences et de l’industrie, Paris, France Hitachi, Ltd. Architecture Design Center, Software & Service Development Division 15 December 2022 Takashi Norimatsu
2. 2023 SERIES OF EVENT New York May 16&17 Australia October 11&12 Singapore April 12&13 Helsinki & North June 5&6 Paris SEPTEMBER London November 15&16 June 28-30 SILICON VALLEY March 14&15 Dubai & Middle East February 22&23
3. 1 © Hitachi, Ltd. 2022. All rights reserved. Self Introduction  providing support services about OSS.  implementing and contributing promising features to keycloak.  W3C Web Authentication API support  Security features support (e.g., secure signature, sender constrained token)  API security profiles support (e.g., Financial-grade API Security Profiles) Takashi Norimatsu (tnorimat in github) : Keycloak maintainer, Senior Engineer, Architecture Design Center, Hitachi, Ltd., Japan * keycloak : The Identity and Access Management (IAM) OSS.
4. 2 © Hitachi, Ltd. 2022. All rights reserved. Contents • What is Open Banking using OAuth 2.0? • How can we access APIs of Open Banking securely? - applying Financial-grade API (FAPI) security profile • Which Open Banking applies FAPI in the real world? • How does FAPI secure API access? • Which open-source software implements FAPI security profiles? - Keycloak • How does keycloak support FAPI security profiles?
5. 3 © Hitachi, Ltd. 2022. All rights reserved. What is Open Banking using OAuth 2.0?
6. 4 © Hitachi, Ltd. 2022. All rights reserved. Open Banking using OAuth 2.0 Financial Service Provider (ASPSP) 3rd Party (TPP) 1. Initiate payment 2. Authz request 3. Authentication(AuthN) & Authorization(AuthZ) request 4. AuthN & AuthZ response 6. Access API w/ access token API Server Authorization Server 5. Issue an access token Client application Access Token End User Only OAuth 2.0 is not enough to secure access to APIs. Applying OAuth 2.0 based “Security Profile” • Using APIs for providing financial services. • Using OAuth 2.0 for accessing APIs securely.
7. 5 © Hitachi, Ltd. 2022. All rights reserved. How can we access APIs of Open Banking securely? - applying Financial-grade API (FAPI) security profile
8. 6 © Hitachi, Ltd. 2022. All rights reserved. Financial-grade API (FAPI) security profiles Financial-grade API (FAPI): OAuth 2.0 based security profile standardized by OpenID Foundation* for securing APIs that requires high security level (e.g., providing financial services). • Financial-grade API Security Profile 1.0 - Part 1: Baseline • Financial-grade API Security Profile 1.0 - Part 2: Advanced • Financial-grade API: JWT Secured Authorization Response Mode for OAuth 2.0 (JARM) • Financial-grade API: Client Initiated Backchannel Authentication Profile (FAPI-CIBA) • FAPI 2.0 Security Profile * The organization for standardizing specifications (e.g., OpenID Connect) in the area of digital identity Final Final
9. 7 © Hitachi, Ltd. 2022. All rights reserved. Security analysis of FAPI security profiles [Specification] A Comprehensive Formal Security Analysis of OAuth 2.0 (https://arxiv.org/abs/1601.01229) An Extensive Formal Security Analysis of the OpenID Financial-grade API (https://arxiv.org/abs/1901.11520) [Implementation] Conformance Suite (https://www.certification.openid.net/login.html) (https://gitlab.com/openid/conformance-suite) Certificate Program (https://openid.net/certification/#FAPI_OPs)
10. 8 © Hitachi, Ltd. 2022. All rights reserved. Which Open Banking applies FAPI in the real world?
11. 9 © Hitachi, Ltd. 2022. All rights reserved. Open banking using FAPI Security Profile [UK : OpenBanking] - OpenBanking Financial Grade API (FAPI) Profile - OpenBanking CIBA Profile [Australia : Consumer Data Right (CDR)] - Consumer Data Right Security Profile [Brazil : Open Banking Brasil] - Open Banking/Finance Brasil Financial-grade API Security Profile
12. 10 © Hitachi, Ltd. 2022. All rights reserved. How does FAPI secure API access?
13. 11 © Hitachi, Ltd. 2022. All rights reserved. OAuth 2.0 for API access 1. Authz Code Request User/Browser Client App Authz Server API Server 2. User Authentication (User Consent) 3. Authz Code Response 5. API Access 4. Token Request/Response (Client Authentication) redirect redirect authz code access token authz code access token OAuth 2.0 Authorization Code Flow
14. 12 © Hitachi, Ltd. 2022. All rights reserved. Problem 1: front-channel communication 1. Authz Code Request User/Browser Client App Authz Server API Server 2. User Authentication (User Consent) 3. Authz Code Response 5. API Access 4. Token Request/Response (Client Authentication) redirect redirect authz code access token authz code access token OAuth 2.0 Authorization Code Flow Front-channel communication: An authorization request is sent from a client to an authorization server via a user’s browser
15. 13 © Hitachi, Ltd. 2022. All rights reserved. Problem 1: front-channel communication 1. Authz Code Request User/Browser Client App Authz Server API Server 2. User Authentication (User Consent) 3. Authz Code Response 5. API Access 4. Token Request/Response (Client Authentication) redirect redirect authz code access token authz code access token OAuth 2.0 Authorization Code Flow Front-channel communication: An authorization request is sent from a client to an authorization server via a user’s browser ⇒ relatively easy to tamper or forge the request compared with back-channel communication directly.
16. 14 © Hitachi, Ltd. 2022. All rights reserved. Solution 1: message integrity and authentication 1. Authz Code Request User/Browser Client App Authz Server API Server 2. User Authentication (User Consent) 3. Authz Code Response 5. API Access 4. Token Request/Response (Client Authentication) redirect redirect authz code access token authz code access token OAuth 2.0 Authorization Code Flow Front-channel communication: An authorization request is sent from a client to an authorization server via a user’s browser ⇒ relatively easy to tamper or forge the request compared with back-channel communication directly. ⇒ use digital signature for message integrity and authentication
17. 15 © Hitachi, Ltd. 2022. All rights reserved. Solution 1: message integrity and authentication Request Object := JWT including parameters Client App wants to tell to Authz Server. It can be signed. (e.g., for non-repudiation, confirming who send the request) Optionally, it can be encrypted. (e.g., for end-to-end encryption) User/Browser Client App Authz Server redirect Sign it by client app’s private key. Verify it by client app’s public key. 1. Authz Code Request request object [Specifications] - RFC 9101 The OAuth 2.0 Authorization Framework: JWT-Secured Authorization Request (JAR) - OpenID Connect Core 1.0: 6. Passing Request Parameters as JWTs
18. 16 © Hitachi, Ltd. 2022. All rights reserved. Solution 2: avoiding front-channel communication 1. Authz Code Request User/Browser Client App Authz Server API Server 2. User Authentication (User Consent) 3. Authz Code Response 5. API Access 4. Token Request/Response (Client Authentication) redirect redirect authz code access token authz code access token OAuth 2.0 Authorization Code Flow Front-channel communication: An authorization request is sent from a client to an authorization server via a user’s browser ⇒ relatively easy to tamper or forge the request compared with back-channel communication directly. ⇒ send a content of the request directly from a client to an authorization server
19. 17 © Hitachi, Ltd. 2022. All rights reserved. Solution 2: avoiding front-channel communication Pushed Authorization Request (PAR) := an authorization request sent from Client App to Authz Server in advance before starting an authorization code flow. It can be signed. (e.g., for non-repudiation, confirming who send the request) Optionally, it can be encrypted. (e.g., for end-to-end encryption) User/Browser Client App Authz Server redirect 1. Authz Code Request [Specifications] - RFC 9126 OAuth 2.0 Pushed Authorization Requests request fetch store reference reference
20. 18 © Hitachi, Ltd. 2022. All rights reserved. Problem 2: front-channel communication (again) 1. Authz Code Request User/Browser Client App Authz Server API Server 2. User Authentication (User Consent) 3. Authz Code Response 5. API Access 4. Token Request/Response (Client Authentication) redirect redirect authz code access token authz code access token OAuth 2.0 Authorization Code Flow Front-channel communication: An authorization response is sent from an authorization server to a client via a user’s browser
21. 19 © Hitachi, Ltd. 2022. All rights reserved. Problem 2: front-channel communication (again) 1. Authz Code Request User/Browser Client App Authz Server API Server 2. User Authentication (User Consent) 3. Authz Code Response 5. API Access 4. Token Request/Response (Client Authentication) redirect redirect authz code access token authz code access token OAuth 2.0 Authorization Code Flow Front-channel communication: An authorization response is sent from an authorization server to a client via a user’s browser ⇒ relatively easy to tamper or forge the response compared with back-channel communication directly.
22. 20 © Hitachi, Ltd. 2022. All rights reserved. Solution: message integrity and authentication (again) 1. Authz Code Request User/Browser Client App Authz Server API Server 2. User Authentication (User Consent) 3. Authz Code Response 5. API Access 4. Token Request/Response (Client Authentication) redirect redirect authz code access token authz code access token OAuth 2.0 Authorization Code Flow Front-channel communication: An authorization response is sent from an authorization server to a client via a user’s browser. ⇒ relatively easy to tamper or forge the request compared with back-channel communication directly. ⇒ use digital signature for message integrity and authentication.
23. 21 © Hitachi, Ltd. 2022. All rights reserved. Solution: message integrity and authentication ID Token as a detached signature := JWT including hash values of protocol parameters sent as query parameters and signed by Authz Server’s private key in asymmetric cryptography. [Specifications] - Financial-grade API Security Profile 1.0 - Part 2: Advanced - 5.1.1. ID Token as Detached Signature User/Browser Client App Authz Server redirect Parameter s and their hash values are enclosed in ID Token. Verify it by authz server’s public key. Compare the hash values of query parameters with ones in ID token. 3. Authz Code Response query params ID token Sign it by authz server’s private key. OAuth 2.0 Authorization Code OIDC Hybrid Flow
24. 22 © Hitachi, Ltd. 2022. All rights reserved. Solution: message integrity and authentication JWT Secured Authorization Response Mode for OAuth 2.0 (JARM) := a new JWT- based mode to encode authorization responses parameters. It can be signed. (e.g., for non-repudiation, confirming who send the request) Optionally, it can be encrypted. (e.g., for end-to-end encryption) [Specifications] - Financial-grade API: JWT Secured Authorization Response Mode for OAuth 2.0 (JARM) User/Browser Client App Authz Server redirect Parameters are enclosed in a JWT Verify it by authz server’s public key. 3. Authz Code Response JWT response Sign it by authz server’s private key. OAuth 2.0 Authorization Code OIDC Hybrid Flow
25. 23 © Hitachi, Ltd. 2022. All rights reserved. Problem 3: bearer token 1. Authz Code Request User/Browser Client App Authz Server API Server 2. User Authentication (User Consent) 3. Authz Code Response 5. API Access 4. Token Request/Response (Client Authentication) redirect redirect authz code access token authz code access token OAuth 2.0 Authorization Code Flow Bearer Token: Everyone who has an access token can access an API.
26. 24 © Hitachi, Ltd. 2022. All rights reserved. Problem 3: bearer token 1. Authz Code Request User/Browser Client App Authz Server API Server 2. User Authentication (User Consent) 3. Authz Code Response 5. API Access 4. Token Request/Response (Client Authentication) redirect redirect authz code access token authz code access token OAuth 2.0 Authorization Code Flow Bearer Token: Everyone who has an access token can access an API. ⇒ An attacker may get a victim client’s access token and use it to access an API illegally.
27. 25 © Hitachi, Ltd. 2022. All rights reserved. Solution 1: sender constrain token 1. Authz Code Request User/Browser Client App Authz Server API Server 2. User Authentication (User Consent) 3. Authz Code Response 5. API Access 4. Token Request/Response (Client Authentication) redirect redirect authz code access token authz code access token OAuth 2.0 Authorization Code Flow Bearer Token: Everyone who has an access token can access an API. ⇒ An attacker may get a victim client’s access token and use it to access an API illegally. ⇒ Only a client who receives an access token from an authorization server can access an API with the access token.
28. 26 © Hitachi, Ltd. 2022. All rights reserved. Solution: sender constrain token (using OAuth MTLS) [Specifications] - RFC 8705 OAuth 2.0 Mutual-TLS Client Authentication and Certificate-Bound Access Tokens Client App Authz Server API Server C 5. API Access authz code Generate access token as JWT in return for authz code. client cert (Mutual TLS) Client cert’s hash value is enclosed into the access token as "cnf" - "x5t#S256" claim Access token is signed by authz server’s private key Access token is verified by authz server’s public key Compare hash value of client cert enclosed in it and the one calculated from the received client cert here. 4. Token Request C access token client cert (Mutual TLS)
29. 27 © Hitachi, Ltd. 2022. All rights reserved. Solution: sender constrain token (using DPoP) [Specifications] - [Internet Draft] OAuth 2.0 Demonstrating Proof-of-Possession at the Application Layer (DPoP) Client App Authz Server API Server C 5. API Access authz code Generate access token as JWT in return for authz code. DPoP proof Client cert’s hash value is enclosed into the access token as "cnf" - “jkt" claim Access token is signed by authz server’s private key Access token is verified by authz server’s public key Compare hash value of the client’s public key enclosed in the access token and the one calculated from the client’s public key enclosed in DPoP proof. 4. Token Request C access token DPoP proof Generate a DPoP proof and enclose a client’s public key in it. Sign a DPoP proof by using a client’s private key. Sign a DPoP proof by using a client’s private key. Generate a DPoP proof and enclose a client’s public key in it. Generate a client’s key pair.
30. 28 © Hitachi, Ltd. 2022. All rights reserved. Which open-source software implements FAPI security profiles? - Keycloak
31. 29 © Hitachi, Ltd. 2022. All rights reserved. Keycloak Keycloak Supporting several AuthN/AuthZ standards Social Login (Identity Brokering) Identity Management LDAP Active Directory RDB OpenID Connect 1.0 SAML v2 GitHub Twitter Facebook OAuth 2.0 • Open-source identity and access management (IAM) software, which is written in Java. • Easy to use, out-of-box • Providing rich features for - Single Sign On - Securing API access • Supporting several standards - Authentication (AuthN) OpenID Connect 1.0, SAML v2, WebAuthn - Authorization (AuthZ) OAuth 2.0, UMA 2.0 and more…
32. 30 © Hitachi, Ltd. 2022. All rights reserved. Supported/Certified FAPI security profiles by Keycloak [FAPI 1.0]  Financial-grade API Security Profile 1.0 - Part 1: Baseline  Financial-grade API Security Profile 1.0 - Part 2: Advanced 1 [FAPI-CIBA]  Financial-grade API: Client Initiated Backchannel Authentication Profile (FAPI-CIBA) 2 [FAPI based Open Banking security profiles]  Brazil Open Banking (Based on FAPI 1 Advanced Final)1  Australia CDR (Based on FAPI 1 Advanced Final)1  UK OpenBanking (Based on FAPI 1 Advanced Final) Certified Certified Certified Certified 1. https://openid.net/certification/#FAPI_OPs 2. https://openid.net/certification/#FAPI-CIBA_OPs [OSS community for supporting FAPI] FAPI-SIG https://github.com/keycloak/kc-sig-fapi
33. 31 © Hitachi, Ltd. 2022. All rights reserved. How does keycloak support FAPI security profiles?
34. 32 © Hitachi, Ltd. 2022. All rights reserved. Implementation of security profiles - Client Policies • Client Policies: a policy-based method that consists of 2 parts, profile and policy. • Profile: Actual implementation of a security profile. It consists of executors, which implement a part of the security profile. • Policy: logic for determining which request from a client applies which security profile. It consists of conditions, which contributes a part of the logic.
35. 33 © Hitachi, Ltd. 2022. All rights reserved. Client policies internals • Interfaces of components are implemented in Keycloak’s body codes while implementation of these interfaces can be implemented outside Keycloak’s body codes, which makes the policy-based method more customizable. • By using Java’s service provider interface (SPI) mechanism, Implementation of components can be pluggable (provider in Java).
36. 34 © Hitachi, Ltd. 2022. All rights reserved. Client policies - representation … "executors": [ { "executor": "secure-client-authenticator", "configuration": { "allowed-client-authenticators": [ "client-jwt", "client-x509" ], "default-client-authenticator": "client-jwt" } }, … • A (security) profile and executors (parts of a security profile) can be represented in JSON. … "conditions": [ { "condition": "client-scopes", "configuration": { "is-negative-logic": false, "scopes": [ "payment_initiation" ], "type": "Optional" } } ], "profiles": [ "fapi-1-advanced" ] … • A policy and conditions (parts of a policy ) can be represented in JSON.
37. 35 © Hitachi, Ltd. 2022. All rights reserved. Summary • What is Open Banking using OAuth 2.0? ⇒ On behalf of a user, a client app accesses APIs providing financial services by using an OAuth 2.0’s access token. • How can we access APIs of Open Banking securely? ⇒ Applying FAPI security profiles to harden security of OAuth 2.0. • Which Open Banking applies FAPI in the real world? ⇒ UK OpenBanking, Australia CDR, Open Banking/Finance Brasil, etc… • How does FAPI secure API access? ⇒ JAR/Request Object, JARM/ID token as a detached signature in hybrid flow, OAuth MTLS/DPoP, and more…
38. 36 © Hitachi, Ltd. 2022. All rights reserved. Summary • Which open-source software implements FAPI security profiles? ⇒ Keycloak supports FAPI 1.0 Baseline, FAPI 1.0 Advanced, FAPI-CIBA as built-in profiles. Keycloak was certified as FAPI 1.0 Advanced, FAPI-CIBA, Australia CDR and Open Banking Brazil FAPI 1.0 supported server by OpenID Foundation. • How does keycloak support FAPI security profiles? ⇒ Client Policies enable us to implement security profile and policies in a pluggable-manner.
39. 37 © Hitachi, Ltd. 2022. All rights reserved. Trademarks • OpenID is a trademark or registered trademark of OpenID Foundation in the United States and other countries. • GitHub is a trademark or registered trademark of GitHub, Inc. in the United States and other countries. • Red Hat is a trademark or registered trademark of Red Hat, Inc. in the United States and other countries. • Twitter is a trademark or registered trademark of Twitter, Inc. in the United States and other countries. • Facebook is a trademark or registered trademark of Facebook, Inc. in the United States and other countries. • Other brand names and product names used in this material are trademarks, registered trademarks, or trade names of their respective holders.
40. © Hitachi, Ltd. 2022. All rights reserved. Takashi Norimatsu 15 December 2022 Hitachi, Ltd. Architecture Design Center, Software & Service Development Division END Securing APIs in Open Banking - FAPI implementation to OSS 38