Private Key JWT: Ett starkare alternativ för klientautentisering

Om du är bekant med OAuth 2.0 och OpenID Connect vet du att klientapplikationer måste autentisera sig själva till auktoriseringsservern som en del av ett säkert kod-för-token-utbyte. Detta är nödvändigt för att verifiera klientens identitet och säkerställa att endast legitima applikationer kan ta emot tokens från auktoriseringsservern.

Klientautentisering kan göras på flera sätt, enligt definitionen i Open ID Connect Core Client Authentication. Det vanligaste tillvägagångssättet för klientautentisering i traditionella serverbaserade applikationer är att använda en client_secret: en delad lösenordsliknande sträng.

En mer robust alternativ metod är Private Key JWT. Med private_key_jwt bevisar klientapplikationer sin identitet genom att signera en JSON Web Token (JWT) med privat nyckel i ett asymmetriskt nyckelpar. Denna signerade JWT(client_assertion) skickas sedan till auktoriseringsservern för autentisering. Servern validerar signaturen med hjälp av klientens offentliga nyckel, som är tillgänglig via en tidigare etablerad registrerings- eller identifieringsmekanism.

Autentisering av JWT-klienter med privat nyckel är nu ett krav för integrering med Finnish Trust Network (FTN). Denna metod stöds dock också fullt ut och rekommenderas för andra eID-integrationer om din applikation är en konfidentiell klient.

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 en av de eID:er som 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.

Fördelarna med Private Key JWT-autentisering

Private Key JWT-autentisering erbjuder flera fördelar jämfört med traditionella klienthemligheter.

1. Förbättrad säkerhet mot imitation

Traditionell autentisering med client_secret bygger på en delad hemlighet och symmetrisk kryptografi. Om hemligheten läcker ut, fångas upp eller stjäls kan vem som helst utge sig för att vara din applikation, vilket äventyrar dess säkerhet. För att göra saken värre är klienthemligheter vanligtvis långlivade och skickas i klartext över kabeln. Om de råkar läcka ut via t.ex. delade HAR-spår är det därför mycket troligt att angriparen kan använda dem.

Private Key JWT minskar avsevärt angreppsytan för stöld av referenser. Den använder asymmetrisk kryptografi: Din applikation behåller en privat nyckel för sig själv och delar endast sin motsvarande offentliga nyckel med auktoriseringsservern.

När du autentiserar signerar ditt program en JWT med sin privata nyckel. Auktoriseringsservern verifierar signaturen med hjälp av din registrerade offentliga nyckel. Den privata nyckeln lämnar alltså aldrig din applikation och den publika nyckeln kan inte användas för att förfalska en signatur och utge sig för att vara din applikation.

Private Key JWT använder också specifika JWT-anspråk (som jti för unika ID och exp för utgång) för att förhindra återspelningsattacker, vilket säkerställer att varje autentiseringsförsök endast är giltigt en gång. En annan säkerhetsfördel är den kortare livslängden för client_assertion - vanligtvishögst en timme.

2. Starkare bevis på ursprung och oavvislighet (non-repudiation)

Att använda client_secret för autentisering gör det svårt att bevisa att en viss klientapplikation har skickat en viss begäran. I teorin kan vem som helst som har hemligheten ha skickat den.

Autentisering med private_key_jwt ger å andra sidan mycket starkare bevis för att en viss klient har initierat en begäran. I det här fallet delas aldrig klientapplikationens privata nyckel externt, så säkerheten beror bara på att nyckeln förblir konfidentiell. Detta eliminerar säkerhetsproblem med auktoriseringsserverns lagring av referenser eller någon kanal över vilken en client_secret kan skickas.

Det är därför den digitala signaturen som är inbäddad i client_assertion ger en stark oavvislighet. Auktorisationsservern kan kryptografiskt verifiera den här signaturen med hjälp av motsvarande offentliga nyckel och bekräfta att endast den klienten kan ha signerat påståendet. Denna kryptografiska försäkran innebär att när en åtgärd loggas vet du nästan säkert vilken klient som utförde den, vilket skapar en starkare och mer tillförlitlig verifieringskedja.

3. Förenklad hantering av referenser

Att hantera hela livscykeln för delade hemligheter - säker distribution, lagring och rotation - kan vara en operativ och säkerhetsmässig börda.

Med Private Key JWT finns det ingen client_secret att distribuera eller rotera. Din applikation genererar helt enkelt ett asymmetriskt nyckelpar och registrerar sin offentliga nyckel hos auktoriseringsservern en gång. Det finns inga hemligheter att överföra under registrering och vid autentisering med auktoriseringsservern. Och om du bestämmer dig för att rotera nycklarna genererar ditt program helt enkelt om sitt asymmetriska nyckelpar, ersätter sin privata nyckel och uppdaterar den offentliga nyckel som registrerats hos auktoriseringsservern. Den här processen är i sig säkrare än att ersätta en symmetrisk klienthemlighet eftersom inga hemligheter utbyts.

Sammanfattningsvis

Private Key JWT är en starkare standard för att säkra klientautentisering i känsliga miljöer. Dess växande antagande under de senaste åren drivs av utvecklande säkerhetsstandarder (som de från Financial-grade API (FAPI) Working Group), ökad medvetenhet om risker för kompromettering av referenser och olika regleringsdrivande drivkrafter, inklusive eIDAS.

Du kan börja använda Private Key JWT-klientautentisering med Idura genom att följa den här guiden. Om du har några frågor är du välkommen att skicka ett e-postmeddelande till support@idura.eu eller kontakta oss på Slack.