Implicit tillstånd vs. Auktoriseringskodflöde: Varför är implicit flöde dött?

Auktoriseringskodflödet och Implicita flödet är två av de mest använda beviljningsformerna i OAuth 2.0, vilket möjliggör säker och effektiv användarautentisering för webbapplikationer. Båda flödena implementerar en auktoriseringsprocess som låter användare bevilja tillgång till applikationer utan att direkt exponera sina referenser. Det implicit flödet utvecklades initialt för att hantera begränsningar i webbläsare, men med de moderna webbteknologiernas utveckling har auktoriseringskodflödet blivit det föredragna valet för många utvecklare på grund av dess förbättrade säkerhetsfunktioner.

I denna artikel kommer vi att utforska skillnaderna mellan dessa två beviljningsformer och förklara varför du bör undvika att använda det implicita flödet till förmån för auktoriseringskodflödet.

Vad är OAuth 2.0?#

Innan vi dyker in i detaljerna om dessa två beviljningsformer, låt oss först förstå vad OAuth 2.0 är och varför det är viktigt för moderna webbapplikationer.

När människor pratar om OAuth syftar vi oftast på OAuth 2.0, känt som "Open Authorization", vilket är ett etablerat protokoll som möjliggör att webbplatser eller applikationer kan använda resurser från andra webbtjänster på en användares vägnar. Det efterträdde OAuth 1.0 år 2012 och har sedan dess blivit den allmänt accepterade standarden för digital auktorisering. OAuth 2.0 är utformat för att ge kontrollerad åtkomst till användare genom att låta klientapplikationer specifika behörigheter för att interagera med resurser som representerar användaren, allt utan att avslöja användarens inloggningsuppgifter.

Även om det främst används i webbmiljöer, utsträcker OAuth 2.0:s ramverk också till olika klientformer. Detta inkluderar webbläsarbaserade appar, serversidiga webbapplikationer, inbyggda eller mobila applikationer och till och med sammanlänkade enheter. Det detaljerar metoden för att hantera delegerad åtkomst över dessa plattformar. Det introducerar konceptet "beviljningsformer" för att definiera auktoriseringsprocessen mellan klientapplikationen, användaren och auktoriseringsservern. Dessa beviljningsformer används för att avgöra hur klientapplikationen kan erhålla en åtkomsttoken för att få åtkomst till användarens resurser. De vanligaste beviljningsformerna i OAuth 2.0 är:

• Auktoriseringskod: Idealisk för alla typer av applikationer, särskilt serversidiga webbapplikationer, där klientapplikationen kan byta en auktoriseringskod mot en åtkomsttoken och hantera token säkert.
• Implicit: Ett förenklat flöde, utformat för webbläsarbaserade applikationer utan en säker serverkomponent. Det skapades för att snabbt leverera token till klientapplikationerna. Men det är nu i stort sett föråldrat på grund av säkerhetsproblem.
• Resursägarens lösenordsuppgifter: Denna typ tillåter klientapplikationen att direkt begära och ta emot en åtkomsttoken genom att skicka användarens referenser (användarnamn och lösenord). Eftersom klientapplikationen har direkt åtkomst till användarens referenser anses denna beviljningsform också föråldrad och bör undvikas under alla omständigheter.
• Klientuppgifter: Används för maskin-till-maskin kommunikation där applikationen själv är klienten. Det innebär att applikationen autentiserar med auktoriseringsservern och begär en åtkomsttoken för att få åtkomst till sina egna resurser eller de hos en annan tjänst.

Vad är det implicita flödet?#

Det implicita flödet är ett förenklat OAuth 2.0 flöde där åtkomsttoken returneras direkt till klienten i omdirigerings URI:n, utan ett extra steg för att byta ut en auktoriseringskod mot en token. Det utformades ursprungligen för webbapplikationer som inte kunde göra serversidiga förfrågningar till token-endpointen på grund av webbläsarrestriktioner.

Hur fungerar implicit flöde?#

1. Användaren klickar på en knapp eller länk i klientapplikationen för att initiera autentiseringsprocessen.
2. Klientapplikationen omdirigerar användaren till auktoriseringsservern för att autentisera, inklusive det önskade åtkomstomfånget.
3. Auktoriseringsservern uppmanar användarna att logga in och bevilja behörighet till klientapplikationen.
4. Vid lyckad autentisering och auktorisering omdirigerar auktoriseringsservern användarens webbläsare tillbaka till klientens angivna omdirigerings-URI, med åtkomsttoken inkluderad i URL-fragmentet.
5. Klientapplikationen extraherar åtkomsttoken från URL-fragmentet och använder den för att få åtkomst till användarens resurser på resursservern.

Säkerhetsrisker med implicit flöde#

Det implicita flödet har flera säkerhetsrisker:

• Tokenexponering: Åtkomsttoken returneras direkt till klienten i URL-fragmentet, vilket enkelt kan avlyssnas av skadliga parter. Detta exponerar åtkomsttoken för potentiell stöld och missbruk.
• CSRF-attacker: Det implicita flödet är mottagligt för Cross-Site Request Forgery (CSRF) attacker, där skadliga webbplatser kan lura användare att ge obevörad åtkomst till sina konton.

På grund av dessa säkerhetsproblem rekommenderas det inte längre att använda det implicita flödet för moderna webbapplikationer. Istället är auktoriseringskodflödet med PKCE (Proof Key for Code Exchange) det föredragna valet för säker användarautentisering.

Vad är auktoriseringskodflödet?#

Auktoriseringskodflödet, å andra sidan, är ett mer säkert OAuth 2.0-flöde som separerar auktoriseringsprocessen i två steg: klientapplikationen erhåller först en auktoriseringskod från auktoriseringsservern, och sedan byter koden mot en åtkomsttoken. Detta flöde utformades initialt för serversidiga webbapplikationer som kan lagra klientuppgifter säkert och hantera åtkomsttoken. Med introduktionen av PKCE-förlängningen kan auktoriseringskodflödet nu även användas i webbläsarbaserade applikationer.

Hur fungerar auktoriseringskodflödet för privata klienter med serversidiga komponenter?#

1. Användaren klickar på en knapp eller länk i klientapplikationen för att initiera autentiseringsprocessen.
2. Klientapplikationen omdirigerar användaren till auktoriseringsservern för att autentisera med det önskade åtkomstomfånget.
3. Auktoriseringsservern uppmanar användarna att logga in och bevilja behörighet till klientapplikationen.
4. Vid lyckad autentisering och auktorisering returnerar auktoriseringsservern en auktoriseringskod till klienten.
5. Klientapplikationen byter säkert ut auktoriseringskoden för en åtkomsttoken genom att göra en server-till-server-förfrågan till token-endpointen med sina klientuppgifter.
6. Auktoriseringsservern validerar auktoriseringskod och klientuppgifter och returnerar en åtkomsttoken till klienten.
7. Klientapplikationen använder åtkomsttoken för att komma åt användarens resurser på resursservern.

Hur fungerar auktoriseringskodflödet för offentliga klienter med PKCE?#

1. Användaren klickar på en knapp eller länk i klientapplikationen för att initiera autentiseringsprocessen.
2. Klientapplikationen genererar en kodverifierare och en kodutmaning.
3. Klientapplikationen omdirigerar användaren till auktoriseringsservern för att autentisera med kodutmaningen.
4. Auktoriseringsservern lagrar kodutmaningen för senare verifiering.
5. Användaren autentiserar och godkänner åtkomst till klientapplikationen.
6. Auktoriseringsservern returnerar en auktoriseringskod till klienten.
7. Klientapplikationen byter ut auktoriseringskoden för en åtkomsttoken genom att göra en server-till-server-förfrågan till token-endpointen med kodverifieraren.
8. Auktoriseringsservern validerar auktoriseringskoden och kodverifieraren mot den lagrade kodutmaningen.
9. Auktoriseringsservern returnerar en åtkomsttoken till klienten.
10. Klientapplikationen använder åtkomsttoken för att komma åt användarens resurser på resursservern.

Lär dig mer om PKCE flödet.

Implicita flödet vs. Auktoriseringskodflödet#

Kan auktoriseringskodflödet eliminera säkerhetsproblemen med implicita flödet?#

Svaret är JA:

Auktoriseringskodflödet introducerar ett extra steg för att byta ut auktoriseringskoden mot en åtkomsttoken, vilket avsevärt minskar risken för tokenexponering.

• För privata klienter med en säker serversidig komponent kan klientapplikationen säkert byta ut auktoriseringskoden mot en åtkomsttoken med sina klientuppgifter.
• För offentliga klienter utan en säker serversidig komponent kan PKCE-förlängningen användas för att skydda processen för konvertering av auktoriseringskoden.

Om du för närvarande använder det implicita flödet i ditt företag kan du genom att byta till auktoriseringskodflödet med PKCE uppnå bättre säkerhet för både dig och dina användare. Vi förstår att migrering och hantering av ett identitetssystem kan vara besvärligt och kostsamt, men fördelarna med förbättrad säkerhet och efterlevnad är väl värda ansträngningen.