Zum Inhalt springen

Open Finance · OAuth · FAPI

OAuth 2.0 / FAPI-Konformität

OAuth 2.0 mit Authorization Code Grant, PKCE, restriktiven Scopes, Token Rotation und FAPI-konformer Implementierung für PSD2- und FIDA-Schnittstellen.

Hinweis: Diese Seite ist eine Umsetzungshilfe und ersetzt keine Rechtsberatung oder verbindliche aufsichtsrechtliche Auslegung.

Management-Zusammenfassung

  • OAuth 2.0 Authorization Code Grant + PKCE ist der verbindliche Standard für Open-Finance-APIs.
  • FAPI 1.0 (Final) und FAPI 2.0 Security Profile definieren erweiterte Sicherheitsanforderungen.
  • Token Rotation, restriktive Scopes und Redirect-URI-Validierung sind Pflicht.

Authorization Code Grant + PKCE

Der Authorization Code Grant mit PKCE (Proof Key for Code Exchange) ist der empfohlene OAuth-Flow für Open-Finance-APIs. PKCE verhindert Authorization-Code-Interception-Angriffe und ist auch für vertrauliche Clients verbindlich.

  • PKCE mit S256-Challenge (nicht Plain)
  • Keine Implicit-Grant- oder Resource-Owner-Password-Flows
  • Authorization Codes nur einmal verwendbar, kurze Gültigkeit (≤ 60 Sekunden)

Restriktive Scopes

Definieren Sie granulare, minimal-notwendige OAuth-Scopes für jeden API-Endpunkt. Vermeiden Sie Catch-All-Scopes wie „read" oder „write" ohne weitere Einschränkung.

  • Scopes pro Ressource und Operation (z. B. accounts:read, payments:initiate)
  • Scope-Validierung bei jedem Request, nicht nur bei Token-Ausstellung
  • Regelmäßiges Scope-Audit zur Vermeidung von Scope-Creep

Token Rotation und Lebensdauer

Implementieren Sie Token Rotation für Refresh Tokens und begrenzen Sie die Lebensdauer aller Token-Typen strikt.

  • Access Token: maximal 15 Minuten Gültigkeit
  • Refresh Token Rotation: bei jeder Verwendung neues Token, altes ungültig
  • Refresh Token maximale Lebensdauer: 90 Tage mit Inactivity-Timeout

FAPI Security Profile

Das Financial-grade API (FAPI) Security Profile der OpenID Foundation definiert erweiterte Sicherheitsanforderungen für Finanz-APIs.

  • FAPI 1.0 Final: JWS-Signatur für Request Objects, mTLS oder private_key_jwt für Client-Authentifizierung
  • FAPI 2.0: PAR (Pushed Authorization Requests), DPoP (Demonstration of Proof-of-Possession)
  • CIBA: Client-Initiated Backchannel Authentication für decoupled Flows

Redirect-URI-Validierung

Validieren Sie Redirect-URIs strikt gegen eine Whitelist. Verwenden Sie exakte Übereinstimmung (keine Substring- oder Pattern-Matches) und erlauben Sie keine Wildcards. Prüfen Sie Redirect-URIs bei jeder Authorization-Request und bei Token-Ausstellung.