Miten allekirjoitetut valtuutuspyynnöt parantavat tietoturvaa

Allekirjoitetut valtuutuspyynnöt lisäävät tunnistautumisprosessien turvallisuutta, ja ne voidaan toteuttaa JWT-suojattuina valtuutuspyyntöinä (JWT-secured Authorization Requests, JAR). Tässä artikkelissa käymme läpi, mitä JAR:t ovat ja miten ne suojaavat yleisimmiltä verkkohyökkäyksiltä. Aihe on erityisen ajankohtainen viimeaikaisten alan muutosten myötä, erityisesti Suomen luottamusverkoston (FTN) kirjautumista koskevien uusien vaatimusten vuoksi.

FTN:n turvallisuusvaatimukset: mitä sinun on hyvä tietää

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 -asiakastunnistamisen
• Todennuspyyntöjen allekirjoittamisen
• Tokenien ja käyttäjätietovastausten (userinfo) salauksen

Olemme juuri ottaneet nämä muutokset käyttöön Iduran palveluissa ja kerromme niistä tarkemmin tässä artikkelisarjassa. Tavoitteena on selittää keskeiset käsitteet ja havainnollistaa, miten nämä vaatimukset parantavat tunnistautumisprosessien kokonais­turvallisuutta.

Jos olet integroimassa FTN-tunnistautumista palveluusi, nämä muutokset on tärkeää ymmärtää ja toteuttaa. Vaikka FTN-tunnistautuminen ei olisi tällä hetkellä käytössäsi olevien eID-tunnisteiden joukossa, näihin tunnisteisiin kannattaa silti tutustua. Vastaavat tietoturvakäytännöt voivat tulevaisuudessa yleistyä myös muissa eID-ratkaisuissa tai ainakin syventää ymmärrystä modernin tunnistautumisen tietoturvasta.

Tässä blogikirjoituksessa keskitymme JAR-prosessin kautta tehtävien todennuspyyntöjen allekirjoittamiseen.

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 perusmuotoista valtuutuspyyntöä.

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 turvallisuutta heikentäviä ongelmia:

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 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 autorisointipyyntö (JAR) on RFC 9101:ssä määritelty menetelmä, jossa autorisointipyynnön parametrit kapseloidaan JSON Web Tokeniin (JWT ), joka on allekirjoitettu sovelluksesi yksityisellä avaimella ja sisällytetty autorisointipyyntöön pyyntöparametrin kautta.

Pohjimmiltaan vakiomuotoinen autorisointipyyntö 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 todentaminen ja kiistämättömyys

Request Objectiin liitetty digitaalinen allekirjoitus toimii todisteena pyynnön alkuperästä. Vain asiakassovelluksesi, joka hallitsee julkisen ja yksityisen avainparin yksityistä avainta, voi luoda validin allekirjoituksen. Näin varmistetaan, että autorisointipalvelin voi luottaa tunnistautumispyynnön lähteeseen. Asiakassovelluksesi ei myöhemmin voi kiistää lähettäneensä pyyntöä, sillä allekirjoitus toimii kryptografisena todisteena pyynnön alkuperästä, jolloin sen lähettäminen on kiistämättömästi todistettavissa.

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 valtuutuspyynnön olevan 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 voi tarvittaessa näyttää käyttäjälle, täyttääkö pyyntö tarvittavat vaatimukset. 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ä verkkohyökkäyksiltä. Vaikka standardin käyttöönotto tuo mukanaan ylimääräisen kryptografisen monimutkaisuuden, tietoturvahyödyt ovat huomattavasti suuremmat kuin toteutukseen liittyvät kustannukset.