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.

 

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

OAuth 2.0 definerer 6 grant types (eksterne lenker):

HelseID tilbyr noen av disse autentiseringsflytene, blant annet:

Implicit grant

Implicit flow er av sikkerhetsmessige årsaker ikke lenger en anbefalt autentiseringsflyt, og vil etterhvert fjernes som en gyldig grant type i HelseID.

SPA (javascript) applikasjoner bør i stedet bruke:

  • Hybrid 
  • Code med PKCE 

SPA applikasjoner bør benytte en dedikert API Gateway, f.eks basert på "Backend-For-Frontend" (BFF) mønsteret.

Authorization code grant

I authorization code grant overføres ikke tokens 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 brukes for SPA med dedikert backend (API Gateway - f.eks BFF mønster), serverside-applikasjoner, 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.