Private Key JWT: Vahvempi vaihtoehto asiakkaiden tunnistamiseen

 Jos OAuth 2.0 ja OpenID Connect ovat sinulle tuttuja, tiedät, että asiakassovellusten on todennettava itsensä autorisointipalvelimelle osana turvallista koodi–token-vaihtoa. Tämä on tarpeen, jotta voidaan varmistaa asiakkaan identiteetti ja taata, että vain luotettavat sovellukset voivat saada tokeneita autorisointipalvelimelta. 

Asiakkaan todennus voidaan tehdä useilla eri tavoilla, jotka on määritelty Open ID Connect Core Client Authentication -a0siakirjassa. Yleisin lähestymistapa asiakkaan todennukseen perinteisissä palvelinpohjaisissa sovelluksissa on client_secret eli jaettu salasanan kaltainen merkkijono.

Vankempi vaihtoehtoinen menetelmä on Private Key JWT. Käyttämällä Private_key_jwt:tä asiakassovellukset todistavat henkilöllisyytensä allekirjoittamalla JSON-verkkotunnisteen (JWT ) epäsymmetrisen avainparin yksityisellä avaimella. Tämä allekirjoitettu JWT(client_assertion) lähetetään sitten valtuutuspalvelimelle todentamista varten. Palvelin vahvistaa allekirjoituksen käyttämällä asiakkaan julkista avainta, johon pääsee käsiksi aiemmin luodun rekisteröinti- tai havaintomekanismin kautta.

Yksityisen avaimen JWT-asiakkaan todennus on nyt edellytys integroitumiselle Suomen luottamusverkostoon (FTN). Tämä menetelmä on kuitenkin täysin tuettu ja suositeltava myös muissa eID-integraatioissa , jos sovelluksesi on luottamuksellinen asiakas.

FTN:n tietoturvavaatimukset – mitä sinun on hyvä tietää

 Suomen viranomaiset ovat ottamassa käyttöön uusia vaatimuksia, joilla tiukennetaan Suomen luottamusverkoston (FTN) tunnistautumisen tietoturvaa. Vaatimukset on kuvattu suosituksessa 213/2023 S Finnish Trust Network OpenID Connect Profile, ja ne sisältävät muun muassa: 

• Private Key JWT -asiakastodennuksen
• Tunnistautumispyyntöjen allekirjoituksen
• Salatut token- ja userinfo-vastaukset

Olemme juuri päivittäneet Iduran palvelut kattamaan nämä muutokset ja käymme niiden yksityiskohtia läpi tässä artikkelisarjassa. Tavoitteena on selittää keskeiset käsitteet ja havainnollistaa, miten nämä vaatimukset parantavat tunnistautumisprosessien kokonaisturvallisuutta.

Jos olet integroimassa FTN-tunnisteita osaksi palveluasi, nämä muutokset on tärkeää ymmärtää ja ottaa käyttöön. Vaikka FTN ei kuuluisi tällä hetkellä käyttämiisi eID-ratkaisuihin, on silti suositeltavaa tutustua näihin käsitteisiin. Vastaavat tietoturvavaatimukset voivat tulevaisuudessa yleistyä myös muissa eID-ratkaisuissa – tai ainakin syventää ymmärrystä modernin tunnistautumisen tietoturvasta.

Private Key JWT -todennuksen edut

Private Key JWT -todennus tarjoaa useita etuja perinteisiin asiakassalaisuuksiin verrattuna.

1. Parannettu suojaus henkilöitymistä vastaan

Perinteinen client_secret -todennus perustuu jaettuun salaisuuteen ja symmetriseen salaukseen. Jos salaisuus vuotaa, siepataan tai varastetaan, kuka tahansa voi esiintyä sovelluksesi henkilöllisyydeksi, mikä vaarantaa sen turvallisuuden. Kaiken kukkuraksi asiakassalaisuudet ovat yleensä pitkäikäisiä ja ne lähetetään selväkielisinä langan välityksellä. Jos ne siis sattuvat vuotamaan esimerkiksi jaettujen HAR-jälkien kautta, hyökkääjä pystyy hyvin todennäköisesti käyttämään niitä.

Private Key JWT vähentää huomattavasti hyökkäyspintaa valtakirjojen varastamiseen. Siinä käytetään epäsymmetristä salausta: Sovelluksesi pitää yksityisen avaimen itsellään ja jakaa valtuutuspalvelimen kanssa vain vastaavan julkisen avaimen.

Todentamisen yhteydessä sovelluksesi allekirjoittaa JWT:n yksityisellä avaimellaan. Valtuutuspalvelin tarkistaa allekirjoituksen rekisteröidyn julkisen avaimesi avulla. Yksityinen avain ei siis koskaan poistu sovelluksestasi, eikä julkista avainta voida käyttää allekirjoituksen väärentämiseen ja sovelluksesi esittämiseen.

Private Key JWT käyttää myös erityisiä JWT-väitteitä (kuten jti yksilöllisille tunnuksille ja exp voimassaolon päättymiselle) estääkseen toistohyökkäykset ja varmistaakseen, että jokainen todennusyritys on voimassa vain kerran. Toinen turvallisuusetu on client_assertion eli lyhyempi käyttöikä, joka on voimassa yleensä enintään tunnin.

2. Vahvempi todiste alkuperästä ja kiistämättömyydestä.

Kun todennuksessa käytetään client_secret-tunnistetta, on haastavaa todistaa, että tietty asiakassovellus on lähettänyt tietyn pyynnön. Teoriassa kuka tahansa, jolla on salaisuus, olisi voinut lähettää sen.

private_key_jwt-todennus sen sijaan tarjoaa paljon vahvemman todisteen siitä, että tietty asiakas on käynnistänyt pyynnön. Tässä tapauksessa asiakassovelluksen yksityistä avainta ei koskaan jaeta ulkopuolisille, joten sen turvallisuus riippuu vain siitä, että avain pysyy luottamuksellisena. Tämä poistaa tietoturvaongelmat, jotka liittyvät valtuutuspalvelimen valtakirjojen säilytykseen tai kanaviin, joiden kautta client_secret voitaisiin lähettää.

Siksi client_assertioniin upotettu digitaalinen allekirjoitus tarjoaa vahvan kiistämättömyyden. Valtuutuspalvelin voi kryptografisesti tarkistaa tämän allekirjoituksen käyttämällä vastaavaa julkista avainta ja vahvistaa, että vain kyseinen asiakas on voinut allekirjoittaa väitteen. Tämä kryptografinen varmuus tarkoittaa, että kun toiminto kirjataan, tiedät lähes varmasti , mikä asiakas sen suoritti, mikä puolestaan luo vahvemman ja luotettavamman kirjausketjun.

3. Yksinkertaistettu valtakirjojen hallinta

Jaettujen salaisuuksien koko elinkaaren - turvallisen jakelun, säilytyksen ja kiertämisen - hallinta voi olla toiminnallinen ja tietoturvallinen taakka.

Private Key JWT:n avulla client_secretiä ei tarvitse jakaa tai kiertää. Sovelluksesi vain luo epäsymmetrisen avainparin ja rekisteröi julkisen avaimensa kerran valtuutuspalvelimelle. Salaisuuksia ei tarvitse välittää rekisteröinnin aikana eikä auktorisointipalvelimella todennettaessa. Ja jos päätät vaihtaa avaimia, sovelluksesi yksinkertaisesti luo asymmetrisen avainparin uudelleen, korvaa yksityisen avaimensa ja päivittää valtuutuspalvelimelle rekisteröidyn julkisen avaimen. Tämä prosessi on luonnostaan turvallisempi kuin symmetrisen asiakassalaisuuden vaihtaminen, koska salaisuuksia ei vaihdeta.

Yhteenvetona

Private Key JWT on vahvempi standardi asiakkaan todennuksen suojaamiseen arkaluonteisissa ympäristöissä. Sen viime vuosina lisääntynyt käyttöönotto johtuu kehittyvistä turvallisuusstandardeista (kuten FAPI-työryhmän (Financial-grade API) standardeista), lisääntyneestä tietoisuudesta valtakirjojen vaarantamisriskeistä ja erilaisista sääntelyponnisteluista, kuten eIDAS:sta.

Voit aloittaa Private Key JWT -asiakastodennuksen käytön Iduran kanssa noudattamalla tätä opasta. Jos sinulla on kysyttävää, lähetä sähköpostia osoitteeseen support@idura.eu tai ota yhteyttä Slackissa.