---
title: "Authentik og OIDC: de faldgruber der koster en weekend"
description: "redirect_uri-mismatch, X-Forwarded-Proto, sub vs. email og de andre OIDC-fælder jeg er faldet i med Authentik."
date: 2026-06-01
taxonomies:
  tags: [authentik, oidc, sso, selfhost]
draft: false
extra:
  godkendt: "v1:6c1d0bac31fd0547c7b0fc4e1c3dbb4ec8bf13d5960f33d8df90766c7700a1cd"
---

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 forventer `https://`.
- 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.

## Kilder og videre læsning

- [Authentik #19883: redirect_uri via Proxy Provider](https://github.com/goauthentik/authentik/issues/19883)
- [Fix OAuth login med Authentik i Portainer](https://oneuptime.com/blog/post/2026-03-20-portainer-oauth-authentik/view)
- [Authentik #3445: forward auth redirect URI](https://github.com/goauthentik/authentik/issues/3445)
- [Okta: OIDC primer (sub, claims, tokens)](https://developer.okta.com/blog/2017/07/25/oidc-primer-part-1)