Miten JSON Web Encryption suojaa tunnistautumisprosesseja

Olemme aiemmin käsitelleet IETF:n standardiin sisältyvän JSON Web Encryptionin (JWE) perusteita. JWE-suojaus on suunniteltu pitämään tiedot luottamuksellisina.

Tämänpäiväisessä blogikirjoituksessa tarkastelemme, miten JWE voi auttaa suojaamaan arkaluonteisia tietoja erityisesti OpenID Connect -tunnistautumisprosesseissa.

Mitä sinun on hyvä tietää FTN:n tietoturvavaatimuksista

Kuten mainitsimme aiemmassa kirjoituksessamme, 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.

 JWE:tä käyttämällä voidaan toteuttaa salattuja token- ja käyttäjätietovastauksia.

Mikä on JWE? (Lyhyt yhteenveto)

JSON Web Encryption (JWE) on standardi tietojen salaamiseen ja esittämiseen JSON-muodossa.

JWE:tä voidaan soveltaa JSON Web Tokens (JWT) -tunnisteisiin tietojen luottamuksellisuuden varmistamiseksi. Toisin kuin tavalliset JWT:t, jotka takaavat eheyden ja aitouden mutta jättävät tiedot luettaviksi, JWE salaa sisällön niin, että vain tarkoitettu vastaanottaja voi käyttää sitä. Yhdistämällä JWE ja JSON Web Signature (JWS) voit luoda allekirjoitetun ja salatun tokenin (nested JWT), jota voidaan käyttää pääsytunnisteena OAuth 2.0:ssa tai tunnisteena OpenID Connectissa.

Miten se toimii tunnistautumisprosesseissa

Jos tarvitset kertausta siitä, miten tunnistautumisprosessit toimivat, olemme kirjoittaneet toisen blogikirjoituksen siitä, mitä tapahtuu, kun kirjaudut sisään eID:llä Iduran kautta.

Tarkastellaan nyt tunnistautumisprosessia yksityiskohtaisemmin nähdäksemme, miten salatut token-vastaukset muuttavat sitä ja mitä hyötyä niistä on.

Tavallinen tunnistautumisprosessi

Tältä näyttää vakiomuotoinen tunnistautumisprosessi identiteettipalveluntarjoajan (IdP), kuten Danish MitID:n tai FTN:n, kanssa:

1. Kun loppukäyttäjä on todennut henkilöllisyytensä IdP:llä, IdP antaa JWT:n, jossa on loppukäyttäjän henkilötiedot, ja lähettää sen Iduralle, joka sitten:
   1. Tallentaa käyttäjän tiedot session-varastoon.
   2. Luo koodiargumentin.
2. Idura ohjaa loppukäyttäjän asiakassovellukseen, jossa on koodiargumentti.
3. Asiakassovellus kutsuu oauth2/token-päätepistettä koodiargumentilla.
   1. Idura luo id_tokenin tallennettujen käyttäjätietojen perusteella.
   2. Idura tallentaa käyttäjätiedot istuntosäilöön (tarkoitettu access_tokenille ja userinfo-päätepisteelle ).
   3. Idura luo access_tokenin.
4. Idura vastaa asiakassovellukselle id_tokenin ja access_tokenin kanssa.
5. (Valinnainen) Asiakassovellus kutsuu oauth2/userinfo-sovellusta access_tokenin kanssa.
   1. Idura luo käyttäjätiedot tallennettujen käyttäjätietojen perusteella.
   2. Idura vastaa asiakassovellukselle käyttäjätiedoilla.

Tässä virrassa Idura voi purkaa käyttäjätiedot (tai istuntotiedot) missä tahansa vaiheessa vaiheen #1.1 jälkeen.

Tunnistusvirta salatun tunnisteen ja käyttäjätietovastausten kanssa.

Edellytyksenä on, että asiakassovellus rekisteröi julkisen avaimensa Idura ja säilyttää turvallisesti epäsymmetrisen avainparin vastaavan yksityisen avaimen.

1. Kun loppukäyttäjä on todennut itsensä IdP:llä, IdP antaa JWT:n, jossa on loppukäyttäjän henkilökohtaiset tiedot, ja lähettää sen Idura. Tämä token voi olla myös salattu (FTN:n vaatimus), jolloin IdP käyttää salaukseen Idura julkista avainta.
   1. Idura luo id_tokenin, salaa sen asiakassovelluksen julkisella avaimella ja tallentaa sen.
   2. Idura luo käyttäjätiedot, salaa ne asiakassovelluksen julkisella avaimella ja tallentaa ne.
   3. Idura luo koodiargumentin.
2. Idura ohjaa loppukäyttäjän asiakassovellukseen, jossa on koodiargumentti.
3. Asiakassovellus kutsuu oauth2/token-loppupistettä koodiargumentilla.
   1. Idura palauttaa salatun vastauksen istuntosäilöstä.
   2. Idura luo access_tokenin.
4. Idura vastaa asiakassovellukselle id_tokenin ja access_tokenin kanssa.
5. (Valinnainen) Asiakassovellus kutsuu oauth2/userinfoa access_tokeninkanssa.
   1. Idura palauttaa asiakassovellukselle salatun vastauksen istuntosäilöstä.

Tässä virrassa Idura voi käyttää tietoja paljon lyhyemmän aikaa salaamalla ne mahdollisimman aikaisessa vaiheessa.

Parannettu turvallisuus ja GDPR:n noudattaminen

Token- ja userinfo -vastausten salaaminen julkisella avaimella mahdollisimman varhaisessa vaiheessa minimoi Iduran pääsyn arkaluonteisiin käyttäjätietoihin.

Yksi keskeinen hyöty on parantunut GDPR-säädösten noudattaminen. Vakiovirtauksessa tallennamme loppukäyttäjien henkilökohtaisia tietoja noin neljän minuutin ajan ja voimme mahdollisesti purkaa salauksen ja tarkastella näitä tietoja. Salauksen avulla Idura ei kuitenkaan pääse käsiksi näihin tietoihin. Lisäksi vaikka tietokantamme vaarantuisi, tiedot pysyisivät luottamuksellisina. Tämä tarkoittaa viime kädessä parempaa tietosuojaa ja GDPR:n noudattamista.