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äyksiltä. Keskittyminen JAR:iin liittyy alan viimeaikaiseen kehitykseen ja erityisesti Suomen luottamusverkoston (FTN) kirjautumisten uusiin vaatimuksiin.

FTN:n turvallisuusvaatimukset: mitä sinun on tiedettävä

Suomen viranomaiset ovat ottaneet käyttöön uusia vaatimuksia FTN:n todennuksen tietoturvan parantamiseksi. Vaatimukset on kuvattu suosituksessa 213/2023 S Finnish Trust Network OpenID Connect Profile ja ne sisältävät:

• Private Key JWT -asiakasautentikoinnin
• Todennuspyyntöjen allekirjoittamisen
• Tokenien ja käyttäjätietovastausten salauksen

Olemme juuri toteuttaneet nämä muutokset Idura ja jaamme yksityiskohdat tässä artikkelisarjassa. Tavoitteena on selittää keskeiset käsitteet ja osoittaa, miten vaatimukset vahvistavat todennusvirtojen kokonaisvaltaista turvallisuutta.

Jos integroit FTN:ään, sinun on ymmärrettävä ja toteutettava nämä muutokset. Vaikka FTN ei vielä kuulu käyttämiisi eID-tunnisteisiin, suosittelemme tutustumaan näihin käsitteisiin: vastaavia turvatoimia saatetaan ottaa käyttöön myös muissa eID-ratkaisuissa tulevaisuudessa, ja samalla syvennät ymmärrystäsi modernista todennusturvallisuudesta.

Tässä blogikirjoituksessa keskitymme todennuspyyntöjen allekirjoittamiseen JARien avulla.

Huomautus: Käytämme vaihtelevasti termejä "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-valtuutuspyyntö

Tarkastellaan ensin perusvaltuutuspyyntöä.

Jos tunnet OAuth 2.0:n ja OpenID Connectin, tiedät, että asiakassovellus lähettää valtuutuspyynnön valtuutuspalvelimelle käynnistääkseen käyttäjän todennusvirran. Käyttäjän selain ohjataan valtuutuspalvelimelle URL-osoitteella, kuten:

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

Parametrit, kuten client_id, response_type, scope ja state, välitetään suoraan URL-kyselymerkkijonossa.

Perinteisten valtuutuspyyntöjen ongelmat

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.idura.broker/oauth2/authorize?client_id=your_client_id&response_type=code&scope=openid%20profile&state=abc

muunnetaan seuraavasti:

https://acme-corp.idura.broker/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.