Die OAuth 2.1 Spezifikation wurde geplant. Lass uns die wichtigsten Unterschiede zwischen OAuth 2.0 und OAuth 2.1 erkunden und sehen, wie sie in Logto übernommen wurden.
Seit OAuth 2.0 (RFC 6749) im Jahr 2012 veröffentlicht wurde, hat sich die Welt der Web- und mobilen Apps stark verändert. Die Leute wechseln von Desktops zu mobilen Geräten, und Single Page Applications (SPAs) sind jetzt der letzte Schrei. Wir haben auch viele neue Frameworks und Webtechnologien aufkommen sehen. Mit all diesen Änderungen haben sich auch die Sicherheitsherausforderungen verschärft. Um mit den neuesten Webtechnologien Schritt zu halten, wurden kontinuierlich neue RFCs wie Proof Key for Code Exchange (PKCE) veröffentlicht, um OAuth 2.0 zu verbessern. Es ist entscheidend geworden, alle Best Practices für die heutigen Sicherheitsanforderungen zu gruppieren, und genau deshalb kommt OAuth 2.1.
In dem kommenden OAuth 2.1 zielt die OAuth-Arbeitsgruppe darauf ab, alle Best Practices und Sicherheitsempfehlungen in einem einzigen Dokument zusammenzufassen. Bei Logto halten wir uns stets an die neuesten Standards und bewährten Praktiken von OAuth. In diesem Artikel werden wir die wichtigsten Unterschiede zwischen OAuth 2.0 und OAuth 2.1 untersuchen und sehen, wie sie in Logto übernommen wurden.
Eine der bedeutendsten Änderungen in OAuth 2.1 ist, dass Proof Key for Code Exchange (PKCE) jetzt für alle OAuth-Clients, die den Authorization Code Flow nutzen, erforderlich ist. PKCE ist eine Sicherheitserweiterung, die Abfangangriffe auf Autorisierungscodes verhindert. Dies ist besonders nützlich für mobile und Single Page Applications (SPAs), bei denen das Client-Geheimnis nicht sicher gespeichert werden kann.
OAuth-Clients lassen sich basierend auf ihrer Fähigkeit, Geheimnisse sicher zu speichern, in zwei verschiedene Typen unterteilen:
Vertrauliche Clients: Diese Clients können Geheimnisse sicher speichern, wie z. B. serverseitig gerenderte Webanwendungen und Webserver. Alle autorisierungsbezogenen Anfragen werden serverseitig gemacht, und das Risiko einer Freilegung des Client-Geheimnisses ist gering.
Öffentliche Clients: Diese Clients können Geheimnisse nicht sicher speichern, wie z. B. mobile Apps und SPAs. Das Client-Geheimnis kann leicht aus dem clientseitigen Code extrahiert werden, und es ist schwierig, es vor Angreifern zu schützen.
Für öffentliche Clients ist PKCE eine unverzichtbare Sicherheitsmaßnahme. Es stellt sicher, dass der Autorisierungscode nur von dem Client ausgetauscht werden kann, der die Autorisierungsanfrage initiiert hat.
PKCE funktioniert, indem ein zufälliger Code-Verifier und eine Code-Challenge basierend auf dem Code-Verifier generiert werden. Der Code-Verifier wird an den Autorisierungsserver gesendet, und die Code-Challenge wird verwendet, um den Code-Verifier zu überprüfen, wenn der Autorisierungscode gegen ein Zugriffstoken ausgetauscht wird.
In OAuth 2.1 wird PKCE für alle OAuth-Clients, die den Authorization Code Flow verwenden, obligatorisch, unabhängig von ihrem Vertraulichkeitsstatus—ob vertraulich oder öffentlich. Diese zentrale Änderung gewährleistet einen universellen Schutz vor potenziellen Abfangangriffen auf Autorisierungscodes.
In Logto wird der PKCE-Validierungs-Flow automatisch für sowohl öffentliche als auch vertrauliche Clients aktiviert.
Für SPAs und mobile Apps ist PKCE eine unverzichtbare Sicherheitsmaßnahme, um den Authorization Code Flow in Logto zu schützen. Jede Autorisierungsanforderung ohne Code-Challenge wird vom Autorisierungsserver von Logto umgehend abgelehnt.
In Bezug auf vertrauliche Clients (traditionelle Webanwendungen) erlaubt Logto aus Gründen der erweiterten Kompatibilität die Auslassung der Code-Challenge in der Autorisierungsanfrage. Wir empfehlen jedoch dringend, dass vertrauliche Clients PKCE anwenden, indem sie die Code-Challenge in die Autorisierungsanfrage einfügen, wie es öffentliche Clients tun.
Eine Redirect-URI (Uniform Resource Identifier) ist ein spezifischer Endpunkt oder eine URL, zu der der Autorisierungsserver den Benutzer nach dem Authentifizierungs- und Autorisierungsprozess zurückleitet.
Während des OAuth-Flows enthält die Client-Anwendung eine Redirect-URI als Teil der initialen Autorisierungsanfrage. Sobald der Benutzer den Authentifizierungsprozess abgeschlossen hat, generiert der Autorisierungsserver eine Antwort, die einen Autorisierungscode enthält, und leitet den Benutzer zurück zur angegebenen Redirect-URI. Jede Abweichung von der ursprünglichen Redirect-URI führt zu einem Code- oder Token-Leck.
Die exakte Zeichenfolgenübereinstimmung von Redirect-URIs wurde erstmals in den OAuth 2.0 Security Best Current Practices Abschnitt 4.1 eingeführt. Diese Praxis stellt sicher, dass die Redirect-URI genau mit der beim Autorisierungsserver registrierten übereinstimmen muss. Jede Abweichung von der registrierten Redirect-URI führt zu einer Fehlermeldung.
Wir haben zahlreiche Anfragen aus der Community zur Implementierung von Platzhalter-Matching für Redirect-URIs erhalten. Obwohl Platzhalter-Matching Entwicklern, die mehrere Subdomains oder Pfade verwalten, insbesondere bei einer großen Anzahl zufälliger Subdomains, Komfort bieten kann, führt es auch zu Sicherheitsrisiken wie Open-Redirect-Angriffen. Für eine praktische Darstellung der Gefahren, die durch die fehlende Redirect-URI-Validierung entstehen, siehe bitte unseren Blogbeitrag Ein kurzer Rückblick auf die OAuth-Sicherheit.
Im Einklang mit den strengen Sicherheitsstandards von OAuth 2.1 verwendet Logto die exakte Zeichenfolgenübereinstimmung bei Redirect-URIs. Diese Entscheidung priorisiert die Sicherheit des OAuth-Flows. Anstatt Platzhalter-Matching zu verwenden, empfehlen wir Entwicklern, alle potenziellen Redirect-URIs beim Autorisierungsserver von Logto zu registrieren. Dies gewährleistet eine gründliche Validierung der Redirect-URIs und hilft, potenzielle Sicherheitslücken zu vermeiden.
Der Implicit-Grant-Flow in OAuth 2.0 wurde für SPAs entwickelt, bei denen das Zugriffstoken direkt im URL-Fragment zurückgegeben wird, nachdem der Benutzer authentifiziert wurde. Diese Methode war praktisch, da ein zusätzlicher Token-Austauschschritt umgangen wurde und der Client das Token direkt erhalten konnte.
Allerdings hat diese Bequemlichkeit auch Nachteile. Das Zugriffstoken kann über den Browserverlauf, Referrer-Header oder andere Mittel unbefugten Parteien zugänglich gemacht werden, was es leichter macht, dass Sicherheitsverletzungen auftreten—vor allem, wenn Zugriffstokens für längere Zeiträume gültig bleiben. Zum Beispiel, wenn die Autorisierungsanfrage von einem böswilligen Dritten abgefangen wird, kann dieser leicht das Zugriffstoken aus dem URL-Fragment extrahieren und den Benutzer nachahmen.
In den OAuth 2.0 Security Best Current Practices wird es klar definiert:
Clients SOLLTEN den Implicit Grant (Responsetyp „token“) oder andere Responsetypen, die Zugriffstokens in der Autorisierungsantwort ausstellen, NICHT verwenden.
Daher wurde der Implicit Flow offiziell aus der OAuth 2.1-Spezifikation entfernt.
In Logto wird der Autorisierungscode-Flow mit PKCE für SPAs und mobile Apps als einziger unterstützter Flow angeboten. Der Autorisierungscode-Flow stellt eine sicherere Methode dar, um Zugriffstokens durch den Austausch des Autorisierungscodes zu erhalten.
Der Resource Owner Password Credentials (ROPC) Grant ermöglicht es dem Client, den Benutzernamen und das Passwort des Benutzers gegen ein Zugriffstoken auszutauschen. Es wurde erstmals in der OAuth 2.0-Spezifikation eingeführt, um ältere Anwendungen wie HTTP-Basis-Authentifizierung oder ältere native Anwendungen zu unterstützen, die die sichereren OAuth-tokenisierten Flows nicht verwenden konnten.
Der ROPC-Grant-Typ wurde in der OAuth 2.0-Spezifikation aufgrund seiner Sicherheitsrisiken als nicht empfohlen eingestuft. Die Anmeldeinformationen des Benutzers werden der Client-Anwendung offengelegt, was zu potenziellen Sicherheitsverletzungen führen kann. Die Client-Anwendung kann die Anmeldeinformationen des Benutzers speichern, und wenn der Client kompromittiert wird, können die Anmeldeinformationen des Benutzers Angreifern zugänglich gemacht werden.
Später wurde in den OAuth 2.0 Security Best Current Practices Abschnitt 2.4 das Verbot des ROPC-Grant-Typs weiter betont und erklärt, dass er NICHT verwendet werden dürfe. Infolgedessen wurde der ROPC-Grant-Typ aus der OAuth 2.1-Spezifikation entfernt.
Aufgrund der hohen Sicherheitsrisiken, die mit dem ROPC-Grant-Typ verbunden sind, wurde dieser in Logto nie unterstützt. Wenn Sie in Ihren älteren Anwendungen weiterhin den direkten Benutzeranmeldeinformationen-Flow verwenden, empfehlen wir dringend, zu einer sichereren Methode wie dem Autorisierungscode-Flow oder dem Client-Credentials-Grant zu migrieren. Logto bietet verschiedene SDKs und Tutorials, um Ihnen zu helfen, diese sicheren OAuth-Flows mühelos in Ihre Anwendungen zu integrieren.
Wir verstehen, dass Entwickler möglicherweise ihr eigenes Benutzeranmelde-Interface entwerfen oder selbst hosten möchten, um die beste Produkterfahrung zu erzielen. Bei Logto bieten wir eine Reihe von Anpassungsoptionen für das Anmeldeerlebnis (SIE), einschließlich Branding-Einstellungen und benutzerdefiniertem CSS. Darüber hinaus haben wir mehrere laufende Projekte wie „bring-your-own UI“ und „direct sign-in“, um Entwicklern mehr Flexibilität zu bieten, ihr eigenes Anmelde-Interface zu verwenden, während die Sicherheit des OAuth-Flows gewahrt bleibt.
OAuth 2.1 ist das neueste Upgrade des OAuth-Protokolls, das darauf abzielt, die heutigen Sicherheitsherausforderungen zu bewältigen und gleichzeitig den Anforderungen moderner Web- und mobiler Apps gerecht zu werden. Die OAuth-Arbeitsgruppe aktualisiert und verfeinert OAuth 2.1 aktiv, um sicherzustellen, dass es den neuesten Sicherheitsstandards und Best Practices entspricht. Der neueste Entwurf, OAuth 2.1 11, wurde im Mai 2024 veröffentlicht und markiert einen bedeutenden Fortschritt in Richtung seiner Finalisierung. Mit der breiten Akzeptanz am Horizont empfehlen wir nachdrücklich, dass jeder die in OAuth 2.1 dargelegten Best Practices befolgt, um die Sicherheit zu erhöhen und die Benutzererfahrung zu verbessern.