Authentik og OIDC: de faldgruber der koster en weekend
Jeg kører Authentik som central identitetsudbyder i mit homelab, så jeg kan logge ind ét sted og få SSO på tværs af alle mine tjenester via OIDC. Det fungerer rigtig godt .. lige indtil det ikke gør. Her er de faldgruber jeg selv er faldet i, og hvordan jeg slap ud af dem igen.
redirect_uri stemmer ikke
Den klassiker. Du logger ind, Authentik sender dig tilbage, og applikationen råber
redirect_uri_mismatch. I næsten alle tilfælde er det en af tre ting:
- En trailing slash der er med det ene sted og ikke det andet.
- http kontra https .. appen bygger callback-URL’en med
http://, mens Authentik forventerhttps://. - Et ekstra query-parameter der får regex’en for tilladte redirect-URI’er til at fejle.
Callback-URL’en i appen skal matche en af redirect-URI’erne i Authentik helt nøjagtigt. Jeg holder én regel: kopiér URL’en, lim den ind begge steder, og rør den ikke med håndkraft.
X-Forwarded-Proto er din ven
Den med http/https er næsten altid en proxy der ikke fortæller appen, at den
oprindelige forbindelse var krypteret. Hvis din reverse proxy ikke sætter
X-Forwarded-Proto: https, så genererer appen sine egne URL’er med http://, og
så er redirect-mismatchen i hus. Sørg for at headeren er sat, så appen bygger
korrekte redirect-URI’er. Det er en af de hyppigste årsager til OAuth-fejl med
Authentik bag fx Portainer.
Bland ikke ID-token og access-token sammen
OIDC giver dig to tokens, og de har hver sin opgave:
- ID-tokenet beviser hvem brugeren er. Det skal bruges til at oprette sessionen i din OIDC-klient.
- Access-tokenet giver adgang til API’er. Det skal sendes med i
Authorization-headeren til din backend.
Sender du et ID-token til et API, har det forkert aud (audience). Bruger du et
access-token til at identificere sessionen, mangler det en defineret
claim-struktur. En af de mest udbredte OIDC-bugs er netop at bytte rundt på de to.
Bind sessionen til sub, ikke email
Det er fristende at bruge email som den unikke nøgle for en bruger. Lad være.
Email kan ændre sig, mens sub er det stabile id. Binder du brugerkontoen til
email, så bryder alt den dag nogen skifter adresse. Brug sub.
Hold ID-tokenet småt og brug /userinfo
Smid ikke alle claims ind i ID-tokenet via store scopes. Hold det lille, og hent de rige profildata fra /userinfo-endpointet når du har brug for dem. ID-tokenet indeholder ikke nødvendigvis alle claims for de scopes du beder om, men /userinfo har det fulde sæt.
PKCE på alt
Brug PKCE på alle flows, både offentlige og fortrolige klienter. Mange public clients springer det stadig over, selvom det i dag reelt er et krav for dem og stærkt anbefalet generelt. Det koster ingenting at slå til, og det lukker en hel klasse af angreb.
Når en opgradering vender op og ned på det
En sidste advarsel: efter en opgradering fra Authentik 2025.12.1 til 2025.12.2
begyndte OAuth via en Proxy Provider at fejle med redirect_uri_mismatch,
fordi Authentik byggede callback’en med applikationens domæne i stedet for sit
eget. Pointen: når noget pludselig knækker uden du har rørt din config, så kig på
changelog’en før du river håret ud.