FAPI 2.0 für Banken: DPoP bindet jeden API-Call

Michael Pattison, Principal Solutions Engineer bei Okta, präsentiert sich in einem grauen Anzug mit einem karierten Hemd. Sein Blick ist direkt und neutral. Die Darstellung vermittelt Professionalität und Expertise im Bereich DPoP und Sicherheitsarchitektur. — Michael Pattison, Principal Solutions Engineer, OktaOkta

Michael Pattison ist Principal Solutions Engineer Auth0 bei Okta. Er arbeitet dort, wo FAPI 2.0, DPoP, mTLS und Fine-Grained Authorization in echte Security-Architektur übersetzt werden. Im Interview erklärt er, woran Banken, Versicherer und regulierte FinTechs beim Umstieg scheitern können: Schlüsselmanagement, Public Clients und Token-Bindung. Und er zeigt, wie sich KI-Agenten technisch begrenzen lassen, bevor sie mit gültigen Tokens zu viel dürfen.

von Michael Hülskötter

Herr Pattison, wo steht Auth0 beim FAPI 2.0 Security Profile – und was sind die echten Stolpersteine beim Umstieg von FAPI 1.0 Advanced?

DFAPIer entscheidende Hebel in FAPI 2.0 ist Sender-Constraining: Tokens werden kryptografisch an genau den Client gebunden, der sie angefordert hat – Diebstahl und Replay laufen damit ins Leere. Auth0 unterstützt hierfür zwei Mechanismen: mTLS und DPoP.

Die Grafik erläutert sieben Missverständnisse und Wahrheiten über FAPI, insbesondere die Rolle von DPoP. Sie verdeutlicht, dass FAPI 2.0 eine umfassende Neugestaltung ist, die auf den Lehren aus FAPI 1.0 basiert und hohe Sicherheits — 7 gängige FAPI-Missverständnisse Okta Inc

Der eigentliche Paradigmenwechsel erfolgt dabei durch DPoP: Während FAPI 1.0 stark auf transportgesichertes mTLS auf Infrastrukturebene setzte, verlagert DPoP die Bindung über asymmetrische Kryptografie und signierte JWTs auf den Application-Layer. Jeder API-Call enthält einen frisch signierten Proof, und das Token wird über den Confirmation-Claim an den öffentlichen Schlüssel des Clients gebunden. Genau deshalb ist DPoP gerade für Financial-Grade- und High-Security-APIs empfehlenswert.

Die echten Stolpersteine auf der anderen Seite existieren an drei Stellen: Erstens, das Private-Key-Handling, denn die Schlüssel müssen Hardware-gestützt und nicht exportierbar gespeichert werden, sonst fällt die Sicherheitsarchitektur in sich zusammen. Zweitens, bei Public Clients wie Single Page Apps der Nonce-Challenge-Flow, denn ohne Nonce antwortet der Authorization Server mit einer entsprechenden Aufforderung. Das hätte zur Folge, dass der Client neu signieren und erneut anfragen muss, was eine zweite Anfrage nach sich zieht und eingeplant werden will.

Michael Pattison, Principal Solutions Engineer, Okta

Michael Pattison, Principal Solutions Engineer bei Okta, präsentiert sich in formeller Kleidung. Der Hintergrund ist neutral gehalten, was den Fokus auf seine Person lenkt. Seine Mimik vermittelt Professionalität und Kompetenz im Bereich Customer Identity and Access Management.

Michael Pattison ist Principal Solutions Engineer bei Okta (Website). Zuvor war er als Senior Solutions Consultant bei Okta/Auth0 tätig und begleitete Unternehmen insbesondere im Bereich Customer Identity and Access Management (CIAM). Weitere Stationen seiner Laufbahn umfassen Appian, CA Technologies, SAP und Hewlett-Packard. Seine Ausbildung absolvierte er als IT-Systemelektroniker mit Schwerpunkt IT-Software und -Hardware.

Drittens, die Schlüssel-Persistenz, denn verliert eine langlebige SPA ihr Schlüsselpaar, dann wird das gebundene Token ungültig. Es braucht daher eine Migration Client für Client.

Und wie verhindern Sie, dass ein KI-Agent mit einem gültigen Token zur Lateral-Movement-Maschine wird?

Über zwei Ebenen: Token-Bindung und Fine-Grained Authorization.

Zum einen DPoP: Wenn ein in die Anwendung integrierter KI-Agent eine fremde API im Namen des Nutzers aufruft, kann der Resource Server kryptografisch verifizieren, dass die Anfrage tatsächlich von diesem Agenten stammt, statt von einem unbefugten Dritten.

Ein abgegriffenes Bearer-Token nützt einem Angreifer nichts mehr – ohne den privaten Schlüssel ist es schlicht wertlos.“

Zum anderen – und das ist der eigentliche Hebel gegen Excessive Agency – Fine-Grained Authorization: Statt grobe Rollen zu vergeben, modellieren wir relationship-based, was ein KI-Agent konkret darf – pro Ressource, pro Objekt, pro Beziehung. In RAG-Pipelines erzwingt das eine Zugriffskontrolle auf Dokumentenebene und prüft bereits vor dem Abruf der Daten, ob der Nutzer die abgerufenen Daten überhaupt einsehen darf.

Schematische Darstellung des Prozesses zwischen Client-Anwendung und Autorisierungsserver unter Verwendung von DPoP. Der Ablauf umfasst die Generierung eines Schlüsselpaares, die Erstellung eines DPoP-Proofs, die Token-Anforderung und die Validierung des DPoP-Proofs. — Schematische Darstellung der Beziehung zwischen Client und Autorisierungs-Server unter DPoP Okta Inc.

Damit ersetzen wir breite Berechtigungen durch präzise, nachprüfbare Entscheidungen. Der klassische Confused-Deputy-Angriff – bei dem ein Agent systematisch fremde Ressourcen abfragt – verpufft, weil jede Beziehung einzeln geprüft wird.

Entscheidend ist dabei die Kombination: DPoP beweist, wer zugreift, während Fine-Grained Authorization entscheidet, worauf. Das ist die Leitplanke, innerhalb der ein autonomer KI-Agent agieren darf und außerhalb der er schlicht nichts ausrichten kann.“

Herr Pattison, vielen Dank für das Gespräch.Michael Hülskötter