FAPI verstehen #03:  Wie unterscheidet sich der Schutz der FAPI 1.0 Profile?
FAPI #03 Banner

FAPI verstehen – Blogserie  Teil #04

Das Ziel der FAPI ist es, Profile für den Einsatz von OAuth und OpenID Connect mit höchstem Sicherheitsniveau zu erreichen. Dieses Sicherheitsniveau wird zum Beispiel im Finanztechnologie-Sektor oder im e-Health Kontext benötigt. Neben der ersten Version – der FAPI 1.0 – wird zur Zeit eine neue verbesserte Version – FAPI 2.0 – entwickelt.  In diesem Blogpost werden wir die Unterschiede zwischen FAPI 1.0 und FAPI 2.0 beleuchten und die jeweiligen Merkmale der beiden Profile vergleichen.

FAPI 2.0 bietet einen interoperablen Weg, um Access Tokens vor Diebstahl und Protokollnachrichten vor Manipulation zu schützen. Dabei werden weit verbreitete Regularien eingehalten.Durch Begrenzung von erlaubten Client-Typen, Protokoll-Flows und Authentifizierungsmethoden für Clients sowie Verpflichtung zu Sicherheitserweiterungen wie signierten Authorization Requests/Responses (JAR, PAR, JARM), absender-beschränkten Access Tokens (mTLS, DPoP) und CSRF-Schutz (state, nonce, PKCE) wird OAuth/OpenID Connect bestmöglich abgesichert.

 

Rückblick: Was ist die FAPI?

Die FAPI bietet verschiedene Sicherheitsprofile für OAuth und OpenID Connect. Diese können u. a. als interoperable Lösung für Open-Banking-Szenarien verwendet werden. Die FAPI wurde als Reaktion auf die europäische Payment Service Directive 2 PSD2) entwickelt, die 2015 veröffentlicht wurde. Trotz ihres Ursprungs im Finanzbereich sind die FAPI-Profile auch in anderen Hochsicherheits-Szenarien, wie im Kontext von e-Health-Lösungen, einsetzbar.

Die FAPI soll dem hohen Bedarf an Cybersicherheit und dem hohen Maß an Regulierung, insbesondere im Finanzbereich, gerecht werden. Dazu definiert sie Maßnahmen, um die drei Sicherheitsziele – Autorisierung, Authentifizierung und die Integrität der Session – zu erreichen.

 
 

Wie unterscheiden sich die verschiedenen FAPI-Spezifikationen?

Die FAPI 1.0 besteht aus drei Profilen: dem Baseline Profile, dem Advanced Profile und dem CIBA Profile. Die Unterschiede unter den drei Profilen haben wir in Teil #03 der Blogserie “FAPI verstehen” untersucht. Die FAPI 2.0 besteht unter anderem aus dem “FAPI 2.0 Security Profile” und dem “FAPI 2.0 Message Singing”-Addon. Zusätzlich wird ein Attacker Model bereitgestellt, welches Angriffe definiert, gegen welche die FAPI schützt. Auf der Basis dieses Modells werden momentan die Drafts der FAPI 2.0 Profile erarbeitet. Dabei soll die FAPI 2.0 mehr Sicherheit und mehr Interoperabilität bieten als ihre Vorgängerin.


Hinweis: Da an den Drafts von FAPI 2.0 zur Zeit noch aktiv gearbeitet wird, ist es möglich, dass sich Inhalte der Drafts nach Veröffentlichung dieses Blogposts ändern. Die Informationen in diesem Blogpost beziehen sich auf den Stand der Drafts nach dem Commit eefba75dcaeb886367b66bab2ca36cf86a2ce9f3  am 20.12.2023. Die Drafts in diesem Stand sind im Markdown-Format hier verfügbar: FAPI 2.0 Security Profile, FAPI 2.0 Message Singing, FAPI 2.0 Attacker Model. Im HTML-Format stehen jeweils nur die aktuellsten Draft Versionen zur Verfügung.


FAPI 2.0 Security Profile

Das FAPI 2.0 Security Profile ist eine überarbeitete Version des FAPI 1.0 Baseline Profiles. Dabei bezieht das neue Profil die Erfahrungen und das Feedback aus dem Einsatz von FAPI 1.0 in der Industrie ein. Das FAPI 2.0 Security Profile macht unter anderem die folgenden dargestellten Vorgaben.

 

Erlaubte Client-Typen

Im Gegensatz zu dem FAPI 1.0 Baseline Profile, werden nur noch Confidential Clients erlaubt. Diese können und müssen vom Authorization Server sicher authentifiziert werden. Hierbei erlaubt das Profil nur die sicheren Methoden Mutual TLS (mTLS) oder private_key_jwt zur Client Authentifizierung (siehe Punkt 6 in 5.3.1.1.).

 

Absicherung von Tokens

Eine weitere Verstärkung des Security Profiles gegenüber FAPI 1.0 besteht darin, dass absender-beschränkte Access Tokens (Proof-of-Possession Tokens, PoP) verpflichtend eingesetzt werden müssen. In FAPI 1.0 galt diese Vorschrift erst für das Advanced Profile. Umgesetzt werden können die PoP Tokens, wie schon in FAPI 1.0, mittels mTLS oder Demonstration of Proof of Possession (DPoP), einer Alternative auf der Anwendungsschicht (siehe Punkt 4 und 5 in 5.3.1.1). Sofern DPoP eingesetzt wird, muss das zusätzliche “Authorization Code Binding to DPoP Key” unterstützt werden (siehe Punkt 13 in 5.3.1.1.).

 

Erlaubte Protokollflüsse und deren Absicherung

Das Security Profile verbietet die Verwendung des Resource Owner Password Credentials Grant, des Implicit Grants und des Hybrid Flows (siehe Punkt 2 in 5.3.1.1). Stattdessen schreibt es die Unterstützung des Authorization Code Flows vor und definiert eine sichere Umsetzung dieses Flows (siehe 5.3.1.2). Bezüglich ausgestellter Authorization Codes schreibt die FAPI 2.0 eine maximale Gültigkeit von 60 Sekunden (siehe Punkt 12 in 5.3.1.1.), sowie die Ablehnung von Versuchen die Codes erneut einzulösen (siehe Punkt 9 in 5.3.1.2.) vor. Weitere Sicherheitsmaßnahmen des Authorization Code Flows beinhalten die verpflichtende Verwendung der Proof Key for Code Exchanges (PKCE)-Erweiterung, sowie die Rückgabe des iss Parameters in der Authorization Response (siehe Punkt 5 und 7 in 5.3.1.2.). Letzteres verhindert erfolgreich Mix-Up Angriffe.

Auch die Option des FAPI 1.0 Advanced Profiles, Pushed Authorization Requests (PAR) zu unterstützen, ist in dem überarbeiteten Security Profile von FAPI 2.0 verpflichtend vorgeschrieben (siehe Punkt 2 und 3 in 5.3.1.2.). Pushed Authorization Requests dürfen nur mit Client Authentication gesendet werden und müssen die redirect_uri enthalten (siehe Punkt 4 und 6 in 5.3.1.2.). Zudem darf die request_uri eines Pushed Authorization Requests nur eine maximale Gültigkeit von weniger als 600 Sekunden haben (siehe Punkt 12 in 5.3.1.2.).

 

Absicherung der TLS-Verbindung und Vorgaben zur eingesetzten Kryptografie

Auch die Maßnahmen zum Schutz einer sicheren Verbindung mittels TLS und dem Einsatz starker Kryptografie werden verschärft: nur eine Auswahl festgeschriebener TLS Cipher Suites und TLS Versionen ab 1.2 dürfen verwendet werden (siehe 5.2). Auch erlaubte Schlüssellängen und sichere kryptografische Algorithmen werden festgelegt (siehe 5.4).

 

Vorgaben für Clients und Resource Server

Für FAPI 2.0 Clients gilt es die gleichen Erweiterungen und Sicherheitsmechanismen zu unterstützen und korrekt umzusetzen, wie für Authorization Server (zum Beispiel die Validierung des iss Parameters gegen Mix-Up Angriffe, siehe 5.3.2.). Zudem stellt FAPI 2.0 Richtlinien für Resource Server zur Verfügung. Durch diese Richtlinien wird unter anderem die korrekte Überprüfung der Gültigkeit von Access Tokens, sowie die Unterstützung von Mechanismen zur Absender-Beschränkung von Access Tokens gewährleistet (siehe 5.3.3).

 

Weitere Vorgaben zu Best Practices, Metadaten und Features

FAPI 2.0 stellt ebenfalls Richtlinien zur Einhaltung von weiteren Security Best Practices zur Verfügung.  So dürfen beispielsweise keine Open Redirect APIs vorhanden sein, der aud Claim muss den Issuer Identifier des Authorization Servers enthalten und Refresh Token Rotation darf nicht immer verwendet werden (siehe Punkt 7, 8 und 10 in 5.3.1.1).
Bezüglich einer sicheren Weiterleitung definiert die FAPI 2.0 weiterhin, dass die URIs das HTTPS Schema verwenden müssen und, dass statt des unsicheren HTTP Status Codes 307, der HTTP Status Code 303 bei Weiterleitungen eingesetzt werden muss (siehe Punkt 8, 10 und 11 in 5.3.1.2.).

Wie das Baseline Profile von FAPI 1.0 muss auch im FAPI 2.0 Security Profile der Authorization Server entweder OpenID Connect Discovery oder OAuth 2.0 Authorization Server Metadata unterstützen, um Metadaten bereitzustellen (siehe Punkt 1 in 5.3.1.1).

Zudem wird empfohlen, Rich Authorization Requests (RAR) zu unterstützen, falls der scope Parameter nicht ausreicht, um alle Details der Autorisierungsanfrage festzulegen (siehe Punkt 4 in 5.1). Die RAR-Erweiterung ist zum Beispiel notwendig, um die Freigabe von individuellen Zahlungen im Finanzkontext zu ermöglichen.

 
 

Welche zusätzlichen Schutzmaßnahmen bietet das FAPI 2.0 Message Signing Addon?

Das FAPI 2.0 Message Signing Addon definiert weitere Sicherheitsmaßnahmen, welche die einzelnen Nachrichten eines Protokollflusses vor Manipulationen schützen, um somit auch Hochrisiko-APIs optimal zu schützen. Kernelemente des überarbeiteten Message Signing Addons beinhalten die verpflichtende Verwendung von diversen OAuth Spezifikationen, welche das Signieren der spezifischen Nachrichten definieren. Dadurch wird das zusätzliche Sicherheitsziel “Non-Repudiation” erreicht. Das bedeutet der Sender einer Nachricht kann nicht abstreiten, Urheber der Nachricht zu sein.

Um den Authorization Request abzusichern, müssen, wie bereits im FAPI 1.0 Advanced Profile, die PAR- und JAR-Erweiterungen eingesetzt werden. Zudem müssen der aud, der nbf und der exp Claim im Request Object vorhanden sein und festgelegte Werte enthalten (siehe 5.3).

Für das Absichern der Authorization Response muss JARM verwendet werden (siehe 5.4). Im Gegensatz zu dem FAPI 1.0 Advanced Profile wird ein signierten ID Tokens in der Authorization Response des Hybrid Flows nicht mehr die alternative Lösung unterstützt. Zusätzlich sieht das Message Signing Addon vor, dass die Antworten der Token Introspection durch ein JWT abgesichert werden (siehe 5.5).
Um die Kommunikation zwischen Resource Server und Client abzusichern, können zusätzlich auch die Resource Requests und Responses mithilfe von HTTP Message Signing signiert werden (siehe 5.6).

 

Tabellarischer Vergleich der Profile von FAPI 1.0 und FAPI 2.0

In der nachfolgenden Tabelle werden die Gemeinsamkeiten und Unterschiede der verschiedenen Profile von FAPI 1.0 und FAPI 2.0 noch einmal dargestellt.

 

 Features FAPI 1.0
Baseline
FAPI 1.0
Advanced
FAPI 2.0
Security
FAPI 2.0
Message Signing

Public Clients

Ja

Nein

Nein

Nein

Confidential Clients

Ja

Ja

Ja

Ja

Code Flow

Ja

Ja

Ja

Ja

Hybrid Flow

Ja

Ja

Nein

Nein

Signierte Authorization Requests (JAR)

Nein

Ja

Nein

Ja

Pushed Authorization Requests (PAR)

Nein

Optional

Ja

Ja

Rich Authorization Requests (RAR)

Nein

Nein

Optional

Optional

Signierte Authorization Response (JARM)

Nein

Ja

Nein

Ja

Signierte Authorization Response
(ID Token as detached Signature)

Nein

Ja

Nein

Nein

Signierte Token Introspection Responses

Nein

Nein

Nein

Ja

Signierte Resource Requests und Responses

Nein

Nein

Nein

Ja

Absender-beschränkte Access Tokens (mTLS)

Nein

Ja

Ja

Ja

Absender-beschränkte Access Tokens (DPoP)

Nein

Nein

Ja

Ja

state (oder nonce)

Ja

Ja

Nein

Nein

PKCE

Ja

Optional

Ja

Ja

 

Fazit

Abschließend lässt sich sagen, dass sich der Schutz der unterschiedlichen FAPI Profile merkbar unterscheidet. Das FAPI 1.0 Advanced Profile und das FAPI 2.0 Message Signing Addon bieten bewusst mehr Schutz als das FAPI 1.0 Baseline Profile und das FAPI 2.0 Security Profile. Zudem limitiert die FAPI 2.0 die möglichen Sicherheitskonfigurationen, was zu einer höheren Interoperabilität führt und den Implementierungsprozess gleichzeitig einfacher und sicherer macht. Die FAPI 2.0 greift auf neue Sicherheitsmaßnahmen zurück, welche zum Veröffentlichungszeitpunkt von FAPI 1.0 noch nicht spezifiziert oder verbreitet waren.

 


 

Blogserie – FAPI verstehen – Alle Beiträge im Überblick

Teil #01Wie werden mit der FAPI im Finanzsektor hochsichere APIs realisiert?

Teil #02Was steckt hinter der FAPI – ein Überblick

Teil #03Wie unterscheidet sich der Schutz der FAPI 1.0 Profile?

Teil #04 – Wie unterscheidet sich FAPI 2.0 von FAPI 1.0?

 

Folgen Sie uns auf Twitter und verpassen Sie keinen unserer zukünftigen Blogposts mehr.

 


 

Unsere Experten entwickeln die optimale Lösung für Sie

APIs – OAuth – FAPI

Stehen Sie vor der Entscheidung, wie Sie Ihre APIs und Kundendaten optimal schützen können? Oder verwenden Sie OAuth bereits und fragen sich, ob Ihre Implementierung sicher ist?

Wir beraten Sie gerne; kontaktieren Sie uns für eine unverbindliche Erstberatung. So stehen wir Ihnen mit folgenden Services und Lösungen zur Seite:

IT-Sicherheitsberatung  |  Schulungen   |  Penetrationstests

Zögern Sie nicht und finden Sie mit uns Ihren Weg zu sicheren APIs. Wir freuen uns darauf Sie bei Ihren Projekten zu unterstützen.

 

Ihr Ansprechpartner für OAuth und sichere API

Dr. Christian Mainka
christian.mainka@hackmanit.de