Säkra autentiseringsflöden med JSON Web Encryption

Vi har tidigare gått igenom grunderna i JSON Web Encryption (JWE), en IETF-standard som är utformad för att hålla data konfidentiella.

I detta blogginlägg utforskar vi hur JWE kan hjälpa till att säkra känslig information specifikt i OpenID Connect-autentiseringsflöden.

FTN:s säkerhetskrav: Vad du behöver veta

Den finska regeringen inför nya krav för att skärpa autentiseringssäkerheten i Finnish Trust Network (FTN). Kraven beskrivs i rekommendation 213/2023 S Finnish Trust Network OpenID Connect Profile och inkluderar:

• Autentisering av JWT-klient med privat nyckel
• Signering av autentiseringsbegäran
• Krypterade token- och användarinformationssvar

Vi har precis implementerat dessa förändringar på Idura och delar med oss av detaljerna i den här artikelserien. Målet är att förklara de viktigaste koncepten och visa hur dessa krav förbättrar den övergripande säkerheten för autentiseringsflöden.

Om du integrerar med FTN måste du förstå och implementera dessa förändringar. Även om FTN inte är bland de eID:er du använder för närvarande uppmuntrar vi dig att bekanta dig med dessa koncept: liknande säkerhetsåtgärder kan antas av andra eID:er i framtiden, eller så kan du helt enkelt få en bättre förståelse för modern autentiseringssäkerhet.

Krypterade token- och userinfo-svar kan implementeras med hjälp av JWE.

Vad är JWE? (En snabb sammanfattning)

JSON Web Encryption (JWE) är en standard för att kryptera data och representera dem i JSON-format.

JWE kan tillämpas på JSON Web Tokens (JWT) för att säkerställa datakonfidentialitet. Till skillnad från standard-JWT, som garanterar integritet och äkthet men lämnar data läsbara, krypterar JWE innehållet så att endast den avsedda mottagaren kan komma åt det. Genom att kombinera JWE med JSON Web Signature (JWS) kan du skapa en signerad och krypterad token (nested JWT) som kan användas som en access-token i OAuth 2.0 eller en ID-token i OpenID Connect.

Hur det fungerar i autentiseringsflöden

Om du behöver en uppfräschning av hur autentiseringsflöden fungerar så har vi skrivit ett annat blogginlägg om vad som händer när du loggar in med en e-legitimation via Idura.

Låt oss nu titta på autentiseringsflödet mer i detalj för att se hur krypterade token-svar förändrar det och vilka fördelarna är.

Standardflödet för autentisering

Så här ser ett standardautentiseringsflöde ut med en Identity Provider (IdP) som danska MitID eller FTN:

1. När slutanvändaren har autentiserat sig hos en IdP utfärdar IdP:n en JWT med slutanvändarens personuppgifter och skickar den till Idura, som sedan
   1. Lagraranvändarens data i vårt sessionslager.
   2. Genererarett kodargument.
2. Idura omdirigerar slutanvändaren till klientapplikationen med kodargumentet.
3. Klientapplikationen anropar oauth2/token endpoint med kodargumentet.
   1. Idura genererar en id_token baserat på lagrad användardata.
   2. Idura sparar användardata i sessionslagret (avsett för access_token och userinfo endpoint).
   3. Idura genererar en access_token.
4. Idura svarar till klientapplikationen med id_token och access_token.
5. (Valfritt) Klientapplikationen anropar oauth2/userinfo med access_token.
   1. Idura genererar userinfo baserat på den lagrade användardatan.
   2. Idura svarar klientapplikationen med användardata.

I detta flöde kan Idura dekryptera användardata (eller våra sessionsdata) från vilken punkt som helst efter steg #1.1.

Autentiseringsflöde med krypterade token- och userinfo-svar

En förutsättning är att din klientapplikation registrerar sin publika nyckel hos Idura och på ett säkert sätt förvarar den motsvarande privata nyckeln i det asymmetriska nyckelparet.

1. När slutanvändaren har autentiserat sig hos en IdP utfärdar IdP:n en JWT med slutanvändarens personliga information och skickar den till Idura. Denna token kan också vara krypterad (ett krav för FTN), i vilket fall IdP:n använder Iduras publika nyckel för kryptering.
   1. Idura genererar en id_token, krypterar den med klientapplikationens publika nyckel och lagrar den.
   2. Idura genererar userinfo, krypterar den med klientapplikationens publika nyckel och lagrar den.
   3. Idura genererar ett kodargument.
2. Idura omdirigerar slutanvändaren till klientapplikationen med kodargumentet.
3. Klientapplikationen anropar oauth2/token endpoint med kodargumentet.
   1. Idura returnerar ett krypterat svar från vårt sessionslager.
   2. Idura genererar en access_token.
4. Idura svarar till klientapplikationen med id_token och access_token.
5. (Valfritt) Klientapplikationen anropar oauth2/userinfo med access_token.
   1. Idura returnerar ett krypterat svar från vårt sessionslager till klientapplikationen.

I det här flödet kan Idura komma åt data under en mycket kortare tid genom att kryptera den så tidigt som möjligt.

Förbättrad säkerhet och GDPR-efterlevnad

Genom att kryptera token- och userinfo-svaren med din publika nyckel så tidigt som möjligt minimeras Iduras tillgång till känslig användardata.

En viktig fördel är förbättrad GDPR-efterlevnad. I standardflödet lagrar vi slutanvändarnas personuppgifter i cirka fyra minuter och kan potentiellt dekryptera och visa dessa data. Med kryptering kan Idura dock inte komma åt dessa uppgifter. Dessutom förblir uppgifterna konfidentiella även om vår databas skulle äventyras. I slutändan innebär detta bättre dataskydd och starkare efterlevnad av GDPR.