Authentik als Identity Provider für Matrix

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

DNS A-Record: auth.axion1337.chat → 49.13.132.245
Pods hochfahren: kubectl get pods -n authentik -w
Authentik UI: https://auth.axion1337.chat/if/flow/initial-setup/ → Admin-Passwort setzen
OIDC Provider: Admin UI → OIDC Provider erstellen
Application: Slug matrix (wichtig für Issuer URL!)
Redirect URIs:
- https://account.axion1337.chat/upstream/callback/01KQDJTR1ZVTG8JQ220F5BNBFZ
- Post-logout: https://axion1337.chat
Client ID + Secret kopieren

Stage 2: MAS Integration

Decrypt: sops --decrypt --in-place apps/production/custom-configs/mas-secret.yaml
upstream_oauth2_config + passwords-config Blöcke hinzufügen
Encrypt: sops --encrypt --in-place ...
Commit & Push
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 (optional, not_configured_action=skip) — Selbst-Einrichtung, 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.

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.