Privat nøkkel JWT: Et sterkere alternativ for klientautentisering

Hvis du er kjent med OAuth 2.0 og OpenID Connect, vet du at klientapplikasjoner må autentisere seg overfor autorisasjonsserveren som en del av en sikker kode-for-token utveksling. Dette er nødvendig for å verifisere klientens identitet og sikre at bare legitime applikasjoner kan motta tokens fra autorisasjonstjeneren.

Klientautentisering kan gjøres på flere måter, som definert i Open ID Connect Core Client Authentication. Den vanligste tilnærmingen til klientautentisering i tradisjonelle serverbaserte applikasjoner er å bruke en client_secret: en delt passordlignende streng.

En mer robust alternativ metode er Private Key JWT. Med private_key_jwt beviser klientapplikasjoner sin identitet ved å signere et JSON Web Token (JWT) med den private nøkkelen til et asymmetrisk nøkkelpar. Denne signerte JWT-en(client_assertion) sendes deretter til autorisasjonsserveren for autentisering. Serveren validerer signaturen ved hjelp av klientens offentlige nøkkel, som er tilgjengelig via en tidligere etablert registrerings- eller oppdagelsesmekanisme.

Private Key JWT-klientautentisering er nå et krav for å kunne integreres med Finnish Trust Network (FTN). Denne metoden støttes imidlertid også fullt ut og anbefales også for andre eID-integrasjoner hvis applikasjonen din er en konfidensiell klient.

FTNs 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:

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

Vi har nettopp 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 tatt i bruk av andre eID-er i fremtiden, eller du kan rett og slett få en bedre forståelse av moderne autentiseringssikkerhet.

Fordelene med JWT-autentisering med privat nøkkel

Private Key JWT-autentisering har flere fordeler sammenlignet med tradisjonelle klienthemmeligheter.

1. Forbedret sikkerhet mot etterligning

Tradisjonell autentisering med klienthemmeligheter baserer seg på en delt hemmelighet og symmetrisk kryptografi. Hvis hemmeligheten blir lekket, snappet opp eller stjålet, kan hvem som helst utgi seg for å være applikasjonen din, noe som kompromitterer sikkerheten. For å gjøre vondt verre er klienthemmeligheter vanligvis langlivede og sendes i klartekst over kabelen. Hvis de skulle lekke ut via f.eks. delte HAR-spor, er det derfor svært sannsynlig at angriperen kan bruke dem.

Private Key JWT reduserer angrepsflaten for legitimasjonstyveri betydelig. Den bruker asymmetrisk kryptografi: Applikasjonen beholder en privat nøkkel for seg selv og deler bare den tilsvarende offentlige nøkkelen med autorisasjonsserveren.

Ved autentisering signerer applikasjonen en JWT med sin private nøkkel. Autorisasjonsserveren verifiserer signaturen ved hjelp av den registrerte offentlige nøkkelen. Den private nøkkelen forlater aldri applikasjonen din, og den offentlige nøkkelen kan ikke brukes til å forfalske en signatur og utgi seg for å være applikasjonen din.

Private Key JWT bruker også spesifikke JWT-påstander (som jti for unike ID-er og exp for utløp) for å forhindre replay-angrep, slik at hvert autentiseringsforsøk bare er gyldig én gang. En annen sikkerhetsfordel er den kortere levetiden til client_assertion - vanligvis maksimalt en time.

2. Sterkere bevis på opprinnelse og uavviselighet

Ved å bruke client_secret til autentisering blir det utfordrende å bevise at en bestemt klientapplikasjon har sendt en bestemt forespørsel. I teorien kan hvem som helst som har hemmeligheten, ha sendt den.

private_key_jwt-autentisering gir derimot mye sterkere bevis på at en spesifikk klient har initiert en forespørsel. I dette tilfellet deles aldri klientapplikasjonens private nøkkel eksternt, så sikkerheten avhenger kun av at nøkkelen forblir konfidensiell. Dette eliminerer sikkerhetsproblemer knyttet til autorisasjonsserverens lagring av legitimasjon eller andre kanaler som klienthemmeligheten kan sendes over.

Derfor gir den digitale signaturen som er innebygd i klient_bekreftelsen, sterk sikkerhet for at avsenderen ikke kan benekte handlingen. Autorisasjonstjeneren kan kryptografisk verifisere denne signaturen ved hjelp av den tilhørende offentlige nøkkelen, noe som bekrefter at bare den aktuelle klienten kan ha signert påstanden. Denne kryptografiske sikringen betyr at når en handling logges, vet du nesten helt sikkert hvilken klient som utførte den, noe som skaper et sterkere og mer pålitelig revisjonsspor.

3. Forenklet administrasjon av legitimasjon

Å administrere hele livssyklusen til delte hemmeligheter - sikker distribusjon, lagring og rotasjon - kan være en drifts- og sikkerhetsmessig byrde.

Med Private Key JWT er det ingen client_secret å distribuere eller rotere. Programmet ditt genererer ganske enkelt et asymmetrisk nøkkelpar og registrerer den offentlige nøkkelen sin hos autorisasjonsserveren én gang. Det er ingen hemmeligheter som må overføres under registrering og ved autentisering med autorisasjonsserveren. Og hvis du bestemmer deg for å rotere nøklene, genererer applikasjonen ganske enkelt det asymmetriske nøkkelparet på nytt, bytter ut den private nøkkelen og oppdaterer den offentlige nøkkelen som er registrert hos autorisasjonsserveren. Denne prosessen er i seg selv tryggere enn å erstatte en symmetrisk klienthemmelighet, fordi ingen hemmeligheter utveksles.

Oppsummert

Private Key JWT er en sterkere standard for å sikre klientautentisering i sensitive miljøer. Den har blitt stadig mer utbredt de siste årene på grunn av nye sikkerhetsstandarder (for eksempel fra Financial-grade API (FAPI)-arbeidsgruppen), økt bevissthet om risikoen for kompromittering av legitimasjon og ulike regulatoriske påtrykk, blant annet eIDAS.

Du kan begynne å bruke Private Key JWT-klientautentisering med Idura ved å følge denne veiledningen. Hvis du har spørsmål, er du velkommen til å sende en e-post til support@idura.eu eller kontakte oss på Slack.