Brukerhistorier som støttes

Det er flere situasjoner der det ønskes "sømløs" integrasjon for innbygger mellom et eksternt system/applikasjon og Helsenorge. Helsenorge sikkerhetstjeneste har derfor et OpenID Connect endepunkt der Helsenorge gir det eksterne systemet informasjon om innlogget innbygger. Denne tjenesten understøtter to Usecase:

UseCase 1: En innbygger som allerede er innlogget på Helsenorge kan gå over fra Helsenorge til eksternt system ved å velge en funksjon på Helsenorge som involverer det eksterne systemet (“uthopp”).

Når uthopp skjer fra Helsenorge, kalles en URL som peker til det endepunkt i det ekstrene systemet som starter OIDC-flyten mot Helsenorge sikkerhetstjeneste. Når dette endepunktet kalles fra Helsenorge skal det eksterne systemet alltid kalle Helsenorge OpenID Connect provider for å reautentisere den innbygger på Helsneorege som nå gjør “uthoppet”.

1. Gjennom OpenID Connect flyten gir Helsenorge sikkerhetstjeneste det eksterne systemet alltid informasjon (via IdToken) om både hvem innlogget innbygger er samt hvem som er representert innbygger (pasienten). Dersom dette ikke er samme person oppgis også relasjon mellom innlogget innbygger og pasient som representeres (foreldrerepresentasjon eller fullmakt). Videre gis det et AksessToken som siden kan benyttes dersom det eksterne systemet skal benytte. API’er på Helsenorge i “innbygger context”..

2. Innbygger er etter dette innlogget i både det eksterne systemet og på Helsenorge:

   1. Man er innlogget på Hesenorge inntil man logger seg av selv, eller etter 30 minutter inaktivitet

   2. Det eksterne systemet kan settes opp i Helsenorge sikkerhetstjeneste på to alternative måter (der alternativ 1 er “default”, og det som normalt benyttes):

      1. Uavhengig: Utlogging (manuelt eller på inaktivitet) skjer i det eksterne systemet. Dette systemet skal da kalle /revoke endepunktet, Merk! Innbygger logges ikke automatisk ut av Helsenorge, selv om man logger ut i det eksterne systemet.

      2. Med single sign-out: Da logges man automatisk ut av det eksterne systemet når man logger ut av Helsenorge. (Dette krever at det eksterne systemet støtter front-channel logout). Dette er normalt ikke en ønskjet konfigurering.

UseCase 2: En innbygger starter med å skulle logge seg inn i et eksternt system (eller MobilAPP). Dette systemet har valgt å benytter Helsenorge OpenID Connect provider. Systemet må ha etablert en integrasjon med Helsenorge for andre digitale helsetjenester utover innlogging for at slik bruk av Helsenorge innloggingstjeneste kan benyttes.

Det eksterne systemet, kontakter Helsenorge OpenID Connect provider for å logge innbygger inn på Helsenorge.

1. Dersom innbygger ikke allerede er innlogget, vil innbygger måtte logge seg inn (via ID-porten).

2. Dersom innbygger ikke allerede er Helsenorge bruker, vil innbygger måtte akseptere bruksvilkårene for Helsenorge.

3. Etter at innbygger er logget inn, vil det eksterne systemet gjennom OpenID Connect flyten få informasjon om innlogget innbygger. Videre gis det et AksessToken som siden kan benyttes dersom det eksterne systemet skal benytte API’er på Helsenorge.

4. Innbygger er innlogget i det eksterne systemet, og i Helsenorge (selv om det ikke finnes noe browser vindu der Helsenorge forsiden vises). Men, dersom innbygger velger å selv gå til Helsenorge, er hen altså allerede innlogget.

5. Det eksterne systemet i denne UseCase alltid opp uavhengig utlogging: Utlogging (manuelt eller på inaktivitet) skjer i det eksterne systemet. Dette systemet skal da kalle /revoke endepunktet.

Overordnet logisk flyt

Dette er en forenklet overordnet beskrivelse av dataflyten mellom eksternt system og STS (mer detaljer finnes på undersiden: V3 - OpenID Connect /API-tilgang (IdToken og AccessToken)

F1: Uthopp fra Helsenorge for allerede innlogget innbygger (URL til “startpunkt” for innbygger i eksternt system). Denne kan ha parametere f.eks. time-id ved videoløsning. Kun relevant for UseCase 1 over (uthopp).

O1: Krav for “public clients; opsjonelt for “confidential clients”: Eksternt system/app kontakter STS sitt endepunkt /PAR for å autentisere seg og overføre parametere som skal benyttes. (Se: /par )

O2: Det eksterne system kontakter /Authorize endepunktet i STS for å logge innbygger inn (se: /authorize ) Det skjer da en redirect i innbyggers nettleser. Innbygger logger inn (eventuelt er allerede innlogget). Resultatet er en AutorisasjonsKode, som systemet/app’en siden må benytte for å få ID-token, AksessToken og eventuelt Refreshtoken.

O3: Eksternt system kontakter STS endepunkt /Token for å få ID-token og AksessToken. AutorisasjonsKode som ble “mottatt” via redirect i innbyggers nettleser (O2) må være med i input. (Se: /token grant_type=authorization_code)

• ID-token inneholder påloget innbygger samt representert innbygger. Videre angis type representasjonsforhold hvis relevant.

• AksessToken gir rettigheter til å kalle Helsenorge API’er i innbygger kontekst (hvis relevant)

F2: Eksternt system/app kan siden benytte AksessToken for å få tilgang til API’er på Helsenorge i “innbygger-context”.

O4: Når innbygger er ferdig/logger ut i eksternt system, skal dette systemet kalle STS for å revokere AksessToken (eventuelt RefreshToken) som er utstedt til systemet/applikasjonen. (Se /revoke )

Detaljert beskrivelse av endepunkter og flyt finnes i denne undersiden: V3 - OpenID Connect /API-tilgang (IdToken og AccessToken)