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 Criipto 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ä Criipton 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:
- 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 Criiptolle, joka sitten:
- Tallentaakäyttäjän tiedot istuntosäilöön.
- Luo koodiargumentin.
- Criipto ohjaa loppukäyttäjän asiakassovellukseen, jossa on koodiargumentti.
- Asiakassovellus kutsuu oauth2/token-päätepistettä koodiargumentilla.
- Criipto luo id_tokenin tallennettujen käyttäjätietojen perusteella.
- Criipto tallentaa käyttäjätiedot istuntosäilöön (tarkoitettu access_tokenille ja userinfo-päätepisteelle ).
- Criipto luo access_tokenin.
- Criipto vastaa asiakassovellukselle id_tokenin ja access_tokenin kanssa.
- (Valinnainen) Asiakassovellus kutsuu oauth2/userinfo-sovellusta access_tokenin kanssa.
- Criipto luo käyttäjätiedot tallennettujen käyttäjätietojen perusteella.
- Criipto vastaa asiakassovellukselle käyttäjätiedoilla.
Tässä virrassa Criipto 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 Criiptoon ja säilyttää turvallisesti epäsymmetrisen avainparin vastaavan yksityisen avaimen.
- 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 Criiptolle. Tämä token voi olla myös salattu (FTN:n vaatimus), jolloin IdP käyttää salaukseen Criipton julkista avainta.
- Criipto luo id_tokenin, salaa sen asiakassovelluksen julkisella avaimella ja tallentaa sen.
- Criipto luo käyttäjätiedot, salaa ne asiakassovelluksen julkisella avaimella ja tallentaa ne.
- Criipto luo koodiargumentin.
- Criipto ohjaa loppukäyttäjän asiakassovellukseen, jossa on koodiargumentti.
- Asiakassovellus kutsuu oauth2/token-loppupistettä koodiargumentilla.
- Criipto palauttaa salatun vastauksen istuntosäilöstä.
- Criipto luo access_tokenin.
- Criipto vastaa asiakassovellukselle id_tokenin ja access_tokenin kanssa.
- (Valinnainen) Asiakassovellus kutsuu oauth2/userinfoa access_tokeninkanssa.
- Criipto palauttaa asiakassovellukselle salatun vastauksen istuntosäilöstä.
Tässä virrassa Criipto 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 Criipton 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 Criipto 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.
