SSO (Authentik)¶
Authentik is the identity provider for every human-facing service in the lab: one account, one login, and every app behind the same SSO flow. It is the "you only log in once" layer that makes a 15+ service self-hosted suite actually usable by real people.
The SSO map¶
| Service | Integration | Login experience |
|---|---|---|
| Authentik (Blackrack ID) | — | The identity provider itself |
| Vikunja (tasks) | Native OIDC | One click, straight in |
| Firefly III (finance) | Reverse-proxy auth gate | Redirected to SSO on first hit |
| wger (health) | Django allauth OIDC | One-step social login |
| Matrix / Element (chat) | Synapse OIDC + SSO option | Matrix credentials or SSO |
| Everything else behind Caddy | forward_auth gate |
SSO by construction |
The fluid login rule¶
Every integrated service must give a one-step, direct login: opening the service's entry URL redirects straight to Authentik (or, with an existing session, straight in) — with no intermediate "pick a login method" click. A service is not considered done until this is verified in a clean browser.
This rule has an engineering reason: friction at login is the top reason
people abandon self-hosted tools, and every framework has a different way to
skip its login chooser (a redirect parameter, a SOCIALACCOUNT_LOGIN_ON_GET
flag, a forward_auth gate...). The platform keeps a per-service mechanism
checklist so the UX contract is enforced, not hoped for.
Access broker¶
Agents can give users direct entry links through a narrow access broker that:
- lists known apps and their SSO readiness,
- returns the safe, fluid entry URL,
- never mints browser sessions, cookies, OIDC codes, reset links, API tokens, or passwords.
Human SSO and agent API access are separate trust domains: a user's browser session and an agent's service token never mix, and agents cannot impersonate users.
Operational notes¶
- Authentik runs in-cluster (server + worker) on its own managed PostgreSQL database, with backups covered by the shared database strategy.
- App registrations and providers are managed as configuration; new apps are added with the fluid-login rule as an acceptance criterion.