Validering av ID-token

Hvis klienten krever en pålogget bruker, gjelder følgende krav for validering av ID-token fra HelseID:

  • Klienten validere token-signaturen:

  • Hvis klienten har lokale brukeridentiteter, den sjekke at den lokalt innloggede brukeren er den samme personen som brukeren som har logget inn med HelseID. Denne sjekken kan gjøres ved bruk av ett av følgende claims: helseid://claims/identity/pid, sub (en hash av fødselsnummeret), eller helseid://claims/hpr/hpr_number.

  • Klienten bør sjekke at brukeren er autentisert av en identitetsleverandør (BankID, ID-porten etc.) på et gyldig sikkerhetsnivå. Denne sjekken kan gjøres ved bruk av følgende claim: helseid://claims/identity/security_level.

  • «Issuer Identifier» for HelseID (som finnes på metadata-endepunktet) være eksakt lik verdien av iss (issuer)-claimet.

    • Hvis klienten godtar mer enn én identitetsleverandør, klienten inspisere iss-parameteret fra token-responsen, og korrelere verdien fra dette parameteret til «Issuer Identifier».
  • Klienten validere at aud (audience)-claimet samsvarer med client_id-verdien. Dette impliserer at kun klient-id kan brukes som en gyldig audience.

  • Klienten inspisere exp-claimet, og validere at levetiden på tokenet ennå ikke har gått ut.

  • Klienten bør sjekke verdien auth_time-claimet og gjøre en ny brukerpålogging hvis klienten mener at for mye tid har gått siden brukeren logget på.

  • iat-claimet kan bli brukt for å avvise ID-token som ble utstedt for lenge tilbake i tid fra nåværende tidspunkt. Klienten må selv velge det akseptable tidsintervallet.

  • Hvis en nonce-verdi ble sendt inn i forespørselen til /par (ev. /authorize)-endepunktet, vil et nonce-claim være tilgjengelig i ID-tokenet, og klienten sjekke at det er den samme verdien som ble sent i forespørselen. Klienten bør sjekke nonce-verdien med tanke på replay-angrep. Metoden for å detektere slike angrep er spesifikk for klienten.

Hensyn vedrærende levetiden til ID-token

Levetiden til ID-tokenet bør ikke bli brukt for å spesifisere levetiden til brukersesjonen. Dette innebærer at klienten ikke må korrelere verdien av exp-claimet med brukersesjonen. Hvis levetiden til brukersesjonen må sjekkes, bør verdien av auth_time-claimet brukes.

Generelle hensyn

  • ID-token er beregnet for bruk av klienten, og bør ikke bli levert til andre parter, for eksempel API-er.

  • ID-token bør bli persistert i klienten for å la brukeren gjøre en enkel utlogging.

ℹ️  Bruk av biblioteker

Hvis et klientbibliotek er tilgjengelig for din programvare, du bruke det. Likefullt er det opp til deg å sikre at dette biblioteket faktisk gjør funksjonaliteten som er beskrevet ovenfor.

ℹ️  Om Access-token

Klienten må ikke inspisere eller validere Access-tokenet som blir returnert fra HelseID. Fra klientens ståsted er Access-tokenet ugjennomsiktig, og kan kun inspiseres av et API.