De specificatie van OAuth 2.1 is gepland. Laten we de belangrijkste verschillen tussen OAuth 2.0 en OAuth 2.1 verkennen en hoe ze in Logto zijn aangenomen.
Sinds OAuth 2.0 (RFC 6749) in 2012 uitkwam, is de wereld van web- en mobiele apps enorm veranderd. Mensen gaan van desktops naar mobiele apparaten en Single Page Applications (SPAs) zijn nu helemaal in. We hebben ook talloze nieuwe frameworks en webtechnologieën zien opkomen. Met al deze veranderingen zijn ook de beveiligingsuitdagingen toegenomen. Om bij te blijven met de nieuwste webtechnologieën zijn er continu nieuwe RFC's uitgebracht, zoals Proof Key for Code Exchange (PKCE) om OAuth 2.0 te verbeteren. Het is cruciaal geworden om alle best practices voor de beveiliging van vandaag te bundelen, en daarom komt OAuth 2.1.
In de aanstaande OAuth 2.1, streeft de OAuth Working Group ernaar om alle best practices en beveiligingsaanbevelingen in één document te consolideren. Bij Logto omarmen we de nieuwste standaarden en best practices van OAuth. In dit artikel zullen we de belangrijkste verschillen tussen OAuth 2.0 en OAuth 2.1 onderzoeken en hoe ze in Logto zijn aangenomen.
Een van de meest significante veranderingen in OAuth 2.1 is dat Proof Key for Code Exchange (PKCE) nu vereist is voor alle OAuth-clients die de Authorization Code flow gebruiken. PKCE is een beveiligingsuitbreiding die interceptieaanvallen op autorisatiecodes voorkomt. Het is vooral nuttig voor mobiele en Single Page Applications (SPAs) waar het clientgeheim niet veilig kan worden opgeslagen.
OAuth-clients kunnen worden gecategoriseerd in twee verschillende typen op basis van hun vermogen om geheimen veilig op te slaan:
Vertrouwelijke clients: Deze clients kunnen geheimen veilig opslaan, zoals server-gerenderde webapplicaties en webservers. Alle autorisatie-gerelateerde verzoeken worden vanaf de serverzijde gedaan en het risico op blootstelling van het clientgeheim is laag.
Openbare clients: Deze clients kunnen geheimen niet veilig opslaan, zoals mobiele apps en SPAs. Het clientgeheim kan gemakkelijk worden geëxtraheerd uit de client-side code en het is moeilijk om het te beschermen tegen aanvallers.
Voor openbare clients is PKCE een onmisbare beveiligingsmaatregel. Het zorgt ervoor dat de autorisatiecode alleen kan worden uitgewisseld door de client die het autorisatieverzoek heeft geïnitieerd.
PKCE werkt door een willekeurige codeverifier en een code-uitdaging te genereren op basis van de codeverifier. De codeverifier wordt naar de autorisatieserver verzonden en de code-uitdaging wordt gebruikt om de codeverifier te verifiëren bij uitwisseling van de autorisatiecode voor een toegangstoken.
In OAuth 2.1 wordt PKCE verplicht voor alle OAuth-clients die de Authorization Code flow gebruiken, ongeacht hun vertrouwelijkheidsstatus — of ze nu vertrouwelijk of openbaar zijn. Deze wezenlijke aanpassing zorgt voor universele bescherming tegen potentiële interceptieaanvallen op autorisatiecodes.
In Logto wordt de PKCE-validatiestroom automatisch geactiveerd voor zowel openbare als vertrouwelijke clients.
Voor SPAs en mobiele apps is PKCE een onmisbare beveiligingsmaatregel om de autorisatiecodeflow in Logto te beschermen. Elk autorisatieverzoek zonder een code-uitdaging wordt door de autorisatieserver van Logto onmiddellijk afgewezen.
Wat vertrouwelijke clients (traditionele webapps) betreft, voor verbeterde compatibiliteit met oudere systemen, staat Logto nog steeds toe dat de code-uitdaging in het autorisatieverzoek wordt weggelaten. We raden vertrouwelijke clients echter sterk aan om PKCE toe te passen door de code-uitdaging in het autorisatieverzoek op te nemen, volgens de praktijken van openbare clients.
Een Redirect URI (Uniform Resource Identifier) is een specifieke eindpunt of URL waarnaar de autorisatieserver de gebruiker terugleidt na het authenticatie- en autorisatieproces.
Tijdens de OAuth-flow omvat de clienttoepassing een Redirect URI als onderdeel van het initiële autorisatieverzoek. Zodra de gebruiker het authenticatieproces voltooit, genereert de autorisatieserver een reactie die een autorisatiecode bevat en leidt de gebruiker terug naar de opgegeven Redirect URI. Elke afwijking van de oorspronkelijke Redirect URI leidt tot code- of tokenlekken.
De exacte tekenreeks overeenkomende Redirect URI's werd voor het eerst geïntroduceerd in OAuth 2.0 Security Best Current Practices sectie 4.1. Deze praktijk zorgt ervoor dat de Redirect URI precies moet overeenkomen met die geregistreerd bij de autorisatieserver. Elke afwijking van de geregistreerde Redirect URI resulteert in een foutmelding.
We hebben talloze verzoeken ontvangen van de community over de implementatie van wildcard-overeenkomsten voor Redirect URI's. Hoewel wildcard-overeenkomsten gemak kunnen bieden voor ontwikkelaars die meerdere subdomeinen of paden beheren, vooral met een groot aantal willekeurige subdomeinen, introduceert het ook beveiligingsrisico's zoals open redirect-aanvallen. Voor een praktische illustratie van de gevaren die worden gevormd door ontbrekende validatie van Redirect URI's, verwijzen we naar onze Een kort overzicht van OAuth-beveiliging blogpost.
In lijn met de strenge beveiligingsnormen van OAuth 2.1 gebruikt Logto de exacte tekenreeks overeenkomende Redirect URI's. Deze beslissing geeft prioriteit aan de beveiliging van de OAuth-flow. In plaats van wildcard-overeenkomsten aan te wenden, moedigen we ontwikkelaars aan om alle mogelijke Redirect URI's bij de Logto-autorisatieserver te registreren. Dit zorgt voor grondige validatie van Redirect URI's en helpt potentiële beveiligingskwetsbaarheden te beperken.
De impliciete toegestane flow in OAuth 2.0 was ontworpen voor SPAs waar het toegangstoken rechtstreeks in de URL-fragment wordt geretourneerd nadat de gebruiker zich authenticeert. Deze methode was handig omdat een extra tokenuitwisselingsstap werd vermeden, waardoor de client het token direct kon ontvangen.
Deze eenvoud heeft echter nadelen. Het toegangstoken kan worden blootgesteld aan onbevoegde partijen via browsergeschiedenis, referrer headers of andere middelen, waardoor beveiligingsinbreuken gemakkelijker kunnen optreden — vooral wanneer toegangstokens gedurende langere perioden geldig blijven. Bijvoorbeeld, als het autorisatieverzoek door een kwaadwillende partij wordt onderschept, kunnen ze gemakkelijk het toegangstoken uit de URL-fragment extraheren en de gebruiker imiteren.
In de OAuth 2.0 Security Best Current Practices staat duidelijk dat:
Clients ZOUDEN NIET mogen gebruikmaken van de impliciete autorisatiemachtiging (responstype "token") of andere responstypen die toegangstokens uitgeven in de autorisatiereactie.
Daarom is de Impliciete Flow officieel verwijderd uit de OAuth 2.1-specificatie.
In Logto wordt de autorisatiecode met PKCE ondersteund als de enige flow voor SPAs en mobiele Apps. De autorisatiecodeflow biedt een veiligere manier om toegangstokens te verkrijgen door de autorisatiecode uit te wisselen.
De resource-owner-wachtwoordreferenties (ROPC) grant stelt de client in staat om de gebruikersnaam en het wachtwoord van de gebruiker uit te wisselen voor een toegangstoken. Het werd voor het eerst geïntroduceerd in de OAuth 2.0-specificatie als een manier om legacy-toepassingen zoals HTTP-basisauthenticatie te ondersteunen of legacy native-toepassingen die de veiligere OAuth-tokenstromen niet konden gebruiken.
Het ROPC-grant-type is gemarkeerd als niet aanbevolen in de OAuth 2.0-specificatie vanwege de beveiligingsrisico's. De inloggegevens van gebruikers worden blootgesteld aan de clienttoepassing, wat kan leiden tot mogelijke beveiligingsinbreuken. De clienttoepassing kan de inloggegevens van de gebruiker opslaan en als de client wordt gecompromitteerd, kunnen de inloggegevens van de gebruiker blootgesteld worden aan aanvallers.
Later, in de OAuth 2.0 Security Best Current Practices sectie 2.4, werd het verbod op het ROPC grant-type verder benadrukt als NIET MOET gebruikt worden. Als resultaat is het ROPC-grant-type verwijderd uit de OAuth 2.1-specificatie.
Vanwege de hoge beveiligingsrisico's die gepaard gaan met het ROPC-grant-type heeft Logto het nooit ondersteund. Als je nog steeds de directe gebruikersverificatiestroom in je legacy-applicaties gebruikt, raden we sterk aan om over te stappen op een veiligere methode, zoals de autorisatiecodeflow of de clientreferenties-grant. Logto biedt verschillende SDK's en tutorials om je te helpen deze veilige OAuth-authenticatiestromen moeiteloos in je applicaties te integreren.
We begrijpen dat ontwikkelaars hun eigen gebruikerslogin-interface willen ontwerpen of zelf hosten voor de beste productervaring. Bij Logto bieden we een reeks aanmeldervaring (SIE)-aanpassingsopties, inclusief merk-instellingen en aangepaste CSS. Daarnaast hebben we verschillende lopende projecten, zoals bring-your-own UI en directe aanmelding, om ontwikkelaars meer flexibiliteit te bieden om hun eigen inloginterface te introduceren terwijl de beveiliging van de OAuth-stroom behouden blijft.
OAuth 2.1 is de nieuwste upgrade van het OAuth-protocol, gericht op het aanpakken van de beveiligingsuitdagingen van vandaag, terwijl het voldoet aan de behoeften van moderne web- en mobiele apps. De OAuth-werkgroep is actief bezig met het bijwerken en verfijnen van OAuth 2.1 om ervoor te zorgen dat het voldoet aan de nieuwste beveiligingsnormen en best practices. Het nieuwste concept, OAuth 2.1 11, werd uitgebracht in mei 2024, wat een aanzienlijke vooruitgang betekende in de richting van de finalisatie. Met de brede acceptatie in zicht, raden we sterk aan dat iedereen de best practices volgt die zijn uiteengezet in OAuth 2.1 om de beveiliging te verbeteren en de gebruikerservaring te verbeteren.