docs: create betrieb/authentik-oidc

betrieb/authentik-oidc.md

@@ -0,0 +1,105 @@
+---
+title: Authentik OIDC
+description: Authentik als Identity Provider für Matrix
+published: true
+date: 2026-08-13T18:04:18.450Z
+tags: 
+editor: markdown
+dateCreated: 2026-08-13T18:04:18.450Z
+---
+
+**Status**: ✅ Deployed (Stage 1 + Stage 2 + Enrollment/Recovery/2FA)  
+**Domain**: `auth.axion1337.chat`
+
+## Überblick
+
+Authentik = OIDC Provider für MAS → Zentrales Login + Einladungs-basierte Registrierung.
+
+## Stage 1: Authentik Deployment
+
+**Dateien** (in `apps/authentik/`):
+- `namespace.yaml`, `helm-repo.yaml`, `authentik-secret.yaml` (SOPS)
+- `authentik.yaml` (HelmRelease v2026.x + embedded Postgres)
+- `certificate.yaml`, `ingress.yaml`
+
+**Flux Kustomization**: `clusters/matrix/flux-system/authentik-sync.yaml`
+
+## Deployment-Schritte
+
+1. **DNS A-Record**: `auth.axion1337.chat → 49.13.132.245`
+2. **Pods hochfahren**: `kubectl get pods -n authentik -w`
+3. **Authentik UI**: `https://auth.axion1337.chat/if/flow/initial-setup/` → Admin-Passwort setzen
+4. **OIDC Provider**: Admin UI → OIDC Provider erstellen
+5. **Application**: Slug `matrix` (wichtig für Issuer URL!)
+6. **Redirect URIs**:
+   - `https://account.axion1337.chat/upstream/callback/01KQDJTR1ZVTG8JQ220F5BNBFZ`
+   - Post-logout: `https://axion1337.chat`
+7. **Client ID + Secret kopieren**
+
+## Stage 2: MAS Integration
+
+1. Decrypt: `sops --decrypt --in-place apps/production/custom-configs/mas-secret.yaml`
+2. `upstream_oauth2_config` + `passwords-config` Blöcke hinzufügen
+3. Encrypt: `sops --encrypt --in-place ...`
+4. Commit & Push
+5. **WICHTIG**: `passwords: enabled: false` erst nach OIDC-Test!
+
+## Einladungs-Links
+
+Authentik Admin → Flows & Stages → Invitations → Create
+
+## Enrollment/Recovery/2FA Fix (2026-07-27)
+
+Der `matrix-invitation`-Flow hatte nur 2 von 5 nötigen Stages (kein Write/Password/Login,
+beide vorhandenen Stages auf derselben `order`). Nutzer wurden nie in Synapse angelegt.
+Behoben und als **Authentik Blueprint** (`apps/authentik/authentik-blueprints.yaml`)
+deklarativ ins Repo übernommen, statt Klick-Anleitung:
+
+- `matrix-invitation`: Invite → Prompt → Write → Password → Login → Redirect (axion1337.chat)
+- `matrix-invitation-prompt`: 16 fehlerhafte `validation_policies` entfernt (crashten mit `AnonymousUser`/`NoneType`-Fehlern)
+- `matrix-recovery`: war komplett leer (0 Stages) — jetzt vollständig, verlinkt als "Passwort vergessen?" auf der echten Login-Seite (`default-authentication-flow`)
+- `Brand.default_application` auf die `matrix`-Application gesetzt, damit `/` für eingeloggte User nicht mehr in der `/if/user/`-Sackgasse landet (die für `type=external` Matrix-Accounts gesperrt ist)
+
+**2FA/Passkey — freiwillig für Mitglieder, Pflicht für Admins** (Stand 2026-08-06):
+
+- **Mitglieder**: freiwillig. Die Standard-Stage `default-authentication-mfa-validation`
+  steht weiterhin auf `not_configured_action=skip`, der Login blockiert also nie.
+- **Gruppe `authentik Admins`**: Pflicht. Eine zweite Stage `admin-mfa-validation`
+  (Ordnung 31, `not_configured_action=configure`) führt Admins ohne zweiten Faktor beim
+  Login durch die Einrichtung. Umgesetzt im Blueprint `admin-mfa-enforcement.yaml`,
+  Details im [Leitfaden 02](https://git.lab/axion1337.chat/axion1337.chat-gitops/-/blob/main/docs/deployment-guides/02-authentik-identity-provider.md)
+  (gitops#57).
+
+Selbst-Einrichtung über Direktlinks, da `/if/user/` für externe User gesperrt ist:
+- Passkey: `https://auth.axion1337.chat/if/flow/default-authenticator-webauthn-setup/`
+- TOTP: `https://auth.axion1337.chat/if/flow/default-authenticator-totp-setup/`
+- Auffindbar für Nutzer über `axion1337.chat/docs/setup/security.html`
+
+**Issue #13 geschlossen (2026-07-29)**: ein direkter Link auf `account.axion1337.chat/account/`
+(MAS) per Custom-Template-Override wurde verworfen — live geprüfte OIDC-Discovery zeigt, dass
+MAS keine 2FA/Passkey-Deep-Link-Action unterstützt. Jetzt als Client-seitige Änderung
+nachgehalten: [ThreadNet-Web#4](https://git.lab/axion1337.chat/ThreadNet-Web/-/issues/4).
+
+## OIDC Provider/Application als Code erfasst (2026-07-28, Issue #36)
+
+Die OAuth2-Provider- + Application-Verknüpfung ("Matrix Authentication Service" / Slug
+`matrix`) aus Stage 1+2 oben war ursprünglich reines Klick-Ergebnis in der UI und existierte
+nirgends als Code — anders als die Flow-Fixes oben. Ginge die Authentik-DB verloren, wäre
+diese Verknüpfung (inkl. Client-Secret) nicht rekonstruierbar gewesen, ohne MAS neu zu
+synchronisieren. Jetzt ebenfalls als Blueprint (`matrix-oidc-provider.yaml` in
+`apps/authentik/authentik-blueprints.yaml`) erfasst: Client-ID, Redirect-URI, `sub_mode:
+hashed_user_id`, Property-Mappings (openid/email/profile), Auth-/Invalidation-Flow, Signing-Key,
+sowie die Application selbst.
+
+Der Client-Secret steht **nicht** im Blueprint (die ConfigMap ist nicht SOPS-verschlüsselt),
+sondern wird per `!Env AUTHENTIK_MAS_OIDC_CLIENT_SECRET` gelesen — die Env-Var kommt aus einem
+neuen Key `mas-oidc-client-secret` in der bestehenden SOPS-verschlüsselten
+`authentik-credentials` Secret (`apps/authentik/authentik-secret.yaml`), verdrahtet über
+`global.env` im `authentik.yaml` HelmRelease. Der eingetragene Wert ist der tatsächliche,
+live genutzte Secret (keine Rotation) — verifiziert per direktem DB-Vergleich nach dem
+Blueprint-Rollout: Client-ID, Secret-Länge, Redirect-URI, Property-Mappings und
+Application-Verknüpfung 1:1 identisch zum Vorzustand, kein Duplikat erzeugt, MAS lief
+durchgehend ohne Neustart/Fehler weiter.
+
+---
+**Weitere Details**: Siehe Kapitel 2 in diesem Projekt.