Sikkerhetsprofil for HelseID-klienter og API-er
Dette dokumentet inneholder standardene som kreves for enhver programvare som skal ta i bruk HelseID-tjenesten.
| Termer | |
|---|---|
| HelseID | En autorisasjonstjener, som beskrevet i RFC 6749. Blir brukt til å sikre nasjonale API-er for helsesektoren. |
| Klient | En klient (client) som definert i RFC 6749. I kontekst av HelseID er en klient en programvareinstallasjon som følger denne sikkerhetsprofilen. |
| Konfidensiell klient | Konfidensielle klienter er klienter som har mulighet til å opprettholde konfidensialiteten til en klienthemmelighet. Alle klienter som bruker HelseID må autentisere seg med denne hemmeligheten. Enhver klient som bruker HelseID må være en konfidensiell klient. |
| Klientautentisering | Prosessen der en klient beviser sin identitet til autorisasjonstjeneren. I HelseID blir dette alltid gjort med å signere en JWT med en privatnøkkel, slik at denne privatnøkkelen korresponderer med en offentlig nøkkel som finnes registrert i HelseID. |
Med unntak av et par forskjeller, som er lagt til for å gjøre det enklere å bruke HelseID i helsesektoren, er sikkerhetsprofilen til HelseID lik FAPI 2.0-profilen. Forskjellene er som følger:
- HelseID tillater at en lokalt installert tykklient kan bli sett på som en konfidensiell klient.
- MTLS for klientautentisering er ikke støttet.
- "Consent" (samtykke for bruk av HelseID for innlogging) blir ikke brukt.
- HelseID stiller eksplisitte krav om generell websikkerhet, vi forventer at du i det minste har kontroll på OWASP Top 10.
- For applikasjoner som støtter lokal innlogging og deretter innlogging med HelseID stiller vi krav om at applikasjonen må ha mekanismer for å sikre at de to innloggingene er gjort av samme person.
HelseID skiller mellom sikkerhetskrav og funksjonelle krav. Hensikten er å gjøre det lettere å kunne skille mellom sikkerhetskravene fra FAPI 2.0-profilen og NHN sine egne funksjonelle krav. Sikkerhetskravene er obligatoriske og må følges av alle klienter og API-er som integrerer med HelseID. De funksjonelle kravene er også obligatoriske, men avvik kan vurderes i enkelte tilfeller.
Som et supplement til sikkerhetsprofilen har vi publisert dette dokumentet som forklarer hvorfor vi stiller de ulike kravene.