Implicit Grant Type 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.

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:

• Da der Implicit Grant normalerweise keine Refresh Tokens bereitstellt, müssen Sie bei Ablauf eines Access Tokens möglicherweise den OAuth-Flow erneut initiieren, 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: Typischerweise stellt der Implicit Grant keine Refresh Tokens bereit. Wenn ein Access Token abläuft, muss daher möglicherweise der gesamte Flow wiederholt werden.

• Abkündigung: Aufgrund der inherenten Sicherheitsbedenken empfiehlt das Dokument "OAuth 2.0 Security Best Current Practice", den Implicit Grant zugunsten des Authorization Code mit PKCE (Proof Key for Code Exchange) für öffentliche Clients wie SPAs zu vermeiden.

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.