FAPI 1 and 2 are security and interoperability profiles for OAuth. FAPI 1 patched OAuth security issues and added features like CIBA. FAPI 2 is a simpler evolution with broader scope, covering authorization, consent management, and secure API access. It uses mechanisms like PAR, RAR, and grant management to enable rich authorization and consent workflows. FAPI 2 provides the same security protections as FAPI 1 in a more versatile manner through alternative mechanisms like DPoP and PKCE. Adoption depends on existing vendor support and use case requirements around authorization complexity and consent lifecycle management.

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)