Deutsch

oauth
impliziter Flow
Autorisierungscode
PKCE

Impliziter Flow vs. Autorisierungscode-Flow: Warum ist der implizite Flow tot?

Warum gibt es einen "Autorisierungscode-Flow" in OAuth 2.0, wenn wir bereits den "impliziten Flow" haben? Lassen Sie uns in die Details dieser beiden Grant-Typen eintauchen und herausfinden, warum Sie den impliziten Flow vermeiden sollten.

Darcy Ye

Developer

1/3/2024

Verschwenden Sie keine Wochen mit Benutzerauthentifizierung

Bringen Sie sichere Apps schneller mit Logto auf den Markt. Integrieren Sie Benutzerauthentifizierung in Minuten und konzentrieren Sie sich auf Ihr Kernprodukt.

Jetzt starten

Der Autorisierungscode-Flow und der implizite Flow sind zwei der am häufigsten verwendeten Grant-Typen in OAuth 2.0, die eine sichere und effiziente Benutzerautorisierung für Webanwendungen ermöglichen. Beide Flows implementieren einen Autorisierungsprozess, der es Benutzern erlaubt, Anwendungen Zugriff zu gewähren, ohne ihre Anmeldeinformationen direkt preiszugeben. Der implizite Flow wurde ursprünglich entwickelt, um Browser-Einschränkungen zu adressieren, aber mit dem Aufkommen moderner Webtechnologien ist der Autorisierungscode-Flow aufgrund seiner verbesserten Sicherheitsmerkmale für viele Entwickler die bevorzugte Wahl geworden.

In diesem Artikel werden wir die Unterschiede zwischen diesen beiden Grant-Typen erkunden und erklären, warum Sie den impliziten Flow zugunsten des Autorisierungscode-Flows vermeiden sollten.

Was ist OAuth 2.0?

Bevor wir in die Details dieser beiden Grant-Typen eintauchen, lassen Sie uns zunächst verstehen, was OAuth 2.0 ist und warum es für moderne Webanwendungen unerlässlich ist.

Wenn Menschen über OAuth sprechen, beziehen wir uns normalerweise auf OAuth 2.0, bekannt als "Open Authorization", ist ein etabliertes Protokoll, das es Websites oder Anwendungen ermöglicht, im Namen eines Benutzers Ressourcen von anderen Webdiensten zu nutzen. Es folgte 2012 auf OAuth 1.0 und ist seitdem der weit verbreitete Standard für digitale Autorisierung geworden. OAuth 2.0 ist darauf ausgelegt, kontrollierten Zugriff auf Benutzer zu gewähren, indem bestimmten Client-Anwendungen bestimmte Berechtigungen eingeräumt werden, um mit Ressourcen zu interagieren, die den Benutzer repräsentieren, ohne die Anmeldedaten des Benutzers offenlegen zu müssen.

Obwohl es hauptsächlich in Web-Umgebungen eingesetzt wird, erstreckt sich das Framework von OAuth 2.0 auch auf verschiedene Client-Formen. Dies umfasst browserbasierte Apps, serverseitige Webanwendungen, native oder mobile Anwendungen und sogar miteinander verbundene Geräte, die den Ansatz für das Management von delegiertem Zugriff auf diesen Plattformen detailliert darstellen. Es führt das Konzept der "Grant-Typen" ein, um den Autorisierungsprozess zwischen der Client-Anwendung, dem Benutzer und dem Autorisierungsserver zu definieren. Diese Grant-Typen werden verwendet, um festzulegen, wie die Client-Anwendung ein Zugriffstoken erhalten kann, um auf die Ressourcen des Benutzers zuzugreifen. Die häufigsten Grant-Typen in OAuth 2.0 sind:

Autorisierungscode: Ideal für alle Arten von Anwendungen, insbesondere serverseitige Webanwendungen, bei denen die Client-Anwendung einen Autorisierungscode gegen ein Zugriffstoken austauschen und Tokens sicher verwalten kann.
Implizit: Ein vereinfachter Flow, der für browserbasierte Anwendungen entwickelt wurde, ohne eine sichere Serverkomponente. Er wurde erstellt, um Tokens schnell an die Client-Anwendungen auszuliefern. Aber er ist nun weitgehend veraltet aufgrund von Sicherheitsbedenken.
Ressourceneigentümer-Passwort-Anmeldeinformationen: Dieser Typ ermöglicht es der Client-Anwendung, direkt ein Zugriffstoken anzufordern und zu erhalten, indem die Anmeldeinformationen des Benutzers (Benutzername und Passwort) übermittelt werden. Da die Client-Anwendung direkten Zugriff auf die Anmeldeinformationen des Benutzers hat, wird dieser Grant-Typ ebenfalls als veraltet betrachtet und sollte unter allen Umständen vermieden werden.
Client-Anmeldeinformationen: Wird für Maschine-zu-Maschine-Kommunikation verwendet, bei der die Anwendung selbst der Client ist. Es beinhaltet, dass die Anwendung sich beim Autorisierungsserver authentifiziert und ein Zugriffstoken anfordert, um auf ihre eigenen Ressourcen oder die eines anderen Dienstes zuzugreifen.

Was ist der implizite Flow?

Der implizite Flow ist ein vereinfachter OAuth 2.0 Flow, bei dem das Zugriffstoken direkt im Redirect-URI an den Client zurückgegeben wird, ohne einen zusätzlichen Schritt, um einen Autorisierungscode gegen ein Token auszutauschen. Er wurde ursprünglich für Webanwendungen entwickelt, die aufgrund von Browser-Einschränkungen keine serverseitigen Anfragen an den Token-Endpunkt stellen konnten.

Wie funktioniert der implizite Flow?

Der Benutzer klickt auf einen Button oder Link in der Client-Anwendung, um den Authentifizierungsprozess zu starten.
Die Client-Anwendung leitet den Benutzer an den Autorisierungsserver weiter, um sich zu authentifizieren, einschließlich des gewünschten Zugriffsbereichs.
Der Autorisierungsserver fordert die Benutzer auf, sich anzumelden und der Client-Anwendung Zugriff zu gewähren.
Nach erfolgreicher Authentifizierung und Autorisierung leitet der Autorisierungsserver den Browser des Benutzers zurück zur angegebenen Redirect-URI des Clients, mit dem Zugriffstoken im URL-Fragment.
Die Client-Anwendung extrahiert das Zugriffstoken aus dem URL-Fragment und verwendet es, um auf die Ressourcen des Benutzers auf dem Ressourcenserver zuzugreifen.

Sicherheitsrisiken beim impliziten Flow

Der implizite Flow weist mehrere Sicherheitslücken auf:

Token-Exposition: Das Zugriffstoken wird direkt im URL-Fragment an den Client zurückgegeben, was von böswilligen Parteien leicht abgefangen werden kann. Dies setzt das Zugriffstoken potenziellem Diebstahl und Missbrauch aus.
CSRF-Angriffe: Der implizite Flow ist anfällig für Cross-Site-Request-Forgery (CSRF)-Angriffe, bei denen bösartige Websites Benutzer dazu verleiten können, unbefugten Zugriff auf ihre Konten zu gewähren.

Aufgrund dieser Sicherheitsbedenken wird der implizite Flow für moderne Webanwendungen nicht mehr empfohlen. Stattdessen ist der Autorisierungscode-Flow mit PKCE (Proof Key for Code Exchange) die bevorzugte Wahl für eine sichere Benutzerautorisierung.

Was ist der Autorisierungscode-Flow?

Der Autorisierungscode-Flow ist hingegen ein sicherer OAuth 2.0 Flow, der den Autorisierungsprozess in zwei Schritte unterteilt: Die Client-Anwendung erhält zunächst einen Autorisierungscode vom Autorisierungsserver und tauscht dann den Code gegen ein Zugriffstoken aus. Dieser Flow wurde ursprünglich für serverseitige Webanwendungen entwickelt, die Client-Anmeldeinformationen sicher speichern und Zugriffstokens verwalten können. Mit der Einführung der PKCE-Erweiterung kann der Autorisierungscode-Flow nun auch in browserbasierten Anwendungen verwendet werden.

Wie funktioniert der Autorisierungscode-Flow für private Clients mit serverseitiger Komponente?

Der Benutzer klickt auf einen Button oder Link in der Client-Anwendung, um den Authentifizierungsprozess zu starten.
Die Client-Anwendung leitet den Benutzer an den Autorisierungsserver weiter, um sich mit dem gewünschten Zugriffsbereich zu authentifizieren.
Der Autorisierungsserver fordert die Benutzer auf, sich anzumelden und der Client-Anwendung Zugriff zu gewähren.
Nach erfolgreicher Authentifizierung und Autorisierung gibt der Autorisierungsserver einen Autorisierungscode an den Client zurück.
Die Client-Anwendung tauscht den Autorisierungscode sicher gegen ein Zugriffstoken aus, indem sie eine serverseitige Anfrage an den Token-Endpunkt mit ihren Client-Anmeldeinformationen stellt.
Der Autorisierungsserver validiert den Autorisierungscode und die Client-Anmeldeinformationen und gibt ein Zugriffstoken an den Client zurück.
Die Client-Anwendung verwendet das Zugriffstoken, um auf die Ressourcen des Benutzers auf dem Ressourcenserver zuzugreifen.

Wie funktioniert der Autorisierungscode-Flow für öffentliche Clients mit PKCE?

Der Benutzer klickt auf einen Button oder Link in der Client-Anwendung, um den Authentifizierungsprozess zu starten.
Die Client-Anwendung generiert einen Code-Überprüfer und eine Code-Challenge.
Die Client-Anwendung leitet den Benutzer an den Autorisierungsserver weiter, um sich mit der Code-Challenge zu authentifizieren.
Der Autorisierungsserver speichert die Code-Challenge zur späteren Überprüfung.
Der Benutzer authentifiziert sich und genehmigt der Client-Anwendung Zugriff.
Der Autorisierungsserver gibt einen Autorisierungscode an den Client zurück.
Die Client-Anwendung tauscht den Autorisierungscode gegen ein Zugriffstoken aus, indem sie eine serverseitige Anfrage an den Token-Endpunkt mit dem Code-Überprüfer stellt.
Der Autorisierungsserver validiert den Autorisierungscode und den Code-Überprüfer gegen die gespeicherte Code-Challenge.
Der Autorisierungsserver gibt ein Zugriffstoken an den Client zurück.
Die Client-Anwendung verwendet das Zugriffstoken, um auf die Ressourcen des Benutzers auf dem Ressourcenserver zuzugreifen.

Erfahren Sie mehr über den PKCE Flow.