Miksi allekirjoitetut valtuutuspyynnöt parantavat tietoturvaa
Allekirjoitetut valtuutuspyynnöt parantavat todennusvirtojen turvallisuutta, ja ne voidaan toteuttaa JWT-suojattuina valtuutuspyyntöinä (JAR). Tässä blogikirjoituksessa selvitämme, mitä JAR:t ovat ja miten ne suojaavat yleisiltä hyökkäysvektoreilta. Keskittyminen JAR:iin johtuu alan viimeaikaisesta kehityksestä ja erityisesti Suomen luottamusverkoston (FTN ) kirjautumisten uusista vaatimuksista.
FTN Security Requirements: What You Need to Know
The Finnish government is introducing new requirements to tighten authentication security of the Finnish Trust Network (FTN). The requirements are described in Recommendation 213/2023 S Finnish Trust Network OpenID Connect Profile and include:
- Private Key JWT client authentication
- Authentication request signing
- Encrypted token and userinfo responses
We've just implemented these changes at Criipto and are sharing the details with you in this article series. The goal is to explain the main concepts and demonstrate how these requirements enhance the overall security of authentication flows.
If you're integrating with FTN, you have to understand and implement these changes. Even if FTN is not among the eIDs you currently use, we encourage you to familiarize yourself with these concepts: similar security measures might be adopted by other eIDs in the future, or you might simply gain a better understanding of modern authentication security.
Tässä blogikirjoituksessa käsitellään todennuspyyntöjen allekirjoittamista, joka on toteutettu JARien avulla.
Huomautus: Käytämme tässä blogikirjoituksessa vaihtelevasti termejä "valtuutuspyynnöt", "valtuutuspyynnöt" ja "OIDC-todennuspyynnöt".Teknisesti ottaen OIDC-todennuspyyntö on OAuth 2.0 -valtuutuspyyntö, joka edellyttää loppukäyttäjän todennusta ja pyytää käyttäjän tunnistetietoja valtuutuspalvelimelta.
Tavallinen OAuth-auktorisointipyyntö
Tarkastellaan ensin perusvaltuutuspyyntöä.
Jos tunnet OAuth 2.0:n ja OpenID Connectin, tiedät, että asiakassovelluksen on lähetettävä valtuutuspyyntö valtuutuspalvelimelle käyttäjän todennusvirran käynnistämiseksi. Käyttäjän selain ohjataan valtuutuspalvelimelle seuraavanlaisella URL-osoitteella:
https://acme-corp.criipto.id/oauth2/authorize?client_id=your_client_id&response_type=code&scope=openid%20profile&state=abc
Tässä parametrit, kuten client_id, response_type, scope ja state, lähetetään suoraan URL-kyselymerkkijonossa.
Perinteisten valtuutuspyyntöjen ongelma
Vaikka perinteiset valtuutuspyynnöt ovat käteviä ja yksinkertaisia, niissä on useita luontaisia ongelmia, jotka voivat heikentää niiden turvallisuutta:
1. Väärinkäytön riski
Kun asiakassovelluksesi ohjaa käyttäjän selaimen valtuutuspalvelimelle, valtuutus-URL ja sen parametrit lähetetään avoimesti, ja ne voidaan siepata. Pahantahtoinen toimija voi muuttaa näitä parametreja ennen kuin pyyntö saapuu valtuutuspalvelimelle.
Pyynnön peukalointi voi johtaa vakaviin ongelmiin, kuten käyttäjän ohjaamiseen haitalliselle sivustolle todennuksen jälkeen (vaikka uudelleenohjaus on lähes aina suojattu) tai pyydettyjen käyttöoikeuksien muuttamiseen. Erityisen vaarallista on, jos hyökkääjä voi muuttaa scope- ja code_challenge-parametreja. Laajuusparametrin muuttaminen voi vaarantaa suuremman määrän henkilökohtaisia tietoja, kun taas code_challenge-parametrin muuttaminen julkiselle asiakkaalle poistaa käytännössä kaiken suojan koodin ja tunnuksen vaihdon aikana.
2. Epävarma alkuperä
Käyttäjän selain lähettää valtuutuspalvelimelle asiakassovelluksen käynnistämän tavallisen valtuutuspyynnön. Ei ole mitään luontaista kryptografista takuuta siitä, että pyyntö on peräisin sinun sovelluksestasi.
Kun perustiedot, kuten sovelluksesi asiakastunnus ja uudelleenohjauksen URI, ovat tiedossa, kuka tahansa voi luoda valtuutuspyynnön. Tämän vuoksi valtuutuspalvelimen on vaikea erottaa toisistaan laillinen pyyntö ja luvaton taho, joka yrittää esiintyä sovelluksenasi.
3. Ei takuuta luottamuksellisuudesta
Vaikka viestintäkanava on tyypillisesti suojattu HTTPS:llä, valtuutuspyynnön parametrit ovat silti näkyvissä ja eri välikäsien saatavilla. Näitä ovat esimerkiksi välityspalvelimet, kuormantasaajat tai jopa selainlaajennukset. Tämän seurauksena haitallinen verkkokomponentti voi lukea, syöttää tai muuttaa pyynnön parametreja.
Mitä ovat JAR-tiedostot?
JWT-suojattu auktorisointipyyntö (JAR) on RFC 9101:ssä määritelty menetelmä, jossa auktorisointipyynnön parametrit kapseloidaan JSON Web Tokeniin (JWT ), joka on allekirjoitettu sovelluksesi yksityisellä avaimella ja sisällytetty auktorisointipyyntöön pyyntöparametrin kautta.
Pohjimmiltaan vakiomuotoinen auktorisointipyyntö on rakenteeltaan seuraavanlainen:
https://acme-corp.criipto.id/oauth2/authorize?client_id=your_client_id&response_type=code&scope=openid%20profile&state=abc
muunnetaan seuraavasti:
https://acme-corp.criipto.id/oauth2/authorize?client_id=your_client_id&request=eyJhbGciOiJSUzI1NiIsImtpZCI6InlhcmxzZXYifQ.eyJpc3MiOiJ5b3VyX2NsaWVudF9pZCI...
Pyyntöparametri sisältää Request Objectin: JWT:n, jonka väittämät sisältävät JSON-koodatut valtuutuspyynnön parametrit.
Allekirjoitettujen valtuutuspyyntöjen edut
Allekirjoitetut valtuutuspyynnöt vahvistavat valtuutusvirran ja siitä johtuvan käyttäjän todennuksen turvallisuutta. Hyötyjä ovat mm:
1. Eheyden suojaaminen
Sisällyttämällä valtuutusparametrien koko joukon allekirjoitettuun JWT:hen valtuutuspalvelin voi tarkistaa kryptografisesti, että pyyntöä ei ole muutettu sen jälkeen, kun asiakassovelluksesi on allekirjoittanut sen. Mikä tahansa väärentäminen mitätöisi allekirjoituksen, ja pyyntö hylättäisiin.
2. Lähteen todennus ja kiistämättömyys
Pyyntöobjektin digitaalinen allekirjoitus toimii alkuperän todisteena. Vain asiakassovelluksesi, joka hallitsee julkisen ja yksityisen avaimen parin yksityistä avainta, voi luoda pätevän allekirjoituksen. Näin varmistetaan, että valtuutuspalvelin voi luottaa todennuspyynnön lähteeseen. Asiakkaasi ei voi myöhemmin kiistää lähettäneensä sitä, koska allekirjoitus toimii kryptografisena todisteena sen alkuperästä ja tarjoaa vahvemman kiistämättömyyden.
3. Tiedonkeruun minimointi
Verkkopalvelut saattavat pyytää enemmän henkilötietoja kuin on ehdottoman välttämätöntä, eivätkä käyttäjät useinkaan voi tarkistaa tietopyyntöjen laillisuutta. Tämän ongelman ratkaisemiseksi JAR-tiedostot voi allekirjoittaa luotettava kolmas osapuoli, joka todistaa, että valtuutuspyyntö on tietyn käytännön mukainen (esim. vahvistaa, että kaikki pyydetyt henkilötiedot ovat ehdottoman välttämättömiä käyttäjän aiottua prosessia varten). Valtuutuspalvelin voi tämän jälkeen tutkia tämän allekirjoituksen ja tarvittaessa näyttää käyttäjälle sen vaatimustenmukaisuuden tilan. Tämä varmistaa pyynnön laillisuuden, auttaa rajoittamaan tiedonkeruuta ja viime kädessä auttaa rakentamaan loppukäyttäjien luottamusta.
Yhteenvetona
Suomen luottamusverkoston uusi vaatimus allekirjoitetuista todennuspyynnöistä on askel kohti turvallisemman digitaalisen identiteetin ekosysteemin rakentamista.
Ottamalla tämän standardin käyttöön palveluntarjoajat ja asiakassovellukset voivat varmistaa todennuspyyntöjensä eheyden ja aitouden, mikä suojaa sekä käyttäjiä että palveluita yleisiltä hyökkäysvektoreilta.
Vaikka se tuo mukanaan ylimääräisen kryptografisen monimutkaisuuden, tietoturvahyödyt ovat huomattavasti suuremmat kuin toteutukseen liittyvät kustannukset.
