Sist endret: 16. juli 2026

Arkitekturmønstre i Authentication

Mønstre for OIDC, tokenflyter og System User i Altinn Authentication.

Authentication kombinerer protokollendepunkter for identitet med arbeidsflyter for System User. Sikkerhetskritisk tilstand lagres bak egne repositorygrenser.

OIDC som protokolltilstandsmaskin

Innlogging, autorisasjonskode, token, sesjon og utlogging behandles som separate steg med lagret, kortlivet tilstand.

Fordeler: standardiserte steg, begrenset levetid for hemmeligheter og tydelige valideringspunkter. Ulemper: mange avhengige steg gir krevende feilsøking, og feil i omdirigering eller tilstand kan bli sikkerhetshull.

Tokenutstedelse bak en tjenestegrense

Controllere overlater oppretting og signering av token til egne tjenester og sertifikatleverandører.

Fordeler: kryptografi og nøkkelhåndtering samles og kan byttes. Ulemper: feil levetid, målgruppe eller nøkkelvalg påvirker alle konsumenter.

Arbeidsflyter med forespørsel og godkjenning

System User skiller registrerte systemer, forespørsler, endringsforespørsler og den ferdige systembrukeren. Hver overgang går gjennom en applikasjonstjeneste og lagres.

Fordeler: godkjenning kan revideres og domenestatus blir eksplisitt. Ulemper: flere statuser og endepunkter krever beskyttelse mot ugyldige og gjentatte overganger.

Porter rundt persistens og eksterne identitetskilder

Kjernen definerer repository- og tjenestegrensesnitt, mens verten setter sammen konkrete lagrings- og integrasjonsklasser.

Fordeler: protokoll- og domenelogikk kan prøves isolert. Ulemper: mange abstraksjoner kan skjule transaksjonsgrenser og gjøre kallkjeden lang.

Når mønstrene endres, må teamet bevare protokollkrav, engangsbruk, utløpstid, revisjonsspor og sikre feilutfall.