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

© 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

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

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

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

3
What is Open Banking using OAuth 2.0?

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

5
How can we access APIs of Open Banking securely?
- applying Financial-grade API (FAPI) security profile

6
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

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

8
Which Open Banking applies FAPI in the real world?

9
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

10
How does FAPI secure API access?

11
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

12
Problem 1: front-channel communication
(User Consent)
5. API Access
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

13
Problem 1: front-channel communication
(User Consent)
5. API Access
redirect
redirect
authz code
access token
authz code
access token
OAuth 2.0
Authorization
Code Flow
⇒ relatively easy to tamper or
forge the request compared with
back-channel communication
directly.

14
Solution 1: message integrity and authentication
(User Consent)
5. API Access
redirect
redirect
authz code
access token
authz code
access token
OAuth 2.0
Authorization
Code Flow
directly.
⇒ use digital signature for
message integrity and
authentication

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

16
Solution 2: avoiding front-channel communication
(User Consent)
5. API Access
redirect
redirect
authz code
access token
authz code
access token
OAuth 2.0
Authorization
Code Flow
directly.
⇒ send a content of the request
directly from a client to an
authorization server

17
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.
redirect
[Specifications]
- RFC 9126 OAuth 2.0 Pushed Authorization Requests
request
fetch
store
reference
reference

18
Problem 2: front-channel communication (again)
(User Consent)
5. API Access
redirect
redirect
authz code
access token
authz code
access token
OAuth 2.0
Authorization
Code Flow
An authorization response is sent
from an authorization server to a
client via a user’s browser

19
Problem 2: front-channel communication (again)
(User Consent)
5. API Access
redirect
redirect
authz code
access token
authz code
access token
OAuth 2.0
Authorization
Code Flow
client via a user’s browser
forge the response compared with
directly.

20
Solution: message integrity and authentication (again)
(User Consent)
5. API Access
redirect
redirect
authz code
access token
authz code
access token
OAuth 2.0
Authorization
Code Flow
client via a user’s browser.
directly.
⇒ use digital signature for
message integrity and
authentication.

21
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
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.
query
params
ID
token Sign it by authz server’s
private key.
OAuth 2.0
Authorization Code
OIDC Hybrid Flow

22
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.
[Specifications]
- Financial-grade API: JWT Secured Authorization Response Mode for OAuth 2.0 (JARM)
redirect
Parameters are enclosed in a JWT
Verify it by authz
server’s public key.
JWT
response Sign it by authz server’s
private key.
OAuth 2.0
Authorization Code
OIDC Hybrid Flow

23
Problem 3: bearer token
(User Consent)
5. API Access
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.

24
Problem 3: bearer token
(User Consent)
5. API Access
redirect
redirect
authz code
access token
authz code
access token
OAuth 2.0
Authorization
Code Flow
Bearer Token:
⇒ An attacker may get a victim
client’s access token and use it to
access an API illegally.

25
Solution 1: sender constrain token
(User Consent)
5. API Access
redirect
redirect
authz code
access token
authz code
access token
OAuth 2.0
Authorization
Code Flow
Bearer Token:
⇒ 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.

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

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

28
Which open-source software implements
FAPI security profiles?
- Keycloak

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

30
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

31
How does keycloak support FAPI security profiles?

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

33
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).

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

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

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

37
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
• Twitter is a trademark or registered trademark of Twitter, Inc. in the United
• 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.

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

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

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

Recomendados

Recomendados

Más contenido relacionado

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

Similar a apidays Paris 2022 - Securing APIs in Open Banking, Takashi Norimatsu, Hitachi (20)

Más de apidays

Más de apidays (20)

Último

Último (20)

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