Auth0 FinServ Meeting 17.6.2021

1. Comprehensive Overview
FAPI 1 and 2
Dr. Torsten Lodderstedt, yes.com

2. What is FAPI?
● A security and interoperability profile for OAuth for open banking and other
use cases with high security requirements
● Includes new specifications as required

3. FAPI Family Tree
Baseline
Advanced
FAPI
1
2016-06 2017-07 2018-10
I
D
1
I
D
2
2019-08 2021-07*
Baseline
Advanced
2021-02
I
D
1
* Projection Only
F
I
N
A
L
uses existing OpenID Connect security
mechanisms to patch OAuth security
issues
Adopted by UK OpenBanking, FDX
(US/CA), CDR (Australia), and Brasil
FAPI
2
Open Banking
Survey
OAuth Security Best Current Practice (BCP)
the next evolutionary step, simpler to use
and with a broader scope
Adopted in yes open banking scheme
(~1000 banks)

4. FAPI 1

5. FAPI 1 vs Plain OAuth
● Patches OAuth security issues, e.g. code replay, authorization request
tampering, and mix-up
● Formal security analysis by University Stuttgart
● Adds CIBA (Decoupled) interaction mode (beside Redirect)
● Defines interoperable OAuth profile that can be tested for conformance
● Introduces conformance testing

6. Signed Requests
{
"scope":"openid consent:urn-amazingbank-0be7a3bb-33e6-4d73-b60a-9523aee6cc0d accounts",
"response_type":"code id_token",
"redirect_uri":"https://tpp.localhost/cb",
"code_challenge":"0q5idWeuyFAGeHHpawD3k4mjE7WzPhw6hOdKbnAQY7s",
"code_challenge_method":"S256",
"state":"19a1456013b8be71e6ce89916c9723e0642e1eb42a9360146cc84178f2bc928e",
"nonce":"8dedaf2c53f7ba7294825ca25e45aa544c3feda8fd4ac16220c216e973ad5fd7",
"claims":{
"id_token":{
"auth_time":{
"essential":true
},
"cpf":{
"values":[
"16386335767"
],
"essential":true
},
"given_name":{
"essential":true
},
"acr":{
"values":[
"brasil:openbanking:standard"
],
"essential":true
}
}
},
"max_age":300,
"iss":"clientIdFromAmazingBank",
"aud":"https://auth.amazingbank.com.br",
"client_id":"clientIdFromAmazingBank",
"jti":"_fj7iamgC1wDzh8KXaJ7XzJiEK_s25DhoDs7uAxpU-k",
"iat":1618672338,
"exp":1618672638,
"nbf":1618672338
}
● Protect integrity and
authenticity of request
● Request can also be
encrypted to protect
confidentiality
https://server.example.com/authorize?
response_type=code%20id_token
&client_id=s6BhdRkqt3
&redirect_uri=https%3A%2F%2Fclient.example.org%2Fcb&
&request=eyJhbGciOiJSU...zCYIb_NMXvtTIVc1jpspnTSD7xMbpL-2QgwUsAlMGzw

7. ID Token as Detached Signature
HTTP/1.1 302 Found
Location: https://tpp.localhost/cb#
code=SplxlOBeZQQYbYS6WxSbIA
&id_token=eyJ0 ... NiJ9.eyJ1c ... I6IjIifX0.DeWt4Qu ... ZXso
&state=af0ifjsldkj
{
"iss": "http://server.example.com",
"sub": "248289761001",
"aud": "s6BhdRkqt3",
"nonce": "n-0S6_WzA2Mj",
"exp": 1311281970,
"iat": 1311280970,
"c_hash": "LDktKdoQak3Pk0cnXxCltA"
"s_hash": "Zjk2Y2VhMTk4YWQxZGQ1Nj"
}
● Protects against
○ code replay
(nonce+c_hash)
○ mix-up (iss)
○ CSRF
● Requires “sub” (even if no
federated id is required)
● End-User claims might be
released in front channel
(additional encryption might
be required)

8. JARM (JWT Secured Authorization Response Mode)
● Response parameters
are wrapped in a signed
(optionally encrypted)
JWT
● No user claims required
● works with plain OAuth {
"iss":"https://accounts.example.com",
"aud":"s6BhdRkqt3",
"exp":1311281970,
"code":"PyyFaux2o7Q0YfXBU32jhw.5FXSQpvr8akv9CeRDSd0QA",
"state":"S8NJ7uqk5fY4EjNvP_G_FtyJu6pUsvH9jsYni9dMAJw"
}
HTTP/1.1 302 Found
Location: https://client.example.com/cb?
response=eyJraWQiOiJsYWViIiwiYWxnIjoiRVMyNTYifQ.eyAgImlzcyI6ICJodHRwczov
L2FjY291bnRzLmV4YW1wbGUuY29tIiwgICJhdWQiOiAiczZCaGRSa3F0MyIsICAiZXhwIjog
MTMxMTI4MTk3MCwgICJjb2RlIjogIlB5eUZhdXgybzdRMFlmWEJVMzJqaHcuNUZYU1FwdnI4
YWt2OUNlUkRTZDBRQSIsICAic3RhdGUiOiAiUzhOSjd1cWs1Zlk0RWpOdlBfR19GdHlKdTZw
VXN2SDlqc1luaTlkTUFKdyJ9.4VdtknVZ9zFYDVLagJpVBD436bjPMcSgOaPDPFgTEkNyCs2
uIHYJ2XML6d2w1AUsm5GBG77DBisZNhLWfug6dA

9. CIBA: Client Initiated Back
Channel Authentication
● Use when User
interacts with the RP
and OP (Bank) on
different physical
devices.
● Examples payment
Kiosk, Alexa,
Connected Cars.
Bank
2. Please Authenticate
and Authorise + id_token
5. Authorisation Complete
6. AT/RT/ID Token
7. Refresh
TPP
1. Give Consent
+ mcdonalds_id +
Bank Name
4. Authorise
3. Do you
want to
authorise?

10. Open Banking Survey ...
… revealed that Open Banking Use Cases require:
(1) authorization beyond scope values
and
(2) grant management capabilities
Examples:
- Lodging Intent (UK OB & NextGenPSD2)
- Scope value + JSON object (Polish API)
{
"instructedAmount":{
"currency":"EUR",
"amount":"123.50"
},
"debtorAccount":{
"iban":"DE40100100103307118608"
},
"creditorName":"Merchant123",
"creditorAccount":{
"iban":"DE02100100109307118603"
},
"remittanceInformationUnstructured":"Ref Number Merchant"
}
see https://cutt.ly/oauth-transaction-authorization for details

11. FAPI 2

12. FAPI 2 as next step
● Broader interoperability
○ through coverage of rich authorization / consent management and secure access to APIs
● Simpler to use
○ through new mechanisms (e.g. Pushed Authorization Requests/PAR, no ID Token as
detached signature required)
● Well-understood and better-defined security
○ Formal attacker model
○ FAPI 2 Baseline fully protects against attacker model
○ FAPI 2 Baseline has same protection level as FAPI 1 Advanced
● More versatile
○ through alternative mechanism for token replay protection (DPoP)

13. Pushed Authorization Requests (PAR)
Authorization request data is pushed to the
AS before user dialog is startet
→ Can replace signed authorization
requests
→ Simplified development through vendor
support and reliance on TLS (signed
requests possible)
→ Minimize data in front-channel to improve
security and increase robustness
POST /as/par HTTP/1.1
Host: as.example.com
Content-Type: application/x-www-form-urlencoded
Authorization: Basic czZCaGRSa3F0Mzo3Rmp..
response_type=code
&client_id=s6BhdRkqt3&state=af0ifjsldkj
&redirect_uri=https%3A%2F%2Fclient.example.org%2Fcb
<voluminous payload goes here>
HTTP/1.1 201 Created
Cache-Control: no-cache, no-store
Content-Type: application/json
{
"request_uri":"urn:example:bwc4JK-ESC0w8acc1...",
"expires_in": 90
}
https://server.example.com/authorize?
client_id=s6BhdRkqt3&
request_uri=urn:example:bwc4JK-ESC0w8acc1...

14. Rich Authorization Requests (RAR)
enable fine-grained and complex consents
captured as JSON objects.
● Structure of authorization details can
be defined as needed (e.g. per
jurisdiction and AAP)
● Supports Multi-Consents
→ Can replace scopes + related
authorization data (e.g. in lodging intents)
[
{
"type":"payment_initiation",
"instructedAmount":{
"currency":"AUD",
"amount":"123.50"
},
"creditorName":"Merchant123",
"creditorAccount":{
"bsb":"123-456",
"accountNumber":"1234567890"
},
"paymentDescription":"INV123456 Description123"
}
]
[
{
"type":"brasil:openbanking:standard:data",
"permissions":[
"ACCOUNTS_READ"
],
"expirationDateTime":"2021-05-21T08:30:00Z",
"transactionFromDateTime":"2021-01-01T00:00:00Z",
"transactionToDateTime":"2021-02-01T23:59:59Z"
}
]

15. Grant Management
Grant Management enables support for
● consent state synchronization
● consent revocation
● concurrent consents
● consent update & renewal
● Dashboards

16. Grant Management (request new grant id)
POST /as/par HTTP/1.1
Host: as.example.com
Content-Type: application/x-www-form-urlencoded
Authorization: Basic czZCaGRSa3F0Mzo3Rm...
response_type=code&
client_id=s6BhdRkqt3
&grant_management_action=create
&state=af0ifjsldkj
&redirect_uri=https%3A%2F%2Fclient.example.org%2Fcb
&code_challenge_method=S256
&code_challenge=K2-ltc83acc4h...
&authorization_details=%5B%7B%2...
HTTP/1.1 200 OK
Content-Type: application/json
Cache-Control: no-cache, no-store
{
"access_token": "2YotnFZFEjr1zCsicMWpAA",
"token_type": "example",
"expires_in": 3600,
"refresh_token": "tGzv3JOkF0XG5Qx2TlKWIA",
"grant_id":"0a15a804-b5b4-4a45-9cd9-18b1a44f3383",
"authorization_details": [...
]
}
(Pushed) Authorization Request) Token Response

17. Grant Management (API)
GET /grants/0a15a804-b5b4-4a45-9cd9-18b1a44f3383
Host: as.example-bank.com
Authorization: Bearer 2YotnFZFEjr1zCsicMWpAA
HTTP/1.1 200 OK
Cache-Control: no-cache, no-store
Content-Type: application/json
{
"authorization_details":[...]
}
DELETE /grants/0a15a804-b5b4-4a45-9cd9-18b1a44f3383
Host: as.example-bank.com
Authorization: Bearer 2YotnFZFEjr1zCsicMWpAA
HTTP/1.1 204 No Content
Query Revoke

18. Grant Management (request use of certain grant)
POST /as/par HTTP/1.1
Host: as.example.com
Content-Type: application/x-www-form-urlencoded
Authorization: Basic czZCaGRSa3F0Mzo3Rm...
response_type=code&
client_id=s6BhdRkqt3
&grant_management_action=update
&grant_id=0a15a804-b5b4-4a45-9cd9-18b1a44f3383
&state=af0ifjsldkj
&redirect_uri=https%3A%2F%2Fclient.example.org%2Fcb
&code_challenge_method=S256
&code_challenge=K2-ltc83acc4h...
&authorization_details=%5B%7B%2...
(Pushed) Authorization Request)
Use cases
● Renew grant (because it is about
to be expire)
● Update existing grant
● Ensure authorization process is
performed with same user
● Allows identification of user
(alternative login hint for CIBA)

19. PKCE
POST /as/par HTTP/1.1
Host: as.example.com
Content-Type: application/x-www-form-urlencoded
Authorization: Basic czZCaGRSa3F0Mzo3Rmp..
response_type=code
&client_id=s6BhdRkqt3&state=af0ifjsldkj
&redirect_uri=https%3A%2F%2Fclient.example.org%2Fcb
&code_challenge_method=S256
&code_challenge=E9Melhoa2OwvFrEMTJguCHaoeK1t8URWbuGJSstw-cM
...
POST /as/par HTTP/1.1
Host: as.example.com
Content-Type: application/x-www-form-urlencoded
Authorization: Basic czZCaGRSa3F0Mzo3Rmp..
grant_type=authorization_code
&code=SplxlOBeZQQYbYS6WxSbIA
&redirect_uri=https%3A%2F%2Fclient.example.org%2Fcb
&code_verifier=dBjftJeZ4CVP-mB92K27uhbUJU1p1r_wW1gFWFOEjXk
PKCE (RFC 7636) is used to detect
code replay and CSRF
Dynamically generated
cryptographically random key used
to bind transaction to browser/device
→ simple and robust
→ security check moved to AS
→ Can replace ID token as detached
signature

20. Feature Comparison
Topic FAPI 1 FAPI 2
Request Integrity Signed Request Objects PAR
CSRF state + s_hash in ID Token PKCE
Code Replay ID Token as detached signature or JARM
or PKCE
PKCE
Mix-Up iss claim in ID token or JARM iss response parameter
Access Token Replay mTLS mTLS or DPoP
Rich authorizations data custom solutions, e.g. Lodging Intent PAR+RAR
Consent management custom solutions, e.g. Lodging Intent Grant Management
Non-repudiation Signed Request Objects, ID Token as
detached signature
API not covered
JAR, JARM, Signed Introspection
Response, Simple HTTP Message
Integrity Protocol
B
a
s
e
l
i
n
e
A
d
v

21. FAPI 1 (lodging intent) vs FAPI 2 (PAR+RAR)

22. MTLS
FAPI Family Tree
Baseline
Advanced
ver.1
2016-06 2017-07 2018-10
I
D
1
I
D
2
JARM
I
D
1
FAPI-CIBA
2019-08 2021-07*
“Public” Client Prof.
I
D
1
Baseline=JAR+PAR+RAR
Advanced
PAR
RFC8705
2021-02
F
I
N
A
L
I
D
1
* Projection Only
ver.2
F
I
N
A
L
RAR L
C

23. Q & A

24. FAPI adoption in new ecosystems
● Reasons to use FAPI 1
○ If vendors in an ecosystem already support FAPI 1
○ FAPI 1 is a mature and widely supported security profile.
● Reasons to use FAPI 2
○ FAPI 2 is easier to implement
○ FAPI 2 covers complex authorization requests and grant lifecycle management aspects
○ FAPI 2 (as profile for API access authorization) better fits with OpenID Connect (for identity
claims provisioning) then FAPI 1

25. Ecosystems already using FAPI 1
● Benefit for adoption:
○ Simpler protocol and improved interoperability
○ Specification aligned with the latest OAuth best practices and security advice
● Incremental adoption of FAPI 2 modules possible:
○ Example: Australia adopted PAR with FAPI 1
○ RAR + Grant Management as full lifecycle consent management solution for FAPI 1
● Running both profile in parallel is possible
○ Would allow new clients to utilize the simpler protocol (and existing clients to migrate)