OAuth 2.1 specifikationen har planerats. Låt oss utforska de viktigaste skillnaderna mellan OAuth 2.0 och OAuth 2.1 och hur de antogs i Logto.
Sedan OAuth 2.0 (RFC 6749) kom ut 2012 har världen av web- och mobilappar förändrats mycket. Människor rör sig från stationära datorer till mobila enheter, och Single Page Applications (SPAs) är nu på modet. Vi har också sett massor av nya ramverk och webbteknologier dyka upp. Med alla dessa förändringar har säkerhetsutmaningarna också ökat. För att hålla jämna steg med de senaste webbteknologierna har nya RFCs som Proof Key for Code Exchange (PKCE) kontinuerligt släppts för att förbättra OAuth 2.0. Det har blivit avgörande att samla alla bästa praxis för dagens säkerhetskrav, och det är därför OAuth 2.1 kommer.
I den kommande OAuth 2.1, syftar OAuth Working Group till att konsolidera alla bästa praxis och säkerhetsrekommendationer i ett enda dokument. Hos Logto anpassar vi oss till de senaste standarderna och bästa praxis för OAuth. I den här artikeln kommer vi att utforska de viktigaste skillnaderna mellan OAuth 2.0 och OAuth 2.1 och hur de antogs i Logto.
En av de mest betydande förändringarna i OAuth 2.1 är att Proof Key for Code Exchange (PKCE) nu krävs för alla OAuth-klienter som använder Authorization Code-flödet. PKCE är en säkerhetsförlängning som förhindrar avlyssning av autorisationskoder. Det är särskilt användbart för mobila och Single Page Applications (SPAs) där klienthemlighet inte kan lagras säkert.
OAuth-klienter kan kategoriseras i två olika typer baserat på deras förmåga att lagra hemligheter säkert:
Konfidentiella klienter: Dessa klienter kan lagra hemligheter säkert, såsom servergenererade webbapplikationer och webbservrar. Alla autorisationsrelaterade förfrågningar görs från serversidan, och risken för att avslöja klienthemligheten är låg.
Offentliga klienter: Dessa klienter kan inte lagra hemligheter säkert, såsom mobilappar och SPAs. Klienthemligheten kan lätt extraheras från klientsidans kod, och det är svårt att skydda den från angripare.
För offentliga klienter är PKCE en oumbärlig säkerhetsåtgärd. Det säkerställer att autorisationskoden bara kan utbytas av klienten som initierade autorisationsförfrågan.
PKCE fungerar genom att generera en slumpmässig kodkontroll och en kodutmaning baserad på kodkontrollen. Kodkontrollen skickas till autorisationsservern, och kodutmaningen används för att verifiera kodkontrollen när autorisationskoden byts mot en åtkomsttoken.
I OAuth 2.1 blir PKCE obligatoriskt för alla OAuth-klienter som använder Authorization Code-flödet, oavsett deras konfidentialitetsstatus—vare sig de är konfidentiella eller offentliga. Denna avgörande justering säkerställer universellt skydd mot potentiella avlyssningsattacker av autorisationskoder.
I Logto aktiveras PKCE-valideringsflödet automatiskt för både offentliga och konfidentiella klienter.
För SPAs och mobila appar är PKCE en oumbärlig säkerhetsåtgärd för att skydda autorisationskodflödet i Logto. Alla autorisationsförfrågningar som saknar en kodutmaning kommer omedelbart att avvisas av Logtos autorisationsserver.
När det gäller konfidentiella klienter (traditionella webbappar), för förbättrad bakåtkompatibilitet, tillåter Logto fortfarande utelämnandet av kodutmaningen i autorisationsförfrågan. Vi rekommenderar dock starkt att konfidentiella klienter antar PKCE genom att inkludera kodutmaningen i autorisationsförfrågan, enligt vanorna hos offentliga klienter.
En Redirect URI (Uniform Resource Identifier) är en specifik slutpunkt eller URL som autorisationsservern omdirigerar användaren tillbaka till efter autentiserings- och autorisationsprocessen.
Under OAuth-flödet inkluderar klientapplikationen en Redirect URI som en del av den initiala autorisationsförfrågan. När användaren slutför autentiseringsprocessen genererar autorisationsservern ett svar som inkluderar en autorisationskod och omdirigerar användaren tillbaka till den angivna Redirect URI. Eventuell avvikelse från den ursprungliga Redirect URI kommer att leda till kod- eller tokenläckage.
Den exakta strängmatchningen av Redirect URIs introducerades först i OAuth 2.0 Security Best Current Practices avsnitt 4.1. Denna praxis säkerställer att Redirect URI måste matcha exakt med den som registrerats hos autorisationsservern. Eventuell avvikelse från den registrerade Redirect URI kommer att resultera i ett felmeddelande.
vi har fått många community-förfrågningar angående implementeringen av wildcard-matchning för Redirect URIs. Medan wildcard-matchning kan erbjuda bekvämlighet för utvecklare som hanterar flera subdomäner eller vägar, särskilt med ett stort antal slumpmässiga subdomäner, introducerar det också säkerhetsrisker som öppna omdirigeringsattacker. För en praktisk illustration av farorna som uppstår av saknad validering av Redirect URI, läs vårt A brief OAuth security recap blogginlägg.
I linje med de stränga säkerhetsstandarderna för OAuth 2.1 använder Logto den exakta strängmatchningen av Redirect URIs. Detta beslut prioriterar säkerheten för OAuth-flödet. Istället för att använda wildcard-matchning uppmuntrar vi utvecklare att registrera alla potentiella Redirect URIs hos Logtos autorisationsserver. Detta säkerställer noggrann validering av Redirect URIs och hjälper till att minska potentiella säkerhetsrisker.
Det implicit grant-flowet i OAuth 2.0 utformades för SPAs där åtkomsttokenet returneras direkt i URL-fragmentet efter att användaren har autentiserats. Denna metod var bekväm eftersom den undvek ett extra tokenutbytessteg, vilket gjorde det möjligt för klienten att ta emot tokenet direkt.
Men denna bekvämlighet har sina nackdelar. Åtkomsttokenet kan utsättas för obehöriga parter genom webbläsarhistorik, referrer-rubriker eller andra medel, vilket gör det lättare för säkerhetsbrott att uppstå—särskilt när åtkomsttoken förblir giltiga under längre perioder. Till exempel, om autorisationsförfrågan avlyssnas av en illvillig part, kan de enkelt extrahera åtkomsttokenet från URL-fragmentet och utge sig för att vara användaren.
I OAuth 2.0 Security Best Current Practices anger det tydligt att:
Klienter BÖR INTE använda implicit grant (svarstyp "token") eller andra svarstyper som utfärdar åtkomsttoken i autorisationssvaret.
Därför har Implicit Flow officiellt tagits bort från OAuth 2.1-specifikationen.
I Logto är autorisationskodflöde med PKCE det enda stödda flödet för SPAs och mobilapplikationer. Autorisationskodflödet ger ett säkrare sätt att erhålla åtkomsttoken genom att utbyta autorisationskoden.
Resource Owner Password Credentials (ROPC) grant tillåter klienten att byta användarens användarnamn och lösenord mot en åtkomsttoken. Det introducerades först i OAuth 2.0-specifikationen som ett sätt att stödja äldre applikationer som HTTP basic-authentisering eller äldre inbyggda applikationer som inte kunde använda de mer säkra OAuth-tokeniserade flödena.
ROPC grant typen har markerats som inte rekommenderad i OAuth 2.0-specifikationen på grund av dess säkerhetsrisker. Användarens uppgifter exponeras för klientapplikationen, vilket kan leda till potentiella säkerhetsbrott. Klientapplikationen kan lagra användarens uppgifter, och om klienten komprometteras kan användarens uppgifter exponeras för angripare.
Senare, i OAuth 2.0 Security Best Current Practices avsnitt 2.4, betonas förbudet av ROPC grant typen ytterligare som MÅSTE INTE användas. Som ett resultat har ROPC grant typen tagits bort från OAuth 2.1-specifikationen.
På grund av de höga säkerhetsriskerna associerade med ROPC grant typen, har Logto aldrig stött det. Om du fortfarande använder det direkta användaruppgifterna flödet i dina äldre applikationer rekommenderar vi starkt att migrera till en säkrare metod, såsom autorisationskodflödet eller klientuppgifter grant. Logto erbjuder olika SDKs och tutorials för att hjälpa dig att smidigt integrera dessa säkra OAuth-flöden i dina applikationer.
Vi förstår att utvecklare kanske vill utforma eller självhosta sina egna användarinloggningsgränssnitt för den bästa produktupplevelsen. Hos Logto erbjuder vi en rad alternativ för anpassning av inloggningsupplevelsen (SIE), inklusive varumärkesinställningar och anpassad CSS. Dessutom har vi flera pågående projekt, såsom bring-your-own UI och direktinloggning, för att ge mer flexibilitet för utvecklare att använda sina egna inloggningsgränssnitt samtidigt som säkerheten för OAuth-flödet bibehålls.
OAuth 2.1 är den senaste uppgraderingen till OAuth-protokollet, inriktad på att tackla dagens säkerhetsutmaningar samtidigt som det omfattar moderna webb- och mobilappbehov. OAuth-arbetsgruppen uppdaterar och förfinar aktivt OAuth 2.1 för att säkerställa att det uppfyller de senaste säkerhetsstandarderna och bästa praxis. Det senaste utkastet, OAuth 2.1 11, släpptes i maj 2024, vilket markerar betydande framsteg mot dess slutgiltigförande. Med den breda antagandet på horisonten rekommenderar vi starkt att alla följer de bästa praxis som beskrivs i OAuth 2.1 för att förbättra säkerheten och förbättra användarupplevelsen.