Hvorfor signerte autorisasjonsforespørsler øker sikkerheten din

Signerte autorisasjonsforespørsler forbedrer sikkerheten i autentiseringsflyten og kan implementeres som JWT-sikrede autorisasjonsforespørsler (JAR). I dette blogginnlegget skal vi se nærmere på hva JAR-er er, og hvordan de beskytter mot vanlige angrepsvektorer. Dette fokuset på JAR-er er et resultat av den siste utviklingen i bransjen, og spesielt de nye kravene til innlogging i Finnish Trust Network (FTN).

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:

• Klientautentisering med privat nøkkel JWT
• 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.

Dette blogginnlegget handler om signering av autentiseringsforespørsler, som er implementert gjennom JAR-filer.

Merk: Vi bruker begrepene "autorisasjonsforespørsler", "autorisasjonsforespørsler" og "OIDC-godkjenningsforespørsler" om hverandre i dette blogginnlegget.Teknisk sett er en OIDC-godkjenningsforespørsel en OAuth 2.0-autorisasjonsforespørsel som krever sluttbrukergodkjenning og ber om informasjon om brukeridentitet fra autorisasjonsserveren.

Standard OAuth-autorisasjonsforespørsel

La oss først se på den grunnleggende autorisasjonsforespørselen.

Hvis du er kjent med OAuth 2.0 og OpenID Connect, vet du at klientapplikasjonen må sende en autorisasjonsforespørsel til autorisasjonsserveren for å sette i gang brukerautentiseringsflyten. Brukerens nettleser blir omdirigert til autorisasjonsserveren med en URL som denne:

https://acme-corp.idura.broker/oauth2/authorize?client_id=your_client_id&response_type=code&scope=openid%20profile&state=abc

Her sendes parametere som client_id, response_type, scope og state direkte i URL-spørringsstrengen.

Problemet med tradisjonelle autorisasjonsforespørsler

Selv om standard autorisasjonsforespørsler er praktiske og enkle, har de flere iboende problemer som kan undergrave sikkerheten:

1. Risiko for manipulering

Når klientapplikasjonen omdirigerer en brukers nettleser til autorisasjonsserveren, overføres autorisasjons-URL-en og tilhørende parametere åpent og kan fanges opp. En ondsinnet aktør kan endre disse parameterne før forespørselen når autorisasjonsserveren.

Manipulering av forespørsler kan føre til alvorlige problemer, for eksempel omdirigering av brukeren til et ondsinnet nettsted etter autentisering (selv om omdirigering nesten alltid er beskyttet) eller endring av de forespurte tillatelsene. Det er spesielt farlig hvis en angriper kan endre scope- og code_challenge-parametrene. Endring av scope-parameteren kan kompromittere en større mengde personopplysninger, mens endring av code_challenge for en offentlig klient i praksis fjerner all beskyttelse under utvekslingen av kode for token.

2. Usikker opprinnelse

En standard autorisasjonsforespørsel som initieres av klientprogrammet ditt, sendes til autorisasjonsserveren av brukerens nettleser. Det finnes ingen iboende kryptografisk garanti for at forespørselen stammer fra applikasjonen din.

Når grunnleggende detaljer som applikasjonens klient-ID og viderekoblings-URI er kjent, kan hvem som helst opprette en autorisasjonsforespørsel. Dette gjør det vanskelig for autorisasjonsserveren å skille mellom en legitim forespørsel og en uautorisert part som prøver å utgi seg for å være applikasjonen din.

3. Ingen garanti for konfidensialitet

Selv om kommunikasjonskanalen vanligvis er sikret med HTTPS, er parameterne i autorisasjonsforespørselen fortsatt synlige og tilgjengelige for ulike mellommenn. Dette kan være proxyer, lastbalansere eller til og med nettleserutvidelser.Dermed kan en ondsinnet nettverkskomponent lese, injisere eller endre forespørselsparametere.

Hva er JAR-er?

En JWT-sikret autorisasjonsforespørsel (JAR) er en metode som er definert i RFC 9101, der parameterne for autorisasjonsforespørselen er innkapslet i et JSON Web Token (JWT) som er signert med applikasjonens private nøkkel og inkludert i autorisasjonsforespørselen via forespørselsparameteren.

En standard autorisasjonsforespørsel er i hovedsak strukturert slik:

https://acme-corp.idura.broker/oauth2/authorize?client_id=your_client_id&response_type=code&scope=openid%20profile&state=abc

blir transformert som følger:

https://acme-corp.idura.broker/oauth2/authorize?client_id=your_client_id&request=eyJhbGciOiJSUzI1NiIsImtpZCI6InlhcmxzZXYifQ.eyJpc3MiOiJ5b3VyX2NsaWVudF9pZCI...

Forespørselsparameteren inneholder Request Object: JWT-en som inneholder de JSON-kodede parameterne for autorisasjonsforespørselen.

Fordelene med signerte autorisasjonsforespørsler

Signerte autorisasjonsforespørsler styrker sikkerheten i autorisasjonsflyten og den resulterende brukerautentiseringen. Fordelene inkluderer:

1. Integritetsbeskyttelse

Ved å inkludere hele settet med autorisasjonsparametere i en signert JWT kan autorisasjonstjeneren kryptografisk verifisere at forespørselen ikke har blitt endret etter at den ble signert av klientprogrammet. Enhver manipulering vil ugyldiggjøre signaturen, og forespørselen vil bli avvist.

2. Kildeautentisering og uavviselighet

Den digitale signaturen på forespørselsobjektet fungerer som opprinnelsesbevis. Bare klientprogrammet ditt, som kontrollerer den private nøkkelen i det offentlig-private nøkkelparet, kan generere en gyldig signatur. Dette sikrer at autorisasjonstjeneren kan stole på kilden til autentiseringsforespørselen. Klienten kan ikke senere nekte for å ha sendt den, ettersom signaturen fungerer som kryptografisk bevis på opprinnelsen og gir sterkere uavviselighet.

3. Minimering av datainnsamling

Nettbaserte tjenester kan be om flere personopplysninger enn strengt tatt nødvendig, og brukerne kan ofte ikke verifisere at dataforespørslene er legitime. For å løse dette kan JAR-er signeres av en betrodd tredjepart som bekrefter at autorisasjonsforespørselen er i samsvar med en bestemt policy (f.eks. at alle personopplysningene som etterspørres, er strengt nødvendige for brukerens tiltenkte prosess). Autorisasjonsserveren kan deretter undersøke denne signaturen og om nødvendig vise brukeren om den er i samsvar med retningslinjene. Dette sikrer at forespørselen er legitim, bidrar til å begrense datainnsamlingen og bidrar i siste instans til å bygge opp sluttbrukernes tillit.

Oppsummert

Det finske tillitsnettverkets nye krav om signerte autentiseringsforespørsler er et skritt i retning av å bygge et sikrere økosystem for digital identitet.

Ved å ta i bruk denne standarden kan tjenesteleverandører og klientapplikasjoner sikre integriteten og autentisiteten til autentiseringsforespørslene sine, noe som beskytter både brukerne og tjenestene deres mot vanlige angrepsvektorer.
Selv om det introduserer et ekstra lag med kryptografisk kompleksitet, oppveier sikkerhetsfordelene langt implementeringsinnsatsen.