Zum Inhalt springen

Grant-Typ Authorization Code in OAuth 2.0

Der Authorization Code Grant Type ist einer der am häufigsten verwendeten OAuth 2.0 Grant-Typen. Er ist speziell für Anwendungen konzipiert, die ihr Client-Secret vertraulich verwalten können, was ihn ideal für serverseitige Anwendungen macht.

Authorization Code Grant Type in LoadFocus

Setzen Sie in einem Lasttest Autorisierungstyp auf OAuth 2.0 und Grant Type auf Authorization Code. 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.
  • Access Token URL: der Token-Endpunkt des Anbieters.
  • Client ID, Client Secret, Scope, State, Audience: wie vom Anbieter ausgestellt oder mit ihm vereinbart.

Vor dem Start des Tests sendet LoadFocus eine POST-Anfrage über HTTPS an die Access Token URL, mit den übrigen Feldern als JSON-Body, und liest access_token aus der JSON-Antwort. LoadFocus öffnet keinen Browser und leitet keinen Benutzer zur Auth URL weiter. Prüfen Sie daher, ob der Token-Endpunkt Ihres Anbieters eine aus diesen Feldern gebaute Anfrage akzeptiert. Anbieter, die RFC 6749 streng umsetzen, erwarten einen formularcodierten Body.

  1. Umleitung:
  • Die Client-Anwendung leitet den Benutzer zum Autorisierungsendpunkt des OAuth 2.0-Autorisierungsservers weiter. Diese Umleitung enthält typischerweise Query-Parameter wie die client_id, response_type (auf "code" gesetzt), redirect_uri (wohin der Autorisierungsserver den Benutzer nach der Genehmigung/Ablehnung sendet) und scope (der die Zugriffsebene angibt, die die Anwendung anfordert).
  1. Benutzerauthentifizierung:
  • Der Benutzer meldet sich beim Autorisierungsserver an (falls noch nicht angemeldet) und prüft die Zugriffsanfrage der Client-Anwendung.
  1. Ausgabe des Authorization Codes:
  • Wenn der Benutzer die Genehmigung erteilt, wird er über die zuvor angegebene redirect_uri zur Client-Anwendung zurückgeleitet. Die Umleitung enthält auch einen Authorization Code in der URL.
  1. Token-Austausch:
  • Die Client-Anwendung tauscht den Authorization Code gegen ein Access Token aus, indem sie eine POST-Anfrage an den Token-Endpunkt des Autorisierungsservers sendet. Diese Anfrage enthält den Authorization Code, client_id, client_secret, redirect_uri und grant_type (auf "authorization_code" gesetzt).
  1. Ausgabe des Access Tokens:
  • Wenn der Autorisierungsserver den bereitgestellten Code und die Client-Anmeldedaten erfolgreich verifiziert, gibt er ein Access Token (und optional ein Refresh Token) an die Client-Anwendung zurück.
  1. Zugriff auf geschützte Ressource:
  • Die Client-Anwendung verwendet das erhaltene Access Token, um Anfragen an den Ressourcenserver (API) im Namen des Benutzers zu stellen.
  1. Anwendung registrieren:
  • Registrieren Sie vor dem Start des OAuth-Flows Ihre Anwendung beim OAuth 2.0-Anbieter. Nach erfolgreicher Registrierung erhalten Sie eine client_id und ein client_secret.
  1. Redirect URI einrichten:
  • Bei der Registrierung Ihrer Anwendung werden Sie oft aufgefordert, eine redirect_uri anzugeben. Diese URI ist der Ort, an den der Autorisierungsserver die Benutzer nach der Genehmigung/Ablehnung des Zugriffs sendet. Stellen Sie sicher, dass diese URI korrekt und sicher ist (typischerweise mit HTTPS).
  1. OAuth-Flow implementieren:
  • Verwenden Sie eine Bibliothek oder ein SDK, das mit der Sprache und dem Framework Ihrer Anwendung kompatibel ist, um diesen Prozess zu vereinfachen.
  • Beginnen Sie den Flow, indem Sie Benutzer zum Autorisierungsendpunkt des Autorisierungsservers mit den notwendigen Query-Parametern weiterleiten.
  • Implementieren Sie einen Endpunkt auf Ihrem Server, der der registrierten redirect_uri entspricht. Dieser Endpunkt verarbeitet den eingehenden Authorization Code.
  • Tauschen Sie den Authorization Code gegen ein Access Token aus, indem Sie eine POST-Anfrage an den Token-Endpunkt senden.
  1. Client Secret sichern:
  • Legen Sie Ihr client_secret niemals in clientseitigem Code offen. Verwenden Sie es nur serverseitig beim Austausch des Authorization Codes gegen ein Access Token.
  1. Token-Speicherung:
  • Sobald Sie ein Access Token haben, speichern Sie es sicher. Je nach den Anforderungen Ihrer Anwendung kann dies im Serverspeicher, einer Datenbank oder einem sicheren Cookie sein. Verwenden Sie immer HTTPS, um eine verschlüsselte Kommunikation sicherzustellen.
  1. Token-Ablauf behandeln:
  • Access Tokens sind oft kurzlebig. Wenn Sie ein Refresh Token haben, verwenden Sie es, um ein neues Access Token zu erhalten, ohne dass sich der Benutzer erneut authentifizieren muss.

Der Authorization Code Grant Type ist eine robuste und sichere Methode zur Erlangung der Benutzerautorisierung, insbesondere für serverseitige Anwendungen. Der zusätzliche Schritt des Austauschs eines Authorization Codes gegen ein Access Token stellt sicher, dass der direkte Zugriff auf Benutzer-Zugangsdaten vermieden wird. Die aktuellen Sicherheitsempfehlungen (RFC 9700) empfehlen für diesen Flow zusätzlich PKCE (Proof Key for Code Exchange). Verwenden Sie immer HTTPS und halten Sie Client Secrets und Tokens aus Logs und URLs heraus.