---
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.