Reverse-proxy header authentication (X-Remote-User)

[PortableProgrammer]

Proposal

Add authentication via trusted HTTP headers set by an upstream reverse-proxy (Authentik Outpost, Authelia, oauth2-proxy, Traefik forward-auth, nginx auth_request). This is the dominant pattern for homelab self-hosters who already run a centralized SSO IdP — lurker becomes "just another app" behind the existing auth layer.

Depends on

#35 should land first since it establishes the create-or-find user pattern that this issue reuses.

Critical security guard

This auth path must only activate when explicitly enabled via an env var (e.g., PROXY_AUTH_HEADER=X-Remote-User). If unset, the header is ignored entirely — preventing the misconfiguration where lurker is exposed directly to the internet and an attacker spoofs the header.

Scope

• Middleware checks for the configured header on each request before falling through to JWT cookie auth
• On valid header, create-or-find user matching <header-value> username; issue a JWT cookie for the session
• Optionally support a secondary header (PROXY_AUTH_GROUPS_HEADER=X-Remote-Groups) to populate admin status — e.g., users in a configured admin group become lurker admins
• Documentation explicitly states the reverse-proxy must be configured to strip incoming versions of these headers from client requests

Touches

• src/auth.js (new middleware)
• src/index.js (wire it into the auth chain)
• readme.md (deployment guidance with example Authentik / oauth2-proxy / Traefik snippets)

Acceptance

With PROXY_AUTH_HEADER set and a request arriving with that header populated, the user is authenticated transparently and a session cookie is issued. With the env var unset, the header is ignored entirely.