Autentikointivirtojen suojaus JSON Web Encryptionin avulla

Olemme aiemmin käsitelleet JSON Web Encryptionin (JWE) perusteita, joka on IETF:n standardi, joka on suunniteltu pitämään tiedot luottamuksellisina.

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

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 Idura 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.

JWE:n avulla 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 todennusvirroissa

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

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

Tavallinen todennusvirta

Tältä näyttää vakiomuotoinen todennusvirta 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 Idura, joka sitten:
   1. Tallentaakäyttäjän tiedot istuntosäilöön.
   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 Idura pääsyn arkaluonteisiin käyttäjätietoihin.

Yksi keskeinen hyöty on parantunut GDPR-vaatimustenmukaisuus. 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.