Authentik bag en reverse proxy: forward auth, outposts og 502-fælden
Når du sætter Authentik bag en reverse proxy, skal du tidligt træffe et valg: skal proxyen selv håndtere applikationstrafikken og kun spørge Authentik “må den her bruger?”, eller skal Authentik stå helt foran? De to modeller hedder forward auth og proxy provider, og de løser hver sit problem.
Forward auth kontra proxy provider
Med forward auth bruger du din eksisterende reverse proxy til selve trafikken, og Authentiks outpost bliver kun spurgt om authentication og authorization. Det er den model jeg foretrækker, fordi min proxy i forvejen styrer TLS, routing og certifikater .. Authentik skal bare sige god eller ej.
Med en proxy provider lader du Authentik proxye trafikken hele vejen. Det er enklere for enkeltstående apps, men du giver afkald på noget kontrol over edge’en.
For at bruge forward auth vælger du en af forward-auth-tilstandene på proxy provideren og konfigurerer din reverse proxy til at sende auth-tjek til outposten. Vælg domain-level hvis du vil dele login på tværs af mange subdomæner, og single application hvis det kun gælder én app.
502-fælden: for store auth-headers
Her er den der koster timer. Alt virker, men en gang imellem .. eller for nogle brugere .. svarer appen med 502 Bad Gateway. Det er ofte fordi auth-proxyen sender meget store response-headers tilbage (tænk mange grupper-claims eller lange tokens), og nginx’ default-buffere er for små til at rumme dem.
Løsningen er at skrue op for buffer-størrelserne i nginx:
proxy_buffers 8 16k;
proxy_buffer_size 32k;Justér tallene op hvis du har mange grupper på din bruger. Det er ikke en Authentik-bug, det er nginx der nægter at videresende en header den synes er for stor.
WebSockets og HTTP/1.1 er et krav
Authentik kommunikerer med sine outposts over WebSockets, og din reverse proxy
skal kunne tale HTTP/1.1 eller nyere. Kører proxyen i en gammel
HTTP/1.0-tilstand, eller mangler den Upgrade- og Connection-headerne, så får
outposten aldrig forbindelse, og din UI viser bare 502 authentik starting... i
en uendelighed.
Sørg for at proto-headeren er sat
Det samme råd som med ren OIDC gælder her: din proxy skal sende
X-Forwarded-Proto, X-Forwarded-Host og X-Forwarded-For videre. Gør den ikke
det, bygger Authentik forkerte redirect-URI’er, og du ender i den klassiske
redirect_uri-fejl .. nu bare med et ekstra lag proxy at fejlsøge igennem.
Min anbefaling
Start med forward auth hvis du allerede har en reverse proxy du er glad for. Hold proxyens buffere store nok fra dag ét, tjek at WebSockets går igennem, og send dine forwarded-headers korrekt. Så er du fri for langt de fleste af de fejl jeg har brugt aftener på.