Financial-grade API (FAPI) and CIBA

Presentation of an OPEN Talk at DeveloperWeek New York 2019 by Taka, co-founder of Authlete, Inc.

Transcript

1. Financial-grade API (FAPI) and CIBA Co-founder, Authlete, Inc. Takahiko Kawasaki <taka@authlete.com> DeveloperWeek NYC 2019 @ Brooklyn Expo Center on June 20, 2019
2. Jan. 2014 Starts to implement Authlete Sep. 2015 Establishes Authlete, Inc. Sep. 2016 Establishes Authlete UK, Ltd. Nov. 2016 Joins FINOLAB Feb. 2017 Joins OpenID Foundation Mar. 2017 Wins FIBC 2017 Grand Prize May 2017 Joins Level39 May 2017 Fund Raising (seed round) Jul. 2017 Gets OpenID Certification Aug. 2017 Cyber39 Founding Member Sep. 2017 Tech in Asia Tokyo 2017 Finalist Feb. 2018 Fund Raising (pre-series A) Apr. 2018 Wins IBM Prize at Draper Nexus B2B Summit 2018 Jul. 2018 Joins Fintech Association of Japan Jul. 2018 Organizes Japan/UK Open Banking and APIs Summit 2018 Jul. 2018 Supports Financial-grade API (Authlete 2.0) Aug. 2018 Passes Open Banking Security Profile Test Jan. 2019 Supervises "OAuth 徹底入門" (book) Feb. 2019 Supports CIBA Apr. 2019 Gets Certified Financial-grade API (FAPI) OpenID Provider 2 Name Authlete, Inc. Establishment September 18, 2015 Capital 444,710,000 JPY (including the capital reserve) Website https://www.authlete.com/ Company Profile Offices Tokyo FINOLAB, Otemachi Bldg 4F, Otemachi 1-6-1, Chiyoda-ku, Tokyo, 100-0004, Japan London Level39, One Canada Square, Canary Wharf, London E14 5AB, UK History Team Takahiko Kawasaki – Co-founder, software engineer Ali Adnan – Co-founder, multilingual serial entrepreneur Joseph Heenan – Lead of the official OpenID test suite Justin Richer – Author of "OAuth 2 in Action" and other wonderful members Product Authlete, SaaS providing Web APIs whereby developers implement servers that support OAuth 2.0 and OpenID Connect.
3. 3 Chapter 1 : Financial-grade API
4. OAuth 2.0 API authorization OpenID Connect (OIDC) verifiable user identity Financial-grade API (FAPI) higher security The Financial-grade API (FAPI) Working Group has developed Financial-grade API (FAPI) on top of OAuth 2.0 and OpenID Connect. OpenID Foundation
5. The specification was renamed from Financial API to Financial-grade API because the specification can apply to not only the financial industry but also other industries that need high security. 5 2017 2 Part 1 of Financial API Implementer's Draft 1 2017 7 Part 2 of Financial API Implementer's Draft 1 2018 10 Financial-grade API Implementer's Draft 2 History of FAPI
6. 6 FAPI Certification (Certified FAPI OPs, as of June 12, 2019) OpenID Foundation started FAPI Certification Program on April 1, 2019.
7. 7 FAPI Parts Financial-grade API consists of the following parts: • Part 1: Read-Only API Security Profile • Part 2: Read and Write API Security Profile • Part 3: Client Initiated Backchannel Authentication Profile From the foreword of FAPI specification: 2019 2 CIBA Core 1.0 NEW CIBA specification adds new authorization flows.
8. 8 Enhanced Security ü Entropy Requirement for Client Secret ü JWT-Based Client Authentication ü Certificate-Based Client Authentication ü Key Size Requirement for Client Authentication ü Proof Key for Code Exchange ü Redirect URI Pre-registration ü Redirect URI Mandatory Request Parameter ü Redirect URI Exact Match ü Level of Assurance for End-User Authentication ü Explicit Consent for Requested Scopes ü Prohibition of Authorization Code Reuse ü Scope Mandatory Response Parameter ü Entropy Requirement for Access Token ü Access Token Revocation ü Claimed HTTP Scheme URI Redirection ü Prohibition of Access Token in Query Part ü Detached Signature ü State Hash ü Certificate-Bound Access Token ü Token Binding ü Request Object Mandatory Request Parameter ü Request Object including All Request Parameters ü Request Object EXP Claim ü Request Object Mandatory Signing ü Essential ACR Claim ü JWT Secured Authorization Response Mode ü TLS Cipher Suite Restriction ü JWS Signature Algorithm Restriction Topics covered in this talk
9. Client Authentication 9
10. 10 Token Endpoint Authorization Server token request Client Application Client Type | | Confidential Client Authentication is required when a confidential client accesses the token endpoint.
11. POST {Token Endpoint} HTTP/1.1 Host: {Authorization Server} Authorization: Basic {BASE64-encoded Credentials} Content-Type: application/x-www-form-urlencoded (abbrev) 11 The traditional ways described in RFC 6749 use Client ID and Client Secret for client authentication. 1. Basic Authentication "{Client ID}:{Client Secret}" {BASE64-encoded Credentials} Encode by BASE64 (client_secret_basic)
12. 12 2. Form Parameters (client_secret_post) POST {Token Endpoint} HTTP/1.1 Host: {Authorization Server} Content-Type: application/x-www-form-urlencoded client_id={Client ID}& client_secret={Client Secret}& (abbrev) These traditional ways (client_secret_basic and client_secret_post) are not allowed in FAPI.
13. 13 Client Authentication Method Part 1 Part 2 client_secret_basic × × client_secret_post × × client_secret_jwt ◦ × private_key_jwt ◦ ◦ tls_client_auth ◦ ◦ self_signed_tls_client_auth ◦ ◦ JWT-based certificate-based traditional
14. 14 ü Generate JWT and pass it to the token endpoint JWT-based Client Authentication (RFC 7523) instead of passing a pair of client ID & client secret directly. ü The JWT is passed as the value of client_assertion. ü The JWT is signed using either (a) the client's client secret (client_secret_jwt), or (b) the client's private key (private_key_jwt).
15. 15 POST {Token Endpoint} HTTP/1.1 Host: {Authorization Server} Content-Type: application/x-www-form-urlencoded client_assertion_type= urn:ietf:params:oauth:client-assertion-type:jwt-bearer& client_assertion={JWT}& (abbrev) { "iss": "{Client ID}", "sub": "{Client ID}", "aud": "{Token Endpoint}", "jti": "{JWT ID}", "exp": {Expiration Time}, "iat": {Issue Time} } payload The iss claim and the sub claim in the JWT hold the client ID.
16. 16 ü Establish mutual TLS connection to the token endpoint. Certificate-based Client Authentication ü The client certificate presented in the connection is used ü The client certificate is either (a) PKI certificate (tls_client_auth), or (b) self-signed certificate (self_signed_tls_client_auth). for client authentication.
17. 17 Token Endpoint Authorization Server Mutual TLS Client Application client certificate A client certificate is sent through the TLS connection. Authorization server uses the client certificate for client authentication. client certificate
18. Certificate-Bound Access Token 18
19. 19 Web API Resource Server Client Application access token access token API call 1 extract 2 verify 3 API response 4 Malicious Client stolen API call access token
20. Certificate-Bound Access Token 20 Authorization Server Client Application token request (Mutual TLS) check the binding issue an access token client certificate access token Resource Server generate an access token and bind the certificate to it access token client certificate API call (Mutual TLS) access token client certificate The same client certificate as used in the token request 1 2 3 4 5
21. JWT Secured Authorization Response Mode (JARM) 21
22. 22 JARM is a specification to pack response parameters from the authorization endpoint into a JWT. HTTP/1.1 302 Found Location: https://client.example.com/callback? response={JWT} HTTP/1.1 302 Found Location: https://client.example.com/callback? code={Authorization Code}&state={State} In normal cases In JARM
23. 23 HTTP/1.1 302 Found Location: https://client.example.com/cb?response=eyJhbGciOiJSUzI1NiIsInR5cCI6IkpXVCJ 9.eyJpc3MiOiJodHRwczovL2FjY291bnRzLmV4YW1wbGUuY29tIiwiYXVkIjoiczZCaGRSa3F0MyIsImV4cC I6MTMxMTI4MTk3MCwiY29kZSI6IlB5eUZhdXgybzdRMFlmWEJVMzJqaHcuNUZYU1FwdnI4YWt2OUNlUkRTZD BRQSIsInN0YXRlIjoiUzhOSjd1cWs1Zlk0RWpOdlBfR19GdHlKdTZwVXN2SDlqc1luaTlkTUFKdyJ9.HkdJ_ TYgwBBj10C-aWuNUiA062Amq2b0_oyuc5P0aMTQphAqC2o9WbGSkpfuHVBowlb-zJ15tBvXDIABL_t83q6aj vjtq_pqsByiRK2dLVdUwKhW3P_9wjvI0K20gdoTNbNlP9Z41mhart4BqraIoI8e-L_EfAHfhCG_DDDv7Yg { "iss": "https://accounts.example.com", "aud": "s6BhdRkqt3", "exp": 1311281970, "code": "PyyFaux2o7Q0YfXBU32jhw.5FXSQpvr8akv9CeRDSd0QA", "state": "S8NJ7uqk5fY4EjNvP_G_FtyJu6pUsvH9jsYni9dMAJw" } Example of an authorization response in JARM Decoded payload
24. 24 To use JARM, include the response_mode parameter with *.jwt. response_mode=query.jwt |fragment.jwt |form_post.jwt |jwt GET {Authorization Endpoint} ?response_type={Response Type} &client_id={Client ID} &response_mode=jwt HTTP/1.1 Host: {Authorization Server}
25. 25 Chapter 2 : Client Initiated Backchannel Authentication
26. 26 CIBA (Client Initiated Backchannel Authentication) defines new authorization flows. 1 CIBA POLL Mode 2 CIBA PING Mode 3 CIBA PUSH Mode The flows enable to separate the authentication device on which a user is authenticated and API authorization is granted from the consumption device on which a client application that calls APIs runs.
27. 27 smart speaker Purchase ABC. backend system authorization server that supports CIBA asks for the permission authentication device consumption device resource server that provides APIs grants the permission The system is asking for the permission. Approve? calls APIs 4 1 2 3 5 6 7 backchannel authentication request
28. 28 Every CIBA flow starts from a backchannel authentication request. Client sends a backchannel authentication request to the backchannel authentication endpoint of the authorization server. Backchannel Authentication Endpoint Client Application Authorization Server NEW A new endpoint defined by CIBA Backchannel authentication request
29. 29 Backchannel Authentication Endpoint Client Application Authorization Server Authentication Device Backchannel Authentication Endpoint returns a response immediately. Authorization Server delegates the tasks of end-user authentication and consent confirmation to the Authentication Device. Authentication Device passes the result to the authorization server. 1 2 3
30. 30 Authorization Server Client Backchannel Authentication Endpoint token request Token Endpoint Authentication Device communicate End-User token response backchannel authentication request backchannel authentication response CIBA POLL mode 1 2 3 4 5 (4)-(5) is repeated until (3) finishes.
31. 31 Authorization Server Client notification Backchannel Authentication Endpoint token request Token Endpoint Client Notification Endpoint Authentication Device communicate End-User token response backchannel authentication request backchannel authentication response CIBA PING mode 1 2 3 4 5 6
32. 32 Authorization Server Client notification Backchannel Authentication Endpoint Token Endpoint Client Notification Endpoint Authentication Device communicate End-User backchannel authentication request backchannel authentication response CIBA PUSH mode 1 2 3 4 This notification includes an access token & an ID token.
33. 33 Thank You G en era l info@authlete.com S ales sales@authlete.com P R pr@authlete.com Technical support@authlete.com Contact https://www.authlete.com/contact/ @authlete
34. References 34
35. 35 ü Financial-grade API, Part 1: Read-Only Security Profile https://openid.net/specs/openid-financial-api-part-1-ID2.html ü Financial-grade API, Part 2: Read and Write API Security Profile https://openid.net/specs/openid-financial-api-part-2-ID2.html ü Financial-grade API: JWT Secured Authorization Response Mode for OAuth 2.0 (JARM) https://openid.net/specs/openid-financial-api-jarm-ID1.html ü OpenID Connect Client Initiated Backchannel Authentication Flow – Core 1.0 https://openid.net/specs/openid-client-initiated-backchannel- authentication-core-1_0.html ü OAuth 2.0 Mutual TLS Client Authentication and Certificate Bound Access Tokens https://datatracker.ietf.org/doc/draft-ietf-oauth-mtls/ ü RFC 7523 – JSON Web Token (JWT) Profile for OAuth 2.0 Client Authentication and Authorization Grants https://tools.ietf.org/html/rfc7523 Specifications ü Financial-grade API (API), explained by an implementer https://medium.com/@darutk/financial-grade-api-fapi- explained-by-an-implementer-d09fcf2ff932 ü "CIBA", a new authentication/authorization technology in 2019, explained by an implementer https://medium.com/@darutk/ciba-a-new-authentication- authorization-technology-in-2019-explained-by-an- implementer-d1e0ac1311b4 Articles Others ü Financial-grade API (FAPI) Working Group https://openid.net/wg/fapi/ ü Official Conformance Suite https://gitlab.com/openid/conformance-suite