Slide 1

Slide 1 text

Basics of OAuth, OIDC, FAPI & CIBA Co-founder, Authlete, Inc. Takahiko Kawasaki Authlete Meetup @ Level39 on Feb 19, 2020

Slide 2

Slide 2 text

2 OAuth

Slide 3

Slide 3 text

Client App Resource Server API "Give me the user's data." Data "Here you are." Data

Slide 4

Slide 4 text

Malicious App Resource Server API "Give me the user's data." Data "Here you are." Data Even a malicious application can get the user's data. Need a mechanism to protect the API!

Slide 5

Slide 5 text

Resource Server Client App API "Give me the user's data." Data "Here you are." An access token must be given to the client in advance. Need someone who issues access tokens! Access Token Access Token Access Token Data verify

Slide 6

Slide 6 text

Someone who issues access tokens Authorization Server (AS) ||

Slide 7

Slide 7 text

Client App Authorization Server Access Token generate issue Access Token

Slide 8

Slide 8 text

"Give me the user's data." Client App Resource Server API Authorization Server Access Token Access Token Data "Here you are." Data Access Token Access Token generate issue verify

Slide 9

Slide 9 text

"Give me an access token." Client App Authz Server User "Do you give the permissions to the client?" "Yes, please." generate Access Token issue "Here you are." RFC 6749 The OAuth 2.0 Authorization Framework Access token request & response Access Token Standardized

Slide 10

Slide 10 text

10 OpenID Connect (OIDC)

Slide 11

Slide 11 text

Hi, I'm Donald Trump. Really? Prove it. Yes. This is my business card. President Donald Trump @White House No. It cannot be proof. Anyone can forge business cards.

Slide 12

Slide 12 text

Wait a second. I'll verify it. Hi, I'm Donald Trump. This time I have a signed business card. President Donald Trump @White House 8IJUF )PVTF

Slide 13

Slide 13 text

Hello, White House. Yes. What can I do for you? Give me the public key to verify the signature attached to a business card issued by you. Here you are. Wait a second. I'll verify it. Hi, I'm Donald Trump. This time I have a signed business card. President Donald Trump @White House 8IJUF )PVTF

Slide 14

Slide 14 text

I've confirmed the business card has been issued by White House. Hello, White House. Yes. What can I do for you? Give me the public key to verify the signature attached to a business card issued by you. Here you are. Wait a second. I'll verify it. Hi, I'm Donald Trump. This time I have a signed business card. President Donald Trump @White House 8IJUF )PVTF

Slide 15

Slide 15 text

“business card with signature” what corresponds to this concept ID Token President Donald Trump @White House 8IJUF )PVTF

Slide 16

Slide 16 text

Someone who issues ID tokens OpenID Provider (IdP) ||

Slide 17

Slide 17 text

Client App OpenID Provider ID Token generate issue ID Token

Slide 18

Slide 18 text

"Give me an ID token." Client App IdP User"Issue an ID token? If so, provide info to authenticate you with." "Yes, and this is the info." generate ID Token issue "Here you are." OpenID Connect Core 1.0 (OIDC Core 1.0) ID token request & response ID Token Standardized

Slide 19

Slide 19 text

OAuth 2.0 OpenID Connect Alike... http://openid.net/connect/ OpenID Connect 1.0 is a simple identity layer on top of the OAuth 2.0 protocol

Slide 20

Slide 20 text

"Issue an ID token and an access token? If so, provide info to authenticate you. "Give me an ID token and an access token." Client App Authz Server "Yes, and this is the info. generate issue "Here you are" ID Token OpenID Provider and Access Token ID Token Access Token U s e r

Slide 21

Slide 21 text

21 Financial-grade API (FAPI)

Slide 22

Slide 22 text

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

Slide 23

Slide 23 text

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

Slide 24

Slide 24 text

24 FAPI Certification OIDF started FAPI Certification Program on April 1, 2019. (as of Feb 19, 2020)

Slide 25

Slide 25 text

25 FAPI-CIBA Certification OIDF started FAPI-CIBA Certification Program on Sep. 1, 2019. (as of Feb 19, 2020)

Slide 26

Slide 26 text

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

Slide 27

Slide 27 text

27 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

Slide 28

Slide 28 text

Client Authentication 28

Slide 29

Slide 29 text

29 Token Endpoint Authorization Server token request Client Application Client Authentication is required when a confidential client accesses the token endpoint. Client Type public confidential

Slide 30

Slide 30 text

POST {Token Endpoint} HTTP/1.1 Host: {Authorization Server} Authorization: Basic {BASE64-encoded Credentials} Content-Type: application/x-www-form-urlencoded (abbrev) 30 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)

Slide 31

Slide 31 text

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

Slide 32

Slide 32 text

32 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

Slide 33

Slide 33 text

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

Slide 34

Slide 34 text

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

Slide 35

Slide 35 text

35 ü 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.

Slide 36

Slide 36 text

36 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

Slide 37

Slide 37 text

Certificate-Bound Access Tokens 37

Slide 38

Slide 38 text

38 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

Slide 39

Slide 39 text

Certificate-Bound Access Token 39 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

Slide 40

Slide 40 text

JWT Secured Authorization Response Mode (JARM) 40

Slide 41

Slide 41 text

41 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

Slide 42

Slide 42 text

42 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

Slide 43

Slide 43 text

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

Slide 44

Slide 44 text

44 Client Initiated Backchannel Authentication (CIBA)

Slide 45

Slide 45 text

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

Slide 46

Slide 46 text

46 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

Slide 47

Slide 47 text

47 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

Slide 48

Slide 48 text

48 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

Slide 49

Slide 49 text

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

Slide 50

Slide 50 text

50 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

Slide 51

Slide 51 text

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

Slide 52

Slide 52 text

References 52

Slide 53

Slide 53 text

53 ü 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 ü OAuth 2.0 Client Authentication https://medium.com/@darutk/oauth-2-0-client- authentication-4b5f929305d4 Articles Others ü Financial-grade API (FAPI) Working Group https://openid.net/wg/fapi/ ü Official Conformance Suite https://gitlab.com/openid/conformance-suite

Slide 54

Slide 54 text

54 Thank You G en era l [email protected] S ales [email protected] P R [email protected] Technical [email protected] Contact https://www.authlete.com/contact/ @authlete