API-Sicherheit: PoPP-Token-Abhängigkeit – Fehlende Fehlerbehandlung und Sicherheitsrisiken durch OAuth2

[Sascha-Block]

Die API erfordert ein PoPP-Token im Header, um auf Versichertenstammdaten zuzugreifen.

paths:
  /vsdservice/v1/vsdmbundle:
    get:
      summary: "Returns a VSDMBundle for the specified patient."
      description: "Returns a VSDMBundle with VSD about a specific patient that is addressed within the PoPP-Token in the request header."

Das Token wird durch einen HTTP-Proxy validiert und im Header ZETA-PoPP-Token-Content an den Resource-Server weitergereicht.

❗ Unklar: Welche Fehlerbehandlung erfolgt, wenn PoPP-Tokens fehlen, inkorrekt sind oder falsch validiert werden?

❗ Wie robust ist die Implementierung gegen Replay-Attacken oder Man-in-the-Middle-Szenarien?
Die aktuelle API-Sicherheit basiert auf OAuth2:

security:
  - oAuthVsdm: ["vsdservice"]

🚨 Kritische Punkte zur Sicherheitsarchitektur:

👉 OAuth2 ist ein überalterter Standard und wurde ursprünglich nicht für föderierte Identitäten und moderne Sicherheitsanforderungen entwickelt.
👉 OAuth2 bietet keine integrierte Nutzer-Authentifizierung. Diese Lücke wurde erst mit OpenID Connect (OIDC) geschlossen, das auf OAuth2 aufbaut, aber moderne Authentifizierungsmechanismen bereitstellt.
👉 OAuth2 allein schützt nicht ausreichend vor Man-in-the-Middle- oder Replay-Attacken, insbesondere wenn es um den Transport sensibler Gesundheitsdaten geht.

Die aktuelle Implementierung erfordert ein PoPP-Token im Header, das einen statischen Identitätsnachweis enthält. Falls dieses Token abgegriffen oder wiederverwendet wird, gibt es keinen nativen Schutzmechanismus innerhalb von OAuth2, um Missbrauch zu verhindern.

✅ Vorschlag: Migration zu OpenID Connect (OIDC)

👉 OIDC bietet starke Authentifizierung (z. B. über ID-Tokens) und kann mit FIDO2/WebAuthn kombiniert werden.
👉 OIDC nutzt Proof Key for Code Exchange (PKCE), um OAuth2-Schwächen zu vermeiden.

Durch ID-Tokens mit Nonce-Werten wird die Gefahr von Replay-Angriffen erheblich reduziert.
Die Kombination aus OIDC + PoPP + FHIR-Profiling könnte eine zukunftssichere, interoperable Lösung darstellen.

👉 Frage zur Implementierung:
Warum sollte OAuth2 verwendet werden, wenn OIDC nachweisbar eine modernere und sicherere Lösung für föderierte Identitäten und Zugriffskontrolle bietet?

[HendrikGematik]

Die dpop Unterstützung von OpenAPI wird erst mit einer Folgeversion unterstützt, siehe OAI/OpenAPI-Specification#3613 In der Spec ist dieser Sicherungsmechanismus bereits vorgesehen.