Page Comparison

T-1

Alle endepunkter i tjenesten skal være sikret med TLS.

O

T-2

Tjenesten skal støtte protokollen OpenID Connect.

O

T-3

Tjenesten skal støtte brukerautentisering på et sikkerhetsnivå angitt av selvdeklarasjonsforskriften. Forskriften finnes her: https://lovdata.no. 

O

T-4

Tjenesten skal angi hvilket sikkerhetsnivå en vellykket autentisering ble gjennomført på i påstanden "acr" [OIDC].

Følgende verdier ansees som gyldige: 

• "Lavt" 

• "Betydelig" 

• "Høyt" 

O

T-5

Tjenesten skal angi hvilken autentiseringsmekanisme som ble brukt for en vellykket autentisering i påstanden "amr" [OIDC].

• verdien for påstanden "amr" kan være en kommaseparert liste ["verdi1", "verdi2", ..] 

• gyldige verdier for amr er definert i https://tools.ietf.org/html/rfc8176  

O

T-6

Tjenesten skal alltid signere ID Tokens og JWT formatterte Access Tokens. 

O

T-7

Tjenesten skal ikke bruke "none" i JOSE header for JWTs eller Access Tokens. 

O

T-8

Tjenesten skal bruke de kryptografiske algoritmene PS256 eller ES256 til signering og kryptering.

O

T-9

Tjenesten skal ikke benytte algoritmer som er definert i kryptopakken RSASSA-PKCS1-v1_5 til signering eller kryptering. 

O

T-11

Tjenesten skal autentisere HelseID som klient med enten MTLS eller hemmelighetstypen "private_key_jwt". 

O

T-12

Tjenesten skal enten kreve verdiene "code" eller "code id_token

" som gyldige verdier for parameteret response_type i autentiseringsforespørselen. 

O

T-13

Tjenesten skal ikke støtte klienter som ikke blir autentisert, f.eks. ved bruk av “implicit flow”.

O

T-14

Tjenesten skal kunne beskytte autorisasjonskoden i Authorization Code Flow ved å tilby mekanismen Proof Key for Code Exchange (som definert i https://tools.ietf.org/html/rfc7636). 

O

T-

15

Tjenesten bør støtte kryptering av ID Token

V

T-

16

Tjenesten bør støtte autentiseringsforespørsler i form av JWT som angitt i OpenID Connect (https://openid.net/specs/openid-connect-core-1_0.html#JWTRequests).

Dersom tjenesten støtter autentiseringsforespørsler som JWT: 

• må verdien i parameteret "request" i autentiseringsforespørselen være en signert JWT. 

• må tjenesten ikke akseptere verdien alg: 'none' i JOSE headeren.

• bør tjenesten støtte at alle parametre for autentiseringsforespørselen kan finnes i et request object som blir sendt i request eller request_uri parameteret.

V

T-

17

Tjenesten bør tilby MTLS (https://www.rfc-editor.org/rfc/rfc8705.html) som mekanisme for å verifisere eierskap til privat nøkkel, og for å sikre mot tyveri av tokens. 

V

T-

18

Som angitt i anbefalingene for sikker bruk av TLS og DTSL (https://tools.ietf.org/html/bcp195) bør kun følgende kryptopakker (cipher suites) benyttes for TLS: 

• TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 

• TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 

• TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 

• TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 

V