Grant-Typ Implicit in OAuth 2.0

Der Implicit Grant Type, auch als "Token"-Methode bekannt, wurde hauptsächlich für clientseitige Anwendungen entwickelt, bei denen der Client ein Client-Secret nicht sicher speichern kann. Solche Anwendungen umfassen Single-Page-Apps (SPAs) oder andere browserbasierte Anwendungen. Anstatt einen Authorization Code zu erhalten, der gegen ein Access Token eingetauscht werden muss, erhält die Anwendung das Access Token direkt.

Die aktuellen Sicherheitsempfehlungen (RFC 9700) sagen, dass der Implicit Grant NICHT verwendet werden SOLLTE. Bevorzugen Sie den Grant Authorization Code mit PKCE.

Was Sie in LoadFocus eingeben

Setzen Sie in einem Lasttest Autorisierungstyp auf OAuth 2.0 und Grant Type auf Implicit. Das Formular hat diese Felder:

• Token Name: eine Bezeichnung für Sie. Sie wird nicht an den Server gesendet.
• Callback URL, Auth URL: die für Ihren Client registrierte Redirect-URI und der Autorisierungsendpunkt des Anbieters.
• Client ID, Client Secret, Scope, State, Audience: wie vom Anbieter ausgestellt oder mit ihm vereinbart.

LoadFocus öffnet keinen Browser und leitet keinen Benutzer zur Auth URL weiter, kann also den Redirect-Schritt, von dem dieser Grant abhängt, nicht abschließen.

Wie funktioniert der Implicit Grant Type?

1. Umleitung:

• Die Client-Anwendung leitet den Benutzer zum Autorisierungsendpunkt des OAuth 2.0-Autorisierungsservers weiter. Diese Umleitung enthält typischerweise Query-Parameter wie client_id, response_type (beim Implicit Grant auf "token" gesetzt), redirect_uri (wohin der Autorisierungsserver nach Gewährung/Verweigerung des Zugriffs weiterleitet) und scope (der die angeforderte Zugriffsebene angibt).

2. Benutzerauthentifizierung:

• Der Benutzer meldet sich beim Autorisierungsserver an (falls noch nicht angemeldet) und prüft die Zugriffsanfrage der Client-Anwendung.

3. Access-Token-Ausgabe:

• Wenn der Benutzer den Zugriff gewährt, leitet der Autorisierungsserver ihn über die angegebene redirect_uri zur Client-Anwendung zurück. Die Weiterleitungs-URI enthält das Access Token (und dessen Ablaufzeit) direkt im Fragment-Teil der URL.

4. Zugriff auf geschützte Ressource:

• Die Client-Anwendung extrahiert das Access Token aus dem URL-Fragment und speichert es (z. B. im Local Storage oder einer Sitzung). Anschließend verwendet sie dieses Token, um im Namen des Benutzers Anfragen an den Ressourcenserver (API) zu stellen.

Wie konfiguriert man den Implicit Grant Type?

1. Anwendung registrieren:

• Beginnen Sie, indem Sie Ihre Anwendung beim OAuth 2.0-Anbieter registrieren. Nach erfolgreicher Registrierung erhalten Sie typischerweise eine client_id.

2. Redirect-URI einrichten:

• Geben Sie bei der Registrierung eine redirect_uri an. Der Autorisierungsserver leitet die Benutzer nach der Entscheidung über Gewährung oder Verweigerung des Zugriffs an diese URI weiter. Stellen Sie sicher, dass diese URI sicher ist (typischerweise mit HTTPS) und die Token-Extraktion aus dem URL-Fragment verarbeiten kann.

3. OAuth-Flow initiieren:

• Leiten Sie Benutzer mit den notwendigen Parametern zum Autorisierungsendpunkt des Autorisierungsservers weiter. Verwenden Sie Bibliotheken oder SDKs, die für die Sprache oder das Framework Ihrer Anwendung geeignet sind, um dies zu erleichtern.

4. Token extrahieren und speichern:

• Nach der Weiterleitung extrahieren Sie das Access Token aus dem URL-Fragment. Speichern Sie das Token sicher unter Berücksichtigung clientseitiger Speicheroptionen wie Web Storage (localStorage oder sessionStorage) oder Cookies. Stellen Sie sicher, dass es vor Cross-Site-Scripting (XSS)-Angriffen geschützt ist.

5. Token verwenden:

• Fügen Sie das Access Token an API-Anfragen an, die an den Ressourcenserver gestellt werden.

6. Token-Ablauf behandeln:

• Der Implicit Grant gibt nie ein Refresh Token zurück (RFC 6749 Abschnitt 4.2.2). Läuft ein Access Token ab, müssen Sie den OAuth-Flow daher erneut durchlaufen, um ein neues zu erhalten.

Überlegungen:

• Sicherheit: Der Implicit Grant Type gilt als weniger sicher als der Authorization Code Grant Type, insbesondere weil das Access Token in der URL offengelegt wird. Dies könnte in Umgebungen, in denen URLs protokolliert oder von Dritten eingesehen werden können, ein Risiko darstellen.

• Kein Refresh Token: Der Autorisierungsserver darf für diesen Grant keines ausstellen, daher wird der gesamte Flow wiederholt, wenn das Access Token abläuft.

• Besser vermeiden: Wegen dieser Sicherheitsbedenken sagt die OAuth 2.0 Security Best Current Practice (RFC 9700), dass der Implicit Grant NICHT verwendet werden SOLLTE, und empfiehlt den Authorization Code Grant mit PKCE (Proof Key for Code Exchange) für öffentliche Clients wie SPAs.

Fazit:

Während der Implicit Grant Type einen einfacheren Flow für clientseitige Anwendungen bietet, haben seine Sicherheitsbedenken zu Empfehlungen gegen seine Verwendung in modernen Anwendungen geführt. Wenn Sie neue Anwendungen erstellen, insbesondere SPAs, erwägen Sie die Verwendung des Authorization Code Grant mit PKCE für einen sichereren Ansatz.