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
   

   View Slide

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
   

   View Slide

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.
   

   View Slide

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?
   

   View Slide

5. 3
   © Hitachi, Ltd. 2022. All rights reserved.
   What is Open Banking using OAuth 2.0?
   

   View Slide

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.
   

   View Slide

7. 5
   © Hitachi, Ltd. 2022. All rights reserved.
   How can we access APIs of Open Banking securely?
   - applying Financial-grade API (FAPI) security profile
   

   View Slide

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
   

   View Slide

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)
   

   View Slide

10. 8
    © Hitachi, Ltd. 2022. All rights reserved.
    Which Open Banking applies FAPI in the real world?
    

    View Slide

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
    

    View Slide

12. 10
    © Hitachi, Ltd. 2022. All rights reserved.
    How does FAPI secure API access?
    

    View Slide

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
    

    View Slide

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
    

    View Slide

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.
    

    View Slide

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
    

    View Slide

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
    

    View Slide

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
    

    View Slide

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
    

    View Slide

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
    

    View Slide

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.
    

    View Slide

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.
    

    View Slide

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
    

    View Slide

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
    

    View Slide

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.
    

    View Slide

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.
    

    View Slide

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.
    

    View Slide

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)
    

    View Slide

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.
    

    View Slide

30. 28
    © Hitachi, Ltd. 2022. All rights reserved.
    Which open-source software implements
    FAPI security profiles?
    - Keycloak
    

    View Slide

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…
    

    View Slide

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
    

    View Slide

33. 31
    © Hitachi, Ltd. 2022. All rights reserved.
    How does keycloak support FAPI security profiles?
    

    View Slide

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.
    

    View Slide

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

    View Slide

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.
    

    View Slide

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…
    

    View Slide

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.
    

    View Slide

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.
    

    View Slide

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
    

    View Slide

41. View Slide