Sikring av autentiseringsflyt med JSON Web Encryption

Vi har tidligere gjennomgått det grunnleggende om JSON Web Encryption (JWE), en IETF-standard som er utviklet for å holde data konfidensielle.

I dette blogginnlegg skal vi se nærmere på hvordan JWE kan bidra til å sikre sensitiv informasjon, spesielt i OpenID Connect-autentiseringsflyter.

FTN-sikkerhetskrav: Hva du trenger å vite

Den finske regjeringen innfører nye krav for å skjerpe autentiseringssikkerheten i det finske tillitsnettverket (FTN). Kravene er beskrevet i anbefaling 213/2023 S Finnish Trust Network OpenID Connect Profile og inkluderer:

• Klientautentisering med privat nøkkel JWT
• Signering av autentiseringsforespørsel
• Krypterte token- og brukerinformasjonssvar

Vi har implementert disse endringene hos Idura og deler detaljene med deg i denne artikkelserien. Målet er å forklare hovedkonseptene og demonstrere hvordan disse kravene forbedrer den generelle sikkerheten i autentiseringsflyten.

Hvis du integrerer med FTN, må du forstå og implementere disse endringene. Selv om FTN ikke er blant de eID-ene du bruker i dag, oppfordrer vi deg til å gjøre deg kjent med disse konseptene: lignende sikkerhetstiltak kan bli innført av andre eID-er i fremtiden, eller du kan rett og slett få en bedre forståelse av moderne autentiseringssikkerhet.

Krypterte token- og brukerinformasjonssvar kan implementeres ved hjelp av JWE .

Hva er JWE? (En rask oppsummering)

JSON Web Encryption (JWE) er en standard for kryptering av data og representasjon av dem i JSON-format.

JWE kan brukes på JSON Web Tokens (JWT-er) for å sikre datakonfidensialitet. I motsetning til standard JWT-er, som garanterer integritet og autentisitet, men gjør dataene lesbare, krypterer JWE innholdet slik at bare den tiltenkte mottakeren har tilgang til det. Ved å kombinere JWE med JSON Web Signature (JWS) kan du opprette et signert og kryptert token (nestet JWT) som kan brukes som et tilgangstoken i OAuth 2.0 eller et ID-token i OpenID Connect.

Slik fungerer det i autentiseringsflyter

Hvis du trenger en oppfriskning av hvordan autentiseringsflyter fungerer, har vi skrevet et annet blogginnlegg om hva som skjer når du logger inn med eID via Idura.

La oss nå se nærmere på autentiseringsflyten for å se hvordan krypterte token-svar endrer den, og hvilke fordeler det gir.

Standard autentiseringsflyt

Slik ser en standard autentiseringsflyt ut med en Identity Provider (IdP) som danske MitID eller FTN:

1. Etter at sluttbrukeren har autentisert seg hos en IdP, utsteder IdP-en en JWT med sluttbrukerens personlige informasjon og sender den til Idura, som deretter
   1. Lagrer brukerdata i sesjonslageret vårt.
   2. Genererer et kodeargument.
2. Idura omdirigerer sluttbrukeren til klientapplikasjonen med kodeargumentet.
3. Klientapplikasjonen kaller oauth2/token-endepunktet med kodeargumentet.
   1. Idura genererer et id_token basert på lagrede brukerdata.
   2. Idura lagrer brukerdata i sesjonslageret (beregnet på access_token og userinfo-endepunktet ).
   3. Idura genererer en access_token.
4. Idura svarer klientapplikasjonen med id_token og access_token.
5. (Valgfritt) Klientapplikasjonen kaller oauth2/userinfo med access_token.
   1. Idura genererer userinfo basert på de lagrede brukerdataene.
   2. Idura svarer klientapplikasjonen med brukerdataene.

I denne flyten kan Idura dekryptere brukerdataene (eller sesjonsdataene våre) når som helst etter trinn 1.1.

Autentiseringsflyt med kryptert token og brukerinfo-svar

En forutsetning er at klientapplikasjonen registrerer sin offentlige nøkkel hos Idura og oppbevarer den tilsvarende private nøkkelen i det asymmetriske nøkkelparet på en sikker måte.

1. Etter at sluttbrukeren har autentisert seg hos en IdP, utsteder IdP-en en JWT med sluttbrukerens personlige informasjon og sender den til Idura. Dette tokenet kan også krypteres (et krav for FTN), og i så fall bruker IdP-en Iduras offentlige nøkkel til krypteringen.
   1. Idura genererer et id_token, krypterer det med klientapplikasjonens offentlige nøkkel og lagrer det.
   2. Idura genererer userinfo, krypterer den med klientapplikasjonens offentlige nøkkel og lagrer den.
   3. Idura genererer et kodeargument.
2. Idura omdirigerer sluttbrukeren til klientapplikasjonen med kodeargumentet.
3. Klientapplikasjonen kaller oauth2/token-endepunktet med kodeargumentet.
   1. Idura returnerer et kryptert svar fra sesjonslageret vårt.
   2. Idura genererer et access_token.
4. Idura svarer klientapplikasjonen med id_token og access_token.
5. (Valgfritt) Klientapplikasjonen kaller oauth2/userinfo med access_token.
   1. Idura returnerer et kryptert svar fra sesjonslageret vårt til klientapplikasjonen.

I denne flyten kan Idura få tilgang til data i mye kortere tid ved å kryptere dem så tidlig som mulig.

Forbedret sikkerhet og overholdelse av GDPR

Ved å kryptere token- og brukerinformasjonssvarene med din offentlige nøkkel så tidlig som mulig, minimerer du Iduras tilgang til sensitive brukerdata.

En viktig fordel er forbedret GDPR-samsvar. I standardflyten lagrer vi sluttbrukernes personopplysninger i omtrent fire minutter og kan potensielt dekryptere og vise disse dataene. Med kryptering får Idura imidlertid ikke tilgang til disse dataene. Og selv om databasen vår skulle bli kompromittert, vil dataene forbli konfidensielle. Til syvende og sist betyr dette bedre databeskyttelse og sterkere overholdelse av GDPR.