- Migrations 010 (content_hash) + 011 (search tsvector column) - new: internal/knowledge/seed.go — knowledge seed ingest engine - new: internal/httpapi/knowledge.go — SearchKnowledge + GetEntityKnowledge - wire knowledge ingest into oikos seed pipeline - convert all 36 wiki docs + 6 investigations + 12 runbooks → seeds/knowledge.yaml - archive: knowledge/wiki/→archive/, oikos/cards/→archive/, .hermes/plans/→archive/ - delete: 9 superseded Python kernel files, ledger/, mcp/build_host_files.py - remove empty knowledge/ directory tree
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— theauthentik_sessioncookie has no Max-Age, cleared on browser close - ~23:25 — Found the
user_loginstage hassession_duration=seconds=0, which callssession.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=30to/opt/authentik.env(maps tosessions.unauthenticated_agein Authentik config, settingSESSION_COOKIE_AGEto 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:
-
SESSION_EXPIRE_AT_BROWSER_CLOSE=True— hardcoded in/authentik/root/settings.py. Makes theauthentik_sessioncookie a session cookie (noMax-Age), cleared when the browser closes. Cannot be changed via env vars or config files (hardcoded in Python source). -
user_loginstagesession_duration=seconds=0— the default-authentication-login stage calledsession.set_expiry(0), which in Django sets_session_expire_at_browser_close=Trueon the session object, overriding any session cookie lifetime set viaSESSION_COOKIE_AGE. -
sessions.unauthenticated_age=days=1(default) —SESSION_COOKIE_AGEwas 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_sessioncookie). 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=Falsefor that session - Sets the session cookie
Max-Ageto 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 beTruesince Authentik is HTTPS-only, but the customSessionMiddleware.is_secure()method dynamically sets the cookie'ssecureflag 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
- Authentik VPS migration
- Ingress (VPS Traefik)
.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.