authelia: forward-auth accepts the session cookie only #409

Merged

mysticalsoap merged 1 commit from authelia/cookie-only into trunk

2026-10-08 14:11:10 -04:00

mysticalsoap commented

2026-10-08 14:00:07 -04:00

Owner

Stacked on #408 (base is its branch); retarget to trunk once that merges.

Problem

The empty-username failed logins from #404's aside, ~160 a day: Authelia's default forward-auth strategy tries any Authorization header as a Basic login before the session cookie, on bypass domains too, and a failed lookup short-circuits as a failed 1FA. The phone's ntfy app sends its access token as Basic with an empty username on every topic resubscribe (seven topics, seven lines a burst), and Forgejo runner/CI traffic from the host did the same. They also counted in authelia_authn{success="false"}, the metric behind AutheliaHighFailedAuthn.

Fix

server.endpoints.authz.forward-auth.authn_strategies: [CookieSession]. The login portal becomes the only place a password is accepted; apps' own API auth passes through untouched. A non-browser client can no longer log in as an Authelia user, which nothing here did. Auth-and-Security page says so.

Verification

Live, 2026-10-08:

Before: curl -u ':x' https://radarr.…/ → 401 with a Basic challenge, and the log file gets Unsuccessful 1FA authentication attempt by user '' plus the user-details error.
just recreate authelia: healthy in 8s, no startup-check line.
After: the same probe → 302 to the login portal, identical to a request with no header; the log has one info line, Access to … is not authorized. On ntfy (bypass) the probe reaches ntfy, which answers 401 for the bad token itself; Authelia logs nothing.
Authelia's error log stays empty of the user '' line since the recreate.

🤖 Generated with Claude Code

Stacked on #408 (base is its branch); retarget to trunk once that merges. ## Problem The empty-username failed logins from #404's aside, ~160 a day: Authelia's default forward-auth strategy tries any `Authorization` header as a Basic login before the session cookie, on `bypass` domains too, and a failed lookup short-circuits as a failed 1FA. The phone's ntfy app sends its access token as Basic with an empty username on every topic resubscribe (seven topics, seven lines a burst), and Forgejo runner/CI traffic from the host did the same. They also counted in `authelia_authn{success="false"}`, the metric behind AutheliaHighFailedAuthn. ## Fix `server.endpoints.authz.forward-auth.authn_strategies: [CookieSession]`. The login portal becomes the only place a password is accepted; apps' own API auth passes through untouched. A non-browser client can no longer log in as an Authelia user, which nothing here did. Auth-and-Security page says so. ## Verification Live, 2026-10-08: - Before: `curl -u ':x' https://radarr.…/` → 401 with a Basic challenge, and the log file gets `Unsuccessful 1FA authentication attempt by user ''` plus the user-details error. - `just recreate authelia`: healthy in 8s, no startup-check line. - After: the same probe → 302 to the login portal, identical to a request with no header; the log has one info line, `Access to … is not authorized`. On ntfy (`bypass`) the probe reaches ntfy, which answers 401 for the bad token itself; Authelia logs nothing. - Authelia's error log stays empty of the `user ''` line since the recreate. 🤖 Generated with [Claude Code](https://claude.com/claude-code)

mysticalsoap added 1 commit

2026-10-08 14:00:07 -04:00

authelia: forward-auth accepts the session cookie only

validate / validate (pull_request) Successful in 12s

Details

7c30f90137

The default authn_strategies try any Authorization header as an
Authelia Basic login before the cookie, on bypass domains too, and a
failed lookup short-circuits as a failed 1FA. Every ntfy token the
phone app sends as an empty-username Basic header on each topic
resubscribe, and the Forgejo runner and CI traffic from the host, were
landing in the log as "Unsuccessful 1FA authentication attempt by user
''" and in authelia_authn{success="false"}: about 160 a day, bursts of
seven a minute against AutheliaHighFailedAuthn's ten.

Cookie only also means the login portal is the single place a password
is accepted; nothing here used Basic auth against Authelia.

Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>

mysticalsoap changed target branch from boot/restart-propagation to trunk

2026-10-08 14:11:05 -04:00

mysticalsoap merged commit 4e3809bef4 into trunk

2026-10-08 14:11:10 -04:00

mysticalsoap deleted branch authelia/cookie-only

2026-10-08 14:11:10 -04:00

mysticalsoap referenced this pull request from a commit

2026-10-08 14:11:11 -04:00

Merge pull request 'authelia: forward-auth accepts the session cookie only' (#409) from authelia/cookie-only into trunk