Vad är PKCE: från grundläggande koncept till djup förståelse

Den här artikeln förklarar hur PKCE (Proof Key for Code Exchange) skyddar OAuth 2.0-autoriseringskodflöde genom att förhindra att skadliga applikationer avlyssnar autoriseringskoder och tar dig från grundläggande koncept till en omfattande förståelse.

Yijun

Developer

7/28/2023

Sluta slösa veckor på användarautentisering

Lansera säkra appar snabbare med Logto. Integrera användarautentisering på några minuter och fokusera på din kärnprodukt.

Kom igång

Proof Key for Code Exchange (PKCE) är en förlängning av Authorization Code flow. Det designades ursprungligen för att säkra autoriseringskodflödet i mobilappar, och nu rekommenderas det att användas av enkel-sidiga appar också. Från OAuth 2.1 är PKCE obligatoriskt för alla typer av klienter, inklusive offentliga klienter och konfidentiella (privata) klienter.

I den här artikeln hjälper vi dig att förstå varför PKCE skapades och hur det skyddar dina applikationer, vilket ger dig en djup förståelse av PKCE.

Varför behövs PKCE?

I OAuth 2.0-autoriseringskodflöden begär användare att logga in via en applikation. Autentiseringsservern riktar användarna till en autentiseringssida. Efter användarautentisering returnerar servern en autoriseringskod till applikationen, som sedan använder denna kod för att begära en åtkomsttoken från autentiseringsservern.

Detta flöde har en betydande säkerhetsrisk: autoriseringskoden kan avlyssnas av skadliga program. Detta är särskilt oroande på mobila enheter där andra applikationer kan registrera samma omdirigerings-URI och avlyssna autoriseringskoden.

Avlyssningsprocessen visas i diagrammet nedan:

Steg (1): Appen utför en autoriseringsförfrågan genom ett säkert API som inte kan avlyssnas. I detta steg tillhandahåller begäraren också en omdirigerings-URI.

Steg (2): Begäran vidarebefordras sedan till OAuth 2.0-autoriseringsservern. Eftersom OAuth kräver användning av TLS är denna kommunikation skyddad av TLS och kan inte avlyssnas.

Steg (3): Autoriseringsservern returnerar autoriseringskoden.

Steg (4.a): autoriseringskoden returneras till begäraren via omdirigerings-URI som tillhandahålls i steg (1). I detta steg, om den skadliga appen har registrerat sig som en hanterare för omdirigerings-URI, kan den skadliga appen avlyssna autoriseringskoden. Med autoriseringskoden kan angriparen begära och erhålla en åtkomsttoken i stegen (5.a) och (6.a) respektive.

Som visas ovan, i OAuth 2.0-autoriseringskodflöde, om autoriseringskoden avlyssnas, kan angripare använda den för att erhålla åtkomsttokens. Därför behöver vi en mekanism för att förhindra avlyssning av autoriseringskoder, vilket ledde till skapandet av PKCE.

Hur fungerar PKCE?

Som nämnts ovan, om vi vill förhindra att bli attackerade, behöver vi säkerställa att endast appen som iniitierade begäran kan begära och erhålla åtkomsttoken. Detta är där PKCE kommer in i bilden.

PKCE löser detta problem genom att införa ett "bevisnyckel"-koncept.

När man begär en autoriseringskod, genererar applikationen först en slumpmässig kodverifierare och lagrar den lokalt. Den konverterar sedan denna kodverifierare till en kodutmaning med hjälp av specifika algoritmer. Applikationen skickar både kodutmaningen och kodutmaningsmetoden till autentiseringsservern under autoriseringskodförfrågan.

Kodverifieraren är en slumpmässigt genererad sträng, och kodutmaningen härleds från kodverifieraren genom konvertering. Två konverteringsmetoder stöds:

plain：Använder kodverifieraren direkt som kodutmaning

S256：Använder SHA-256 hashing på kodverifieraren, följt av Base64URL-kodning. Eftersom hashutdata inte kan vändas för att erhålla kodverifieraren, och eftersom "plain"-metoden kan vara sårbar för Man-in-the-Middle-attacker under överföring, rekommenderas starkt användning av "S256" för säkerhetsskäl.

Efter användarautentisering returnerar autentiseringsservern autoriseringskoden till applikationen. När man begär en åtkomsttoken skickar applikationen både autoriseringskoden och kodverifieraren till autentiseringsservern. Servern transformerar "kodverifieraren" med hjälp av den tidigare mottagna "kodutmaningsmetoden" och jämför resultatet med den tidigare mottagna "kodutmaningen" för att verifiera klientens innehav av "kodverifieraren".

Steg (1-3): Appen skapar och registrerar en hemlighet kallad "kodverifieraren" och härleder en transformerad version "kodutmaning", som skickas i OAuth 2.0-autoriseringsbegäran tillsammans med transformationsmetoden "kodutmaningsmetod".

Steg (3-6): Auth Server svarar som vanligt men registrerar "kodutmaning" och "kodutmaningsmetod".

Steg (7.a): Appen skickar sedan autoriseringskoden till tokenändpunkten som vanligt men inkluderar den "kodverifierare" hemlighet som genererats i steg (1).

Steg (8.a-9.a): Autoriseringsservern transformerar "kodverifierare" till "kodutmaning" och jämför den med "kodutmaningen" från steg (1-3). Åtkomst nekas om de inte är lika.

I detta fall, även om den skadliga appen har avlyssnat autoriseringskoden i steg (6.b), kan den inte lösa in den för en åtkomsttoken, eftersom den inte har "kodverifierare"-hemligheten, och eftersom "kodverifieraren" skickas över TLS kan den inte avlyssnas.

Sammanfattning

Den här artikeln förklarar hur PKCE fungerar och varför det är nödvändigt för att skydda autoriseringskodflödet. Genom att lägga till en bevisnyckelmekanism förhindrar PKCE att skadliga applikationer avlyssnar och missbrukar autoriseringskoder. Förhoppningsvis hjälper denna förklaring dig att förstå PKCE på djupet.

Testa Logto idag

Varför behövs PKCE?#

Hur fungerar PKCE?#

Sammanfattning#

Varför behövs PKCE?#

Hur fungerar PKCE?#

Sammanfattning#

Varför behövs PKCE?

Hur fungerar PKCE?

Sammanfattning

Varför behövs PKCE?

Hur fungerar PKCE?

Sammanfattning