Problem: docs-lint (added in the wiki-hq reorg) surfaced 126 broken relative
links that predated this session — a container rename, incident/plan docs
that moved into archive/done subfolders without their inbound links being
updated, and a handful of relative-depth bugs in files nested under
containers/archive/ and plans/done/.
Fixes applied, by category:
- 124-authentik.md -> 106-auth-outpost.md (container was renamed; ~40 refs).
- investigations/{2026-04-21-hubris-crash-loop,2026-05-31-authentik-vps-migration}.md
-> archive/ prefix (both moved to investigations/archive/ previously).
- plans/{2026-06-01-slate-ax-to-sodola-migration,2026-06-04_130000-deprecate-claudio-bot,
2026-06-25-yuvomi-deployment}.md -> plans/done/ prefix.
- Depth bugs in files nested one level deeper than their siblings assumed
(investigations/archive/*, knowledge/wiki/containers/archive/*,
plans/done/*) — corrected relative-path depth.
- Destroyed containers with no surviving page (126-plato) delinked to the
containers/index.md archaeology row instead of a 404.
- ludo-mini.yaml -> strong.yaml (host was renamed, same physical machine).
- netbird-vps.md (no narrative page exists) -> netbird-vps.yaml (substrate
record, matching the existing convention for hosts without a wiki page).
- runbook-dpkg-interrupted.md refs -> .agents/skills/runbook-dpkg-interrupted/SKILL.md
(missed in the phase-4 runbook move because the referencing files used a
bare filename, not a runbooks/ prefix).
- One dangling forward-reference to a never-written investigation delinked
to the actual incident record it was describing.
Left alone: two links in knowledge/wiki/containers/101-jellyfin.md into
devops/homelab-authentik-admin/ — an intentional reference to a sibling repo,
not present in this checkout.
Verification: broken-link count 126 -> 2 (real remainder is the cross-repo
reference above); gen-topology.py --check still exit 0; build_host_files.py
still idempotent; all inventory.yaml doc_page targets still resolve.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
101 lines
5.3 KiB
Markdown
101 lines
5.3 KiB
Markdown
# 2026-06-06 — Frequent Authentik login prompts fixed (session duration)
|
|
|
|
## Summary
|
|
|
|
User needed to re-authenticate to Authentik several times per day. Root cause was the Django session being configured as a **session cookie** (cleared on browser close) with a short 24-hour lifetime. Fixed by extending both the session cookie lifetime and the user_login stage session duration to 30 days.
|
|
|
|
## Timeline
|
|
|
|
- **2026-06-06 ~23:00** — User reports "having to login to authentik several times per day"
|
|
- **~23:10** — Investigation begins: check Authentik OAuth2 provider settings, proxy session table, Django session config
|
|
- **~23:20** — Found `SESSION_EXPIRE_AT_BROWSER_CLOSE=True` — the `authentik_session` cookie has no Max-Age, cleared on browser close
|
|
- **~23:25** — Found the `user_login` stage has `session_duration=seconds=0`, which calls `session.set_expiry(0)` → `_session_expire_at_browser_close=True`
|
|
- **~23:30** — Applied DB fix: updated `authentik_stages_user_login_userloginstage` → `session_duration='days=30'`
|
|
- **~23:35** — Added `AUTHENTIK_SESSIONS__UNAUTHENTICATED_AGE=days=30` to `/opt/authentik.env` (maps to `sessions.unauthenticated_age` in Authentik config, setting `SESSION_COOKIE_AGE` to 30 days)
|
|
- **~23:40** — Recreated container with `docker compose up -d` (restart doesn't re-read env file)
|
|
- **~23:45** — Verified both changes took effect
|
|
|
|
## Root cause
|
|
|
|
Two independent but compounding issues:
|
|
|
|
1. **`SESSION_EXPIRE_AT_BROWSER_CLOSE=True`** — hardcoded in `/authentik/root/settings.py`. Makes the `authentik_session` cookie a session cookie (no `Max-Age`), cleared when the browser closes. Cannot be changed via env vars or config files (hardcoded in Python source).
|
|
|
|
2. **`user_login` stage `session_duration=seconds=0`** — the default-authentication-login stage called `session.set_expiry(0)`, which in Django sets `_session_expire_at_browser_close=True` on the session object, overriding any session cookie lifetime set via `SESSION_COOKIE_AGE`.
|
|
|
|
3. **`sessions.unauthenticated_age=days=1`** (default) — `SESSION_COOKIE_AGE` was 86,400 seconds (24 hours), so even with the browser left open, the server-side session data expired after 24 hours with no way to extend it (`SESSION_SAVE_EVERY_REQUEST=False`).
|
|
|
|
### Why forward-auth worked but OAuth2 didn't
|
|
|
|
- **Forward-auth (Caddy-gated services)** — The `authentik_proxy_*` cookie is a *persistent* cookie with 24-hour validity, set by the Authentik proxy outpost. It survives browser restart. Caddy's forward-auth validates this cookie directly with the outpost API — no Django session needed.
|
|
- **OAuth2 (Gitea, Jellyfin, etc.)** — These services redirect to `auth.hubris.network/application/o/authorize/`, which checks the Django session (`authentik_session` cookie). If the browser was closed, this cookie is gone → user is redirected to the login form.
|
|
|
|
## Changes applied
|
|
|
|
### 1. Database — `authentik_stages_user_login_userloginstage`
|
|
|
|
```sql
|
|
UPDATE authentik_stages_user_login_userloginstage
|
|
SET session_duration = 'days=30'
|
|
WHERE stage_ptr_id = (
|
|
SELECT stage_uuid FROM authentik_flows_stage
|
|
WHERE name = 'default-authentication-login'
|
|
);
|
|
```
|
|
|
|
This causes the login stage to call `session.set_expiry(timedelta(days=30))`, which:
|
|
- Sets `_session_expire_at_browser_close=False` for that session
|
|
- Sets the session cookie `Max-Age` to 30 days (persistent cookie)
|
|
- Sets the server-side session expiry to 30 days
|
|
|
|
### 2. Environment — `AUTHENTIK_SESSIONS__UNAUTHENTICATED_AGE`
|
|
|
|
Added to `/opt/authentik.env`:
|
|
|
|
```
|
|
AUTHENTIK_SESSIONS__UNAUTHENTICATED_AGE=days=30
|
|
```
|
|
|
|
This maps to config key `sessions.unauthenticated_age`, which Authentik's `settings.py` reads via:
|
|
|
|
```python
|
|
SESSION_COOKIE_AGE = timedelta_from_string(
|
|
CONFIG.get("sessions.unauthenticated_age", "days=1")
|
|
).total_seconds()
|
|
```
|
|
|
|
Result: `SESSION_COOKIE_AGE` = 2,592,000 seconds (30 days). This is a fallback for sessions that don't go through the `user_login` stage or when the stage's explicit `set_expiry` doesn't apply.
|
|
|
|
## Verification
|
|
|
|
```python
|
|
# Inside authentik-server container:
|
|
import os
|
|
os.environ.setdefault("DJANGO_SETTINGS_MODULE", "authentik.root.settings")
|
|
import django
|
|
django.setup()
|
|
from django.conf import settings
|
|
print("SESSION_COOKIE_AGE:", settings.SESSION_COOKIE_AGE) # → 2592000.0
|
|
print("SESSION_EXPIRE_AT_BROWSER_CLOSE:", settings.SESSION_EXPIRE_AT_BROWSER_CLOSE) # → True
|
|
|
|
from authentik.stages.user_login.models import UserLoginStage
|
|
stage = UserLoginStage.objects.filter(name="default-authentication-login").first()
|
|
print("session_duration:", stage.session_duration) # → "days=30"
|
|
```
|
|
|
|
## Open questions
|
|
|
|
- `SESSION_COOKIE_SECURE=False` — Should be `True` since Authentik is HTTPS-only, but the custom `SessionMiddleware.is_secure()` method dynamically sets the cookie's `secure` flag based on the request, so it's fine.
|
|
- 30 days is generous. Could be reduced to 7-14 days if desired. Change the DB value and env var accordingly.
|
|
|
|
## Related
|
|
|
|
- [Container 106 — auth-outpost](../knowledge/wiki/containers/106-auth-outpost.md)
|
|
- [Authentik VPS migration](archive/2026-05-31-authentik-vps-migration.md)
|
|
- [Ingress (VPS Traefik)](../knowledge/wiki/infrastructure/ingress.md)
|
|
- `.hermes/plans/2026-06-06_232200-authentik-frequent-login-fix.md` — original plan
|
|
|
|
## Changelog
|
|
|
|
### 2026-06-06 — created
|
|
Documented the session lifetime investigation, root cause, and applied fixes. |