Så höjer signerade auktoriseringsförfrågningar säkerheten

Signerade auktoriseringsförfrågningar förbättrar säkerheten i autentiseringsflöden och kan implementeras som JWT-säkrade auktoriseringsförfrågningar (JAR). I det här blogginlägget går vi igenom vad JAR är och hur de skyddar mot vanliga attackvektorer. Detta fokus på JAR beror på den senaste tidens utveckling inom branschen och särskilt de nya kraven för FTN-inloggningar (Finnish Trust Network).

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

Den finska regeringen inför nya krav för att skärpa autentiseringssäkerheten för 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.

Det här blogginlägget handlar om signering av autentiseringsbegäran, som implementeras via JAR:er.

Observera: Vi använder termerna "authorize requests", "authorization requests" och "OIDC authentication requests" omväxlande i det här blogginlägget.Tekniskt sett är en OIDC-autentiseringsbegäran en OAuth 2.0-auktoriseringsbegäran som kräver slutanvändarautentisering och begär användaridentitetsinformation från auktoriseringsservern.

Den vanliga OAuth-auktoriseringsbegäran

Låt oss först titta på den grundläggande auktoriseringsbegäran.

Om du är bekant med OAuth 2.0 och OpenID Connect vet du att klientprogrammet måste skicka en auktoriseringsbegäran till auktoriseringsservern för att initiera användarautentiseringsflödet. Användarens webbläsare omdirigeras till auktoriseringsservern med en URL som denna:

https://acme-corp.idura.broker/oauth2/authorize?client_id=your_client_id&response_type=code&scope=openid%20profile&state=abc

Här skickas parametrar som client_id, response_type, scope och state direkt i URL-frågesträngen.

Problemet med traditionella auktoriseringsförfrågningar

Även om standardauktoriseringsförfrågningar är praktiska och enkla har de flera inneboende problem som kan undergräva deras säkerhet:

1. Risk för manipulering

När din klientapplikation omdirigerar en användares webbläsare till auktoriseringsservern överförs auktoriseringsadressen och dess parametrar öppet och kan fångas upp. En illasinnad aktör kan ändra dessa parametrar innan begäran når auktoriseringsservern.

Om begäran manipuleras kan det leda till allvarliga problem, t.ex. att användaren omdirigeras till en skadlig webbplats efter autentisering (även om omdirigering nästan alltid är skyddad) eller att de begärda behörigheterna ändras. Det är särskilt farligt om en angripare kan ändra parametrarna scope och code_challenge. Om scope-parametern ändras kan en större mängd personuppgifter äventyras, medan en ändring av code_challenge för en offentlig klient i princip tar bort allt skydd under utbytet av kod mot token.

2. Osäkert ursprung

En standardiserad auktoriseringsbegäran som initieras av din klientapplikation skickas till auktoriseringsservern av användarens webbläsare. Det finns ingen inneboende kryptografisk garanti för att begäran kommer från din applikation.

När grundläggande detaljer som klient-ID och omdirigeringsadress är kända kan vem som helst skapa en auktoriseringsbegäran. Detta gör det svårt för auktoriseringsservern att skilja mellan en legitim begäran och en obehörig part som försöker utge sig för att vara ditt program.

3. Ingen garanti för sekretess

Även om kommunikationskanalen vanligtvis är säkrad med HTTPS är parametrarna i auktoriseringsbegäran fortfarande synliga och tillgängliga för olika mellanhänder. Dessa inkluderar proxyer, lastbalanserare eller till och med webbläsartillägg.Därför kan en skadlig nätverkskomponent läsa, injicera eller ändra parametrar för begäran.

Vad är JAR:er?

En JWT-säkrad auktoriseringsbegäran (JAR) är en metod som definieras av RFC 9101, där parametrarna för auktoriseringsbegäran kapslas in i en JSON Web Token (JWT) som signeras med programmets privata nyckel och inkluderas i auktoriseringsbegäran via begäranparametern.

En standardiserad auktoriseringsbegäran är i princip uppbyggd så här:

https://acme-corp.idura.broker/oauth2/authorize?client_id=your_client_id&response_type=code&scope=openid%20profile&state=abc

omvandlas på följande sätt:

https://acme-corp.idura.broker/oauth2/authorize?client_id=your_client_id&request=eyJhbGciOiJSUzI1NiIsImtpZCI6InlhcmxzZXYifQ.eyJpc3MiOiJ5b3VyX2NsaWVudF9pZCI...

Parametern för begäran innehåller Request Object: JWT:n vars anspråk innehåller de JSON-kodade parametrarna för auktoriseringsbegäran.

Fördelarna med signerade auktoriseringsbegäranden

Signerade auktoriseringsbegäranden stärker säkerheten i auktoriseringsflödet och den resulterande användarautentiseringen. Fördelarna inkluderar:

1. Integritetsskydd

Genom att inkludera hela uppsättningen auktoriseringsparametrar i en signerad JWT kan auktoriseringsservern kryptografiskt verifiera att begäran inte har ändrats efter att den signerades av din klientapplikation. Om någon manipulerar signaturen blir den ogiltig och begäran avvisas.

2. Autentisering av källa och oavvislighet

Den digitala signaturen på Request Object fungerar som ett ursprungsbevis. Endast ditt klientprogram, som kontrollerar den privata nyckeln i det offentliga/privata nyckelparet, kan generera en giltig signatur. Detta säkerställer att auktoriseringsservern kan lita på källan till autentiseringsbegäran. Din klient kan inte senare neka till att ha skickat den, eftersom signaturen fungerar som kryptografiskt bevis på dess ursprung och ger starkare oavvislighet.

3. Minimering av datainsamling

Onlinetjänster kan begära mer personuppgifter än vad som är absolut nödvändigt, och användare kan ofta inte verifiera legitimiteten i dataförfrågningar. För att åtgärda detta kan JAR:er signeras av en betrodd tredje part som intygar att auktoriseringsbegäran överensstämmer med en specifik policy (t.ex. bekräftar att alla begärda personuppgifter är absolut nödvändiga för användarens avsedda process). Auktorisationsservern kan sedan undersöka signaturen och vid behov visa användaren om den överensstämmer med policyn. Detta säkerställer att begäran är legitim, bidrar till att begränsa datainsamlingen och bidrar i slutändan till att bygga upp slutanvändarnas förtroende.

Sammanfattningsvis

Finnish Trust Networks nya krav på signerade autentiseringsförfrågningar är ett steg mot att bygga ett säkrare ekosystem för digitala identiteter.

Genom att anamma denna standard kan tjänsteleverantörer och klientapplikationer säkerställa integriteten och äktheten i sina autentiseringsförfrågningar, vilket skyddar både deras användare och deras tjänster från vanliga attackvektorer.
Även om det introducerar ytterligare ett lager av kryptografisk komplexitet, överväger säkerhetsfördelarna vida implementeringsinsatsen.