Files
oikos/investigations/2026-06-06-authentik-session-lifetime.md
dtoro 4efddb8bed docs: fix pre-existing broken links surfaced by docs-lint
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>
2026-07-06 17:53:35 +02:00

5.3 KiB

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

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:

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

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

Changelog

2026-06-06 — created

Documented the session lifetime investigation, root cause, and applied fixes.