Gå til hovedinnhold

Autentiseringsflyt og grant types

For å logge inn en bruker må applikasjonen din gjøre en autentiseringsforespørsel mot HelseID. I autentiseringsforespørselen kan du angi hvordan du ønsker HelseID skal levere fra seg tokens tilbake til klienten din. De forskjellige måtene HelseID kan levere fra seg tokens på kalles Grant Types, eller autentiseringsflyt.

Grant types, eller autentiseringsflyt, er ulike måter for hvordan en klient kan samhandle med STS-en.

OpenID Connect 1.0 definerer 3 forskjellige autentiseringsflyter (eksterne lenker):

OAuth 2.0 definerer 6 grant types (eksterne lenker):

HelseID implementerer, eller tilrettelegger for, det som kombinert blir 7 grant types (autentiseringsflyter), som vil kort forklares her.

Implicit grant

Implicit flow er primært tiltenkt browserbaserte applikasjoner, det være seg enten for brukerautentisering alene, eller både autentiserings- og access token-forespørsler, der det sistnevnte vil gjelde for JavaScript-applikasjoner. En SPA (Single Page Application) er det typiske brukstilfellet for implicit flow.

Ved implicit flow vil tokens bli sendt via browseren, altså frontkanalen. Av sikkerhetsmessige årsaker tillates ikke refresh tokens ved implicit flow.

Eksempel på flyt for en JavaScript/SPA-klient

SPA

Authorization code grant

I motsetning til ved implicit flow, overføres tokens ikke via frontkanalen (browseren) med authorization code flow. En autorisasjonskode overføres via frontkanalen inn til klienten, som videre kontakter HelseIDs Token-endepunkt vedlagt autorisasjonskoden, og får et identity token, et access token og eventuelt et refresh token i retur. I tillegg må klienten autentisere seg mot HelseID med eksempelvis en delt hemmelighet, eller et klientsertifikat, for å få lov til å bruke autorisasjonskoden til å hente ut informasjon. Dette for å hindre at autorisasjonskoden brukes av uvedkommende tredjepart.

Klientautentisering er beskrevet i spesifikasjonen for OpenID Connect Core 1.0.

Eksempel på flyt for en webapplikasjon med delt hemmelighet med HelseID

Webapplikasjon

PKCE (Proof Key for Code Exchange)

I tilfeller der klienten befinner seg i et miljø som gjør at den ikke kan holde på en delt statisk hemmelighet over tid, er PKCE et alternativ. PKCE-protokollen er spesifisert her.

I korte trekk oppretter klienten en dynamisk hemmelighet, som hashes og vedlegges autentiseringsforespørselen for brukeren. HelseID må på sin side internt assosiere den hashede hemmeligheten med autorisasjonskoden som utstedes etter autentisering hos den brukervalgte identitetstilbyderen. Når koden senere brukes mot token-endepunktet hos HelseID, må hemmeligheten, i klartekst, vedlegges forespørselen. HelseID hasher klarteksthemmeligheten og sammenligner med autorisasjonskodens assosierte hemmelighet.

PKCE

Eksempel på flyt for en desktop- eller mobilapplikasjon med dynamisk opprettet PKCE-hemmelighet mot HelseID

Desktopapplikasjon

Hybrid grant

Hybrid flow kombinerer mulighetene ved implicit og authorization code flow. For de fleste konfigurasjoner vil autorisasjonskode og identity token overføres via frontkanalen, mens access token og eventuelt refresh token hentes via bakkanalen. Det er mulig å også overføre access token via frontkanalen, for spesielle brukstilfeller.

Hybrid flow kan gjerne brukes for serverside-applikasjoner med en delt statisk hemmelighet, og native desktop- eller mobilapplikasjoner sammen med PKCE.

Client credentials grant

Client credentials er den enkleste granttypen, og brukes for server-til-server-kommunikasjon. Tokens forespørres alltid på vegne av en klient, ikke en bruker.

En klient autentiserer seg mot Token-endepunktet ved hjelp av klientidentifikatoren sin, samt en delt hemmelighet eller klientsertifikat.

Eksempel på flyt for en systemklient med delt hemmelighet overfor HelseID

Systemklient

Eksempel på flyt for en systemklient med klientsertifikat overfor HelseID

Systemklient_klientsertifikat

Resource owner password grant

Ikke relevant for HelseID siden løsningen ikke eier en brukerbase.

Extension grants

Extension grants muliggjør å utvide Token-endepunktet med nye (custom) grant types, noe som tillater skreddersøm av samhandlingen mellom klient og STS.