Gå til hovedinnhold

Sikring av API

HelseID tilbyr tilgangssikring av dine API ved hjelp av OAuth 2.0 mekanismene. Her finner du litt overordnet informasjon om hvordan det fungerer.

En av oppgavene HelseID kan hjelpe deg med er å sikre dine API. Vi tilbyr mekanismer som bygger på et rammeverk som heter OAuth 2.0, og som i kombinasjon med mekanismene som er definert av protokollen OpenId Connect gir deg mulighet til å utføre tilgangskontroll av sluttbrukere.

Dersom du som eier av en Ressursserver har spesielle behov som ikke dekkes av standard protokollflyt kan du ta kontakt med HelseID på helseid@nhn.no

Klientkonfigurasjon ligger i HelseID

En OAuth 2.0 klient er en applikasjon som konsumerer en ressurs (API) på vegne av en bruker. Denne klienten må opprettes og konfigureres på riktig måte i HelseID. I tillegg til annen informasjon vil konfigurasjonen også angi hvilke API denne klienten har tillatelse til å bruke.

Når klienten skal kalle et gitt API må den først be HelseID om å få utstedt en sikkerhetsbillett (token) som bevis på at den har tillatelse til å kalle APIet. Når klienten har mottatt dette tokenet fra HelseID må det legges ved i forespørselen mot APIet. APIet må undersøke sikkerhetsbillettene den mottar for å være sikker på at klienten er en godkjent konsument.

OAuth 2.0

Access Tokens i HelseID

OAuth 2.0 spesifikasjonen stiller ingen krav til format i Access Tokens, men i HelseID vil alle Access Tokens alltid være formatterte som JWTs. Det vil si at de alltid vil være signerte med HelseIDs signeringssertifikat. Dermed kan APIet være sikker på at billetten er utstedt av HelseID, og at informasjonen ikke er endret etter at den ble utstedt.

Dersom en bruker er involvert i forespørselen om tilgang til en ressurs vil Access Tokens utstedt av HelseID også kunne innholde informasjon om den autentiserte brukeren. 

Forespørsel om tilgang til ressurs

En klient må få konfigurert en eksplisitt tillatelse til å få utstedt et token som kan brukes mot et spesifikt API. Denne tillatelsen uttrykker vi med det vi kaller et scope.

Et tenkt eksempel på et scope i OAuth 2.0 sammenheng kunne ha vært "https://www.minehelsedata.no/patient/read" - som f.eks kunne ha gitt en klient tilgang til å lese pasientdata fra et API.

Når klienten ber om et Access Token må den altså angi ønsket scope i forespørselen, og dersom klientens konfigurasjon i HelseID tilsier at den har tilgang til dette scopet kan HelseID generere og utstede et nytt token.

Når APIet så mottar forespørselen må det verifisere at det riktige scopet er angitt i Access Tokenet, og at sikkerhetsbilletten er gyldig.