Dieses Dokument ist ein früher Entwurf (Early Draft) und befindet sich noch in der aktiven Bearbeitung und Abstimmung bezüglich des D-Stacks. Quelle ist die öffentliche Konsultation (v1.0, 19.03.2026 – 16.04.2026) des Projekts „Föderale API-Autorisierungsinfrastruktur" von Sachsen-Anhalt und FITKO.
Erstellt am: 16. April 2026 | Zuletzt geändert: 17. April 2026 | Autor: BMDS-Architekturteam | Quelle: gitlab.opencode.de/sachsen-anhalt/mid/foederale-api-autorisierungsinfrastruktur
public Föderale API-Autorisierungsinfrastrukturfeedback
Das Projekt „Föderale API-Autorisierungsinfrastruktur" (Sachsen-Anhalt / FITKO) liefert den bisher fehlenden verbindlichen Standard-Unterbau für die Absicherung föderaler Basisdienst-APIs. Es ergänzt den API-Management-Baustein um den konkreten Sicherheits- und Autorisierungslayer und wird voraussichtlich in der Sommersitzung 2026 des IT-Planungsrats verabschiedet.
info 1. Einordnungfeedback
Die föderale API-Autorisierungsinfrastruktur adressiert eine Lücke, die weder die GovStack-Specs noch SCS allein schließen können: verbindliche, formal geprüfte Sicherheitsprofile für M2M-APIs in einer föderalen Verwaltungslandschaft und eine zweistufige Berechtigungsarchitektur zwischen zentraler Plattform und dezentralen Fachverbünden.
Kernbeitrag zum D-Stack:
- Sicherheitsprofile nach Schutzbedarf (normal / hoch / sehr hoch), die die Lücke zwischen abstraktem BSI-Grundschutz und konkreter Protokoll-Konfiguration schließen.
- Verbindliche Autorisierungsstandards (OAuth 2.0 / OAuth 2.1 + qualifiziertes FAPI 2.0-Profil, DPoP,
private_key_jwt). OAuth 2.1 sollte als Mindeststandard für alle Schutzbedarfe festgeschrieben werden, da es unsichere Grant Types (Implicit, Password) entfernt und PKCE für alle Clients verpflichtend macht. - Föderale Berechtigungsarchitektur mit zentraler Plattform (FöPD) und dezentralen Policy Decision Points.
- Revisionssichere Protokollierung über ein Merkle-Tree-basiertes Transparency Log.
- Übergreifendes Monitoring via Shared Signals Framework (SSF) der OpenID Foundation.
2. Projektstruktur und Artefaktefeedback
Das Projekt-Repository gliedert sich in sechs inhaltliche Säulen:
| Bereich | Inhalt |
|---|---|
| Vorgaben | Sicherheitsprofile Schutzbedarf normal (RFC 9700) und hoch/sehr hoch (FAPI 2.0) inkl. Angreifer-Modelle |
| Architekturprinzipien | 15 normierende Leitprinzipien (Zero Trust, Least Privilege, Open-Source-Priorisierung, …) |
| Anforderungen | Konsolidierte funktionale und nicht-funktionale Anforderungen |
| Architekturentscheidungen | 22 ADRs mit Optionenvergleich (OAuth-Standard, DPoP, ReBAC, Transparency Log, …) |
| Zielarchitektur | 9 Kapitel: Geschäftsarchitektur, IT-Architektur, Berechtigungskonzept, SSF-Monitoring, Revisionssicherheit, Transition, Roadmap |
| Glossar | Projektweit einheitliche Begriffsdefinitionen |
security 3. Sicherheitsprofile nach Schutzbedarffeedback
Die Vorgaben differenzieren strikt nach Schutzbedarf und verwenden dafür unterschiedliche, etablierte Industriestandards:
Schutzbedarf normalfeedback
- Basis: RFC 9700, Best Current Practice for OAuth 2.0 Security
- Mindestanforderungen und empfohlene Sicherheitspraktiken
- Angreifer-Modell explizit dokumentiert (BCP Attacker Model)
- Für den Großteil der Verwaltungs-APIs ausreichend
- D-Stack-Empfehlung: OAuth 2.1 als verbindliche Baseline, da es PKCE verpflichtend macht, Implicit Grant und Password Grant entfernt sowie Refresh Token Rotation vorschreibt
4. Zentrale Architekturentscheidungen (Auszug)feedback
| ADR | Entscheidung | Begründung |
|---|---|---|
| ADR-001 | OAuth 2.0 mit qualifiziertem FAPI 2.0-Profil | Weit verbreitet, formal analysiert, OpenID-zertifizierte Implementierungen |
| ADR-002 | private_key_jwt für Client-Authentifizierung | Auf Applikationsebene umsetzbar, keine PKI-Abhängigkeit, FAPI-konform |
| ADR-003 | DPoP für Sender-Constraining | Keine zusätzliche PKI nötig, breite Client-Unterstützung |
| ADR-008 | Zweistufige Berechtigungsarchitektur | Grobgranular zentral (Plattform) / feingranular dezentral (Fachverbund) |
| ADR-009 | ReBAC für zentrale Regeladministration | Bildet föderale Organisationsbeziehungen natürlich ab |
| ADR-015/016 | BundID für natürliche, Mein Unternehmenskonto für juristische Personen | Etablierte staatliche Identifikationssysteme, eIDAS-anschlussfähig |
| ADR-017/021 | Transparency Log (Merkle-Tree, tlog-tiles) | Manipulationssichere Nachvollziehbarkeit ohne zentrale Kontrollinstanz |
| ADR-020 | Zentrales Log personen- und organisationsfrei | DSGVO-konform; Personenbezug nur in lokalen Audit-Logs |
5. Systemlandschaft der Zielarchitekturfeedback
Die Zielarchitektur trennt vier Systemgruppen klar voneinander:
Zentrale Komponenten:
- FöPD (Föderales Plattform Directory): Self-Service-Portal und Single Source of Truth für Organisationen, Software, Clients, Policies und Attributkatalog.
- FöPD Identity Provider: Aggregiert Identitäten aus BundID, MUK und föderierten IdPs.
- Zentrale Policy Infrastruktur: Kanonische Quelle aller Policies; wird von den dezentralen PDPs repliziert.
- Transparency Log: Manipulationssicherer Prüfpfad (Merkle-Tree,
c2sp.org/tlog-tiles). - SSF-Monitoring: Aggregiert Security Event Tokens und stellt Risikosignale bereit.
Dezentrale Komponenten je Basisdienst: Authorization Server, API-Gateway (PEP), Policy Decision Point (PDP), SSF-Transmitter-Adapter.
info 6. Einordnung in das BMDS-Portalfeedback
Die Föderale API-Autorisierungsinfrastruktur ist querschnittlich relevant. Sie konkretisiert mehrere bestehende BMDS-Artefakte:
| Föderale API-Autorisierungsinfrastruktur | Bestehendes BMDS-Artefakt |
|---|---|
| Sicherheitsprofile Schutzbedarf normal / hoch / sehr hoch | Sicherheit & Compliance, konkretisiert BSI-Grundschutz für API-Ebene |
| 15 Architekturprinzipien | Kernprinzipien, API-spezifische Ausprägung |
OAuth 2.0 / FAPI 2.0 / DPoP / private_key_jwt | API-Management |
| FöPD-IdP, BundID, MUK, SCIM, EUDI Wallet | Identität & Zugang (IAM) |
| ReBAC, PDP/PIP, OPA/Cedar, Policy-as-Code | Zero-Trust Policy Engine |
private_key_jwt, mTLS, Software Statement Assertions | Machine Identity |
| Shared Signals Framework, Security Event Tokens | SIEM & SOC / Anomalie-Erkennung |
| Transparency Log (tlog-tiles, Merkle-Tree) | Audit Trail & Compliance Log |
| Föderale Zielarchitektur für Basisdienste | Fachanwendungen absichern, direkter Umsetzungspfad |
warning 7. Kritischer Vergleich mit Markt-Funktionsbausteinenfeedback
Um die Vollständigkeit der Föderalen API-Autorisierungsinfrastruktur zu bewerten, werden ihre Funktionsbausteine systematisch gegen die Fähigkeiten führender API-Management-Plattformen gespiegelt. Die folgende Analyse basiert auf der API-Tools- und Plattformübersicht.
7.1 Funktionsbausteine aus dem Markt abgeleitetfeedback
Aus den Fähigkeiten der fünf führenden Plattformen (Apigee, AWS API Gateway, Azure APIM, Kong Enterprise, MuleSoft) und den Open-Source-Tools (Swagger, Bruno, Hoppscotch, Insomnia, Redocly) lassen sich acht zentrale Funktionsbausteine für ein vollständiges API-Ökosystem ableiten:
| Nr. | Funktionsbaustein | Beschreibung |
|---|---|---|
| F1 | API Gateway & Traffic Management | Routing, Rate Limiting, Load Balancing, Circuit Breaker, Canary/Blue-Green |
| F2 | Authentifizierung & Autorisierung | OAuth 2.0, OIDC, mTLS, API-Keys, RBAC/ABAC, Policy Engine |
| F3 | API Lifecycle Management | Design-First (OpenAPI), Versionierung, Deprecation, Environments |
| F4 | Developer Portal & Self-Service | API-Katalog, Try-it-out, SDK-Generierung, Self-Service-Registrierung |
| F5 | Observability & Analytics | Logging, Metriken, Distributed Tracing, SLA-Monitoring, Anomalie-Erkennung |
| F6 | API Testing & Qualitätssicherung | Contract Testing, Mocking, Load Testing, Security Scanning |
| F7 | Integration & Transformation | Protokollkonversion, Mediation, Event-driven APIs (AsyncAPI, Webhooks) |
| F8 | Governance & Compliance | Audit Trail, Policy-as-Code, Revisionssicherheit, Datenschutz-Compliance |
7.2 Deckungsvergleich: Föderale API-Autorisierungsinfrastruktur vs. Marktfeedback
Legende: ● vollständig abgedeckt · ◔ teilweise abgedeckt · ○ nicht adressiert
| Funktionsbaustein | Föderale API-Infra | Apigee | AWS API GW | Azure APIM | Kong | MuleSoft |
|---|---|---|---|---|---|---|
| F1 API Gateway & Traffic | ◔ | ● | ● | ● | ● | ● |
| F2 AuthN & AuthZ | ● | ● | ◔ | ● | ● | ● |
| F3 API Lifecycle | ○ | ● | ◔ | ● | ◔ | ● |
| F4 Developer Portal | ◔ | ● | ○ | ● | ● | ● |
| F5 Observability | ◔ | ● | ● | ● | ● | ● |
| F6 API Testing | ○ | ◔ | ○ | ◔ | ○ | ● |
| F7 Integration & Transformation | ○ | ● | ◔ | ● | ◔ | ● |
| F8 Governance & Compliance | ● | ◔ | ○ | ◔ | ◔ | ◔ |
7.3 Kritische Analysefeedback
Wo die Föderale API-Autorisierungsinfrastruktur dem Markt voraus ist:
- Formale Sicherheitsanalyse (F2, F8): Kein kommerzieller Anbieter liefert ein formal analysiertes, nach Schutzbedarf differenziertes Sicherheitsprofil. FAPI 2.0 mit DPoP und
private_key_jwtgeht über die Standard-OAuth-Implementierungen von Apigee, Kong etc. deutlich hinaus. - Föderale Berechtigungsarchitektur (F2): Die zweistufige Autorisierung (grobgranular zentral / feingranular dezentral) adressiert ein Problem, das kommerzielle Plattformen nicht kennen; sie sind für einzelne Organisationen konzipiert, nicht für föderale Strukturen mit 16 Ländern + Bund + Kommunen.
- Transparency Log (F8): Kein Marktprodukt bietet ein Merkle-Tree-basiertes, manipulationssicheres Transparency Log. Apigee/Azure bieten Audit Logs, aber ohne kryptographische Integritätsgarantie.
- SSF-Monitoring (F5): Die Nutzung des Shared Signals Frameworks als föderale Signalschicht ist einzigartig; kommerzielle Plattformen beschränken sich auf interne Metriken.
Wo der Markt Fähigkeiten bietet, die der Föderalen API-Infrastruktur fehlen:
- API Lifecycle Management (F3): Die Föderale API-Infrastruktur macht keine Aussagen zu Design-First-Ansätzen, Versionierungsstrategien, Deprecation-Policies oder OpenAPI-Spezifikationsmanagement. Dies ist ein strukturelles Defizit, da verbindliche Vorgaben zum API-Design für Interoperabilität entscheidend sind. Empfehlung: Ergänzung durch den API-Management-Baustein und Aufnahme von OpenAPI-3.1-Pflicht in die Vorgaben.
- API Testing & Qualitätssicherung (F6): Kein Wort zu Contract Testing, Mocking oder automatisierten Sicherheitsscans. In einer föderalen Landschaft mit Dutzenden Basisdiensten ist die Frage „Wie stelle ich sicher, dass meine API-Implementation die Spezifikation einhält?" unbeantwortet. Empfehlung: Vorgabe von Conformance-Testsuite (analog zur FAPI-2.0-Zertifizierung) und Referenzierung von Pact / Schemathesis als Tooling.
- Integration & Transformation (F7): Keine Adressierung von Protokollkonversion (REST ↔ SOAP, was in der Verwaltung hochrelevant ist), Mediation oder Event-driven APIs. Empfehlung: Klare Abgrenzung: Die Föderale API-Infrastruktur sichert APIs ab, transformiert sie aber nicht. Die Verantwortung liegt bei den Basisdiensten oder dem API-Gateway.
- Developer Experience (F4): Das FöPD übernimmt Teile eines Developer Portals (Client-Registrierung, Software Statement Assertions), bietet aber keine interaktive API-Dokumentation, kein Try-it-out und keine SDK-Generierung. Empfehlung: FöPD um einen API-Katalog mit OpenAPI-Rendering erweitern oder die Verantwortung an die Basisdienste delegieren und als Anforderung in ADR-018 verankern.
Zusammenfassende Bewertung:
Die Föderale API-Autorisierungsinfrastruktur ist bewusst eng geschnitten auf Autorisierung und Sicherheit; das ist ihre Stärke und gleichzeitig ihre Grenze. Sie ersetzt kein vollständiges API-Management, sondern liefert den Sicherheits- und Governance-Layer, der den kommerziellen Plattformen fehlt. Für ein vollständiges API-Ökosystem im D-Stack muss sie mit den Fähigkeiten des API-Management-Bausteins und der API-Tools-Übersicht komplementiert werden.
rate_review 8. Bewertungfeedback
Stärkenfeedback
- Industriestandard-Treue statt Eigenbau: OAuth 2.0 + FAPI 2.0, DPoP, OIDC, SCIM, SSF, AuthZEN. Deckt sich mit dem Prinzip „Offene Industriestandards nutzen".
- ADR-Disziplin: 22 nachvollziehbar begründete Architekturentscheidungen mit Optionenvergleich; vorbildhaft im deutschen Verwaltungskontext.
- Formale Sicherheitsanalyse: Explizite Verweise auf das FAPI-Angreifer-Modell, differenzierte Profile nach Schutzbedarf. Schließt eine Lücke, die BSI-Grundschutz allein nicht füllt.
- Klare Subsidiarität: Zweistufige Autorisierung respektiert föderale Verantwortung; PDP-Externalisierung ist optional, nicht erzwungen.
- Revisionssicherheit by Design: Transparency Log und Trennung personenfreies zentrales Log / lokale Audit-Logs sind DSGVO-konform und auditierbar.
- Offene Konsultation: Transparenter Entwicklungsprozess auf openCode mit Issue-basiertem Feedback; übertragbares Muster für weitere föderale Projekte.
Schwächen / Risikenfeedback
- Offene Governance-Fragen (Kapitel 7 der Zielarchitektur): PKI-Betrieb, gemeinsame Governance-Struktur und Behörden-IdP-Anbindung sind explizit ungeklärt; kritischer Pfad vor Sommersitzung 2026.
- Policy-Sprache noch offen: Entscheidung zwischen DMN, OPA/Rego und Cedar verschoben; fundamentale Interoperabilitätsfrage, blockiert die Replikationsmechanik zentral → dezentral.
- Breite der FAPI-Profilierung: „FAPI 2.0 + qualifiziertes Profil" erhöht Lock-in auf wenige zertifizierte Implementierungen; die praktische Abdeckung im Verwaltungskontext ist enger als im Banken-Umfeld.
- Betriebskomplexität: Dezentraler Betrieb von AuthZ-Server + API-Gateway + PDP + SSF-Adapter je Basisdienst verlangt DevSecOps-Reife, die bei vielen Ländern/Kommunen nicht gegeben ist. Kein expliziter „Managed-Service"-Pfad dokumentiert.
- EUDI-Wallet / eIDAS 2.0 unterrepräsentiert: In den ADRs bisher nicht ausreichend verankert; kurzfristiger Ergänzungsbedarf angesichts der eIDAS-2.0-Fristen.
- Scope-Begrenzung (ADR-019): Zentrale Nutzerautorisierung initial nur für Verwaltungskunden; Beschäftigte ausgeschlossen, obwohl Ressort-SSO-Bedarf dringlich ist.
- Fehlende API-Lifecycle- und Testing-Vorgaben: Wie im Marktvergleich dargelegt, fehlen verbindliche Aussagen zu Design-First, Versionierung, Contract Testing und Conformance-Suites.
- OAuth 2.1 als Mindeststandard nicht festgeschrieben: Die Vorgaben referenzieren OAuth 2.0 und OAuth 2.1, legen aber für den Schutzbedarf normal nicht fest, ob OAuth 2.1 als Mindeststandard verpflichtend wird. Da OAuth 2.1 die unsicheren Grant Types (Implicit, Password) entfernt und PKCE für alle Clients vorschreibt, sollte es als verbindliche Baseline für alle Schutzbedarfe gelten. FAPI 2.0 setzt diese Härtungen implizit voraus, aber Basisdienste mit Schutzbedarf normal könnten ohne explizite Vorgabe weiterhin unsichere Konfigurationen verwenden.
Gesamt-Einschätzungfeedback
Die Dokumentation ist inhaltlich hochwertig, standardtreu und methodisch vorbildlich (ADR-getrieben, formal fundiert). Sie liefert für den D-Stack die bisher fehlende verbindliche Ausprägung der IAM- und API-Management-Bausteine auf der Ebene konkreter Protokolle und Profile. Der Marktvergleich zeigt jedoch, dass sie ein vollständiges API-Management nicht ersetzt, sondern als spezialisierter Sicherheits- und Governance-Layer komplementiert werden muss.
Das Projekt sollte als verbindliche Referenzarchitektur für den API-Sicherheitslayer in den D-Stack übernommen werden, sobald der IT-Planungsrat in seiner Sommersitzung 2026 entschieden hat. Bis dahin:
- Tracking der offenen Governance-Punkte (Policy-Sprache, PKI-Governance, EUDI-Integration) als eigene D-Stack-Roadmap-Einträge.
- Ergänzung um API-Lifecycle- und Testing-Vorgaben in Abstimmung mit dem API-Management-Baustein und der API-Tools-Übersicht.
- Frühzeitige Abstimmung mit den BMDS-Bausteinen Zero-Trust Policy Engine, Machine Identity und API-Management.
arrow_forward 9. Weiterführende Quellenfeedback
- Projekt-Repository: gitlab.opencode.de/sachsen-anhalt/mid/foederale-api-autorisierungsinfrastruktur
- FAPI 2.0 Security Profile: OpenID Foundation
- RFC 9700: Best Current Practice for OAuth 2.0 Security
- Shared Signals Framework (SSF): OpenID Foundation
- Transparency Log Tiles: c2sp.org/tlog-tiles
- API-Tools und Plattformen im Vergleich