Datenschutz-Information: Authentifizierung über Authentik-IdP

1. Verantwortlicher (Art. 13 §1 lit. a DSGVO)

Verantwortlich für die Verarbeitung deiner personenbezogenen Daten im Rahmen der Authentifizierung ist:

Marcel Clausmeyer (Inhaber, Verantwortlicher i.S.v. Art. 4 Abs. 7 DSGVO)
Condictum
Deutschland

Condictum betreibt Authentik self-hosted im eigenen Hetzner-Cluster (DE/Falkenstein). Bis zur Bestellung eines externen Datenschutzbeauftragten (DSB) nach § 5 BDSG + Art. 37 DSGVO ist Marcel Clausmeyer auch Ansprechpartner für Datenschutz-Anfragen.

2. Auftragsverarbeiter + Empfänger (Art. 13 §1 lit. a/e DSGVO)

• Hetzner Online GmbH (Falkenstein, DE) — Hosting (Hosting-AVV vorhanden). Hetzner hostet die Authentik-Server- + Worker-Pods, die Authentik-Postgres-Datenbank und den Redis-Cache im eigenen Rechenzentrum in Falkenstein (DE).
• HashiCorp Vault (self-hosted) — Crypto-at-Rest-Infrastruktur für die Authentik-Postgres (Field-Level-Encryption via Vault-Transit-Engine). Vault sieht keine Plaintext-PII (Transit-Engine, ADR 0508).
• BeryJu / Tilo Renz (DE-ansässig) — Code-Maintainership des Authentik-Upstream-Source-Codes. BeryJu sieht keine Condictum-Produktionsdaten (reiner Code-Beitrag via GitHub). AVV-Anhang für die Code-Maintainerschaft liegt unter tom/avv/authentik-template.md ([user-gate] — Unterzeichnung steht aus).
• Condictum-Services (intern, 18+ Microservices) konsumieren die von Authentik ausgestellten JWTs (Bearer-Gate ADR 0008) — sie sehen nur die Token-Claims, nicht die Authentik-Datenbank.
• Condictum-BFFs (bff-web, bff-business) — OAuth2-Authorize-Redirect zu Authentik + Token-Exchange. Token-Paar verbleibt in der BFF-Session (Ktor-Session, ADR 0507), nicht im Browser.

3. Verarbeitungstätigkeiten + Zwecke (Art. 13 §1 lit. c DSGVO)

Deine personenbezogenen Daten werden für folgende Authentifizierungs-Zwecke verarbeitet:

• Login via Passwordless (Magic-Link-E-Mail-Stage), Passkey (WebAuthn) oder Passwort (Fallback).
• MFA (Multi-Faktor-Authentifizierung) — TOTP (RFC 6238), WebAuthn-Hardware-Key, Duo-ähnliche Push-Benachrichtigung (Phase 7+, optional), Recovery-Codes (10× Einweg-Code).
• Step-Up-Reauth für sensible Aktionen (z.B. Account-Löschung): Authentik- Authorize mit max_age=0 + acr_values (Passwordless/Passkey, ADR 0522). Ersetzt die historischen 4 Custom-Reauth-Endpoints.
• OAuth2-Authorize-Flow für BFFs, Mobile-App und OAuth-Apps (Tenant-Admin- konfiguriert, ADR 0119/0501).
• Token-Refresh mit Refresh-Token-Family-Rotation (Authentik-Standard).
• Logout via Authentik-End-Session-Endpoint (ADR 0523) — Token-Family-Cleanup durch Authentik.
• Account-Lifecycle: Suspend (reaktivierbar, KEIN Crypto-Shred) und Löschung (terminal, irreversibel — siehe §6 Crypto-Shred-Kaskade).
• Custom-Claim-Enrichment: Das Access-Token wird mit dem fachlichen Claim condictum:verification_level (NONE/PHONE/BANK/IDENTITY, Spec §10.1) angereichert — Quelle ist der interne identity-service-Endpoint, PII-frei per Construction.
• SCIM-Inbound-Webhook: Authentik pushet User-Lifecycle (Create/Update/Delete) an den identity-service — HMAC-SHA256-signiert (ADR 0516).

Zweckbindung: Authentik-Daten werden ausschließlich für die Authentifizierung + Account-Lifecycle verwendet. Kein Marketing, kein Tracking, keine Weitergabe an Dritte zu anderen Zwecken. Audit-Log ausschließlich für Security-Incident-Response und Compliance-Nachweise (§ 147 AO).

4. Datenkategorien (Art. 13 §2 DSGVO)

• E-Mail-Adresse (Login-Identifikator + Kontakt-Weg) — gespeichert in der Authentik-Postgres, Crypto-at-Rest via Vault-Transit.
• Name (vollständiger Name, Display-Zwecke) — Authentik-Postgres, Crypto-at-Rest via Vault-Transit.
• Username (User-gewählt) — Authentik-Postgres.
• Authentifizierungs-Faktoren: Passwort-Hash (Argon2id), TOTP-Seed (RFC 6238, 160-bit, AES-encrypted), WebAuthn-Credentials (Credential-ID, Public-Key, Sign-Counter, AAGUID, Transport, Attestation-Statement), Duo-Push-Token (optional), Recovery-Codes (Argon2id gehashed).
• Authentik-Session: Session-ID, Token-Family (Access/Refresh/ID-Token), Refresh-Token-Family-Metadata (Rotation, Reuse-Detection).
• Prozessdaten: Device-IP, User-Agent, GeoIP (best-effort).
• Audit-Log / Protokollierung: Login-Zeit, Logout-Zeit, MFA-Challenge-Erfolg /-Misserfolg, Step-Up-Trigger, SCIM-Inbound-Events. 10 Jahre Aufbewahrung (§ 147 AO + §17.10 Condictum-Spec).
• OAuth-App-Metadaten (für Tenant-Admin-OAuth-Apps): client_id, client_secret (Argon2id gehashed), Redirect-URIs, Scopes, Custom-Claims.

Art. 9-Abgrenzung (biometrische Daten): Authentik-WebAuthn ist faktorbasiert (Possession-Key), nicht biometrisch. Die lokale Biometrie am Authenticator (Touch ID, Windows Hello) ist client-seitig und verlässt das Gerät nicht — Authentik sieht nur den WebAuthn-Assertion-Response ohne biometrische Rohdaten. → Keine Art. 9-Verarbeitung.

5. Aufbewahrungsfristen + Lösch-Pfad (Art. 13 §2 lit. a DSGVO)

• Audit-Log: 10 Jahre Aufbewahrung (§ 147 AO + §17.10 Condictum-Spec + § 14 BDSG-Log-Tabelle).
• Authentik-User-Record + Auth-Faktoren: Bis Account-Löschung via SCIM (Hard-Delete) — physische Löschung innerhalb von 30 Tagen nach UserDeleted-Event.
• Session + Token-Family: Kurz (Session-TTL 24h, Refresh-Token 30d) — Authentik-Standard.
• Postgres-Backup: 30 Tage rotierend (Hetzner-Standard).
• Redis (Session-Cache, JWKS-Cache): Redis-TTL (kurz).

Lösch-Pfad (Account-Löschung): Du kannst die Löschung deines Accounts über den Condictum-Account-Delete-Endpoint anfordern. Der identity-service sendet einen SCIM-DELETE-Webhook (HMAC-SHA256-signiert) an Authentik → Authentik markiert den User als gelöscht → SCIM-Webhook-Push zurück an identity-service → UserDeleted-Event in Kafka → Crypto-Shred-Kaskade zerstört irreversibel die Condictum-seitigen PII-Heimaten (profile-service etc., ADR 0007). Authentik-Hard-Delete des User-Records erfolgt innerhalb von 30 Tagen (Authentik-seitiger Cleanup-Job).

6. Technische + organisatorische Maßnahmen (TOM, Art. 13 §2 lit. f DSGVO)

• Crypto-at-Rest via Vault-Transit (ADR 0508): Authentik-Postgres nutzt Field-Level-Encryption via Vault-Transit-Engine. DEK (Data Encryption Key) pro Feld, KEK (Key Encryption Key) in Vault, Plaintext-DEK wird nie persistent. Crypto-at-Rest für alle PII-Spalten.
• Crypto-Shred-Kaskade bei Account-Delete (ADR 0007): User-angetragene Löschung triggert SCIM-DELETE → UserDeleted-Event → irreversibler Crypto-Shred aller Condictum-seitigen PII-Ciphertexte (Zerstörung des DEK pro User-Scope).
• NetworkPolicy + Linkerd-mTLS (Plan §1.1, ADR 0152): K8s-NetworkPolicy isoliert Authentik-Server, Authentik-Worker, Authentik-Postgres und Authentik-Redis vom restlichen Cluster — einziger Netz-Weg ist Linkerd-mTLS-Mesh.
• SCIM-Webhook-Signature-Check (ADR 0516): Der identity-service /scim/v2/Users-Inbound-Endpoint prüft jeden SCIM-Webhook via HMAC-SHA256 + Timestamp-Window (300s Replay-Schutz). Fail-closed bei fehlendem/ungültigem Header. Timing-Attack-resistent via konstanter Zeit-Comparison (RFC 6151 §3).
• Anti-Enumeration (ADRs 0025/0059 historisch, weiter gepflegt): Authentik-Email-Stage mit consent_unknown_user=true + konstanter Response-Time. WebAuthn-Stage mit synthetischer Challenge bei unbekanntem User. Bewusst keine 404-/409-Orakel-Responses.
• ProdSecretsGuard (ADR 0057): Dev-Default-Secrets (z.B. shared-secret, admin-password) werden in Prod fail-loud abgewiesen — verhindert versehentlichen Prod-Betrieb mit schwachen Defaults.
• HPA (Horizontal Pod Autoscaler) auf Authentik-Server + Worker — horizontal skalierbar, keine Singleton-Flaschenhälse (Guardrail 3).
• Outpost-pro-Tenant als stateless Deployment (ADR 0509): Pro Tenant ein embedded-proxy-outpost für Vertical-Branding am Login — skaliert linear mit Tenant-Anzahl.
• Audit-Log revisionssicher (§17.10): Authentik schreibt Audit-Events bei jedem Login/Logout/MFA-Challenge/Step-Up/Admin-Aktion. Condictum-anomaly-Detection via audit-service (PII-freie Whitelist, §17.10 + ADR 0064). 10 Jahre Aufbewahrung (§ 147 AO).

Die ausführliche TOM-Dokumentation nach BSI-Grundschutz / ISO 27001 liegt unter tom/tom-docs/; die vollständige DSFA unter tom/dsfa/authentik-idp.md.

7. Übermittlung in Drittländer (Art. 13 §1 lit. f DSGVO)

Keine Übermittlung in Drittländer. Authentik self-hosted im Hetzner-DC Falkenstein (DE), Vault self-hosted im selben Cluster. BeryJu (DE-ansässig) sieht keine Produktionsdaten (nur Code-Beiträge via GitHub, der wiederum GitHub-US-Datenflüsse unterliegt, die aber auf öffentlichen Code beschränkt sind — keine User-Daten). EU/EWR-only.

8. Deine Rechte als betroffene Person (Art. 15–22 DSGVO)

• Art. 15 DSGVO — Auskunftsrecht: Du kannst jederzeit Auskunft über die zu deiner Person verarbeiteten Daten verlangen. Condictum stellt dir auf Anfrage eine strukturierte Aufstellung der Authentik-Datenkategorien zur Verfügung.
• Art. 16 DSGVO — Berichtigung: Du kannst die Berichtigung unrichtiger Daten verlangen (z.B. falsche E-Mail-Adresse, falscher Name).
• Art. 17 DSGVO — Löschung: Du kannst die Löschung deiner Daten verlangen — die Crypto-Shred-Kaskade (siehe §5) zerstört irreversibel alle Condictum-seitigen PII-Heimaten, Authentik-Hard-Delete erfolgt innerhalb von 30 Tagen.
• Art. 18 DSGVO — Einschränkung der Verarbeitung: Du kannst die Einschränkung der Verarbeitung verlangen, wenn die Voraussetzungen des Art. 18 erfüllt sind.
• Art. 20 DSGVO — Datenübertragbarkeit: Du kannst die Übertragbarkeit deiner Daten in einem strukturierten, gängigen und maschinenlesbaren Format verlangen (Datenexport als asynchroner Job, signierter 7-Tage-Link, ADR 0083 Step-Up-Pflicht).
• Art. 21 DSGVO — Widerspruch: Du kannst der Verarbeitung widersprechen, wenn die Voraussetzungen des Art. 21 erfüllt sind (bei Condictum selten einschlägig, weil Authentifizierung vertraglich notwendig ist).
• Art. 22 DSGVO — Automatisierte Entscheidungen: Condictum führt kein Profiling mit Rechtsfolge durch. Custom-Claim-Provider nutzt nur den fachlichen condictum:verification_level (Enum, nicht Score).

Zur Ausübung deiner Rechte wende dich an: Marcel Clausmeyer (Condictum, Verantwortlicher i.S.v. Art. 4 Abs. 7 DSGVO). Du kannst die Privacy-Request-Funktion im eingeloggten Zustand nutzen (Self-Service-Portal, ADR 0083 Step-Up-Pflicht für ERASURE), oder eine Anfrage per E-Mail stellen.

9. Beschwerderecht bei der Aufsichtsbehörde (Art. 77 DSGVO)

Du hast das Recht, dich bei der zuständigen Datenschutz-Aufsichtsbehörde über die Verarbeitung deiner personenbezogenen Daten durch Condictum zu beschweren. Die zuständige Aufsichtsbehörde ist in der Regel diejenige an deinem Wohnsitz oder an Condictums Sitz.

Für Condictum (Verantwortlicher DE-ansässig) ist die zuständige Aufsichtsbehörde der Landesdatenschutzbeauftragte des Bundeslandes, in dem Condictum seinen Sitz hat. Eine Liste der deutschen Datenschutz-Aufsichtsbehörden findest du auf der Website der Konferenz der unabhängigen Datenschutzbehörden des Bundes und der Länder (DSK).

10. Querverweise + weiterführende Doku

• Datenschutz-Folgenabschätzung (DSFA, Art. 35 DSGVO): tom/dsfa/authentik-idp.md — ausführliche Erörterung der Verarbeitungstätigkeit, Bedrohungen (W-01 bis W-10), TOMs und Restrisiko.
• AVV-Anhang (BeryJu-Code-Maintainership): tom/avv/authentik-template.md ([user-gate] — Unterzeichnung steht aus).
• TOM-Katalog nach BSI-Grundschutz / ISO 27001: tom/tom-docs/ (Controls A.5–A.18).
• Pen-Test-Briefing (Phase 7.1, ADR 0543): docs/security/AUTHENTIK-PEN-TEST-BRIEFING.md + 5 weitere Pen-Test-Artefakte (Vektoren-Katalog, Readiness-Checkliste, NDA-/RoE-/Report-Templates).
• Production-Cutover-Plan (Phase 7.3, ADR 0541): docs/operations/AUTHENTIK-PRODUCTION-CUTOVER-PLAN.md.
• Authentik-Migration-Master-Plan: docs/sprints/AUTHENTIK-MIGRATION-PLAN.md.

11. Stand + Review-Zyklus

Stand: 2026-07-06 (Authentik-Migration / Slice 7.2-n1). Diese Privacy-Page ist die Betroffenen-Information gemäß Art. 13/14 DSGVO für die Authentik-IdP- Verarbeitungstätigkeit. Die DSFA tom/dsfa/authentik-idp.md ist der rechtlich verbindliche Source-of-Truth — bei Diskrepanzen gilt die DSFA.

Review-Zyklus: 6 Monate (verkürzt wegen aktiver Migrations-Phase + ausstehendem externem Pen-Test), oder bei Authentik-Upstream-Release, Spec-/ADR-Änderung, Pen-Test-Phase 7.1.