Autorisierungsanfrage (Authorization request)

Was ist eine Autorisierungsanfrage (Authorization request)?

Je nach Kontext kann der Begriff “Autorisierungsanfrage (Authorization request)” unterschiedliche Dinge bedeuten. In diesem Artikel konzentrieren wir uns auf die Definition in der OAuth 2.0 -Spezifikation.

In OAuth 2.0 gibt es mehrere Typen von Zugriffsgewährungen (Flows), die definieren, wie ein Client die Autorisierung eines Benutzers erhalten kann, um auf geschützte Ressourcen zuzugreifen.

![Hinweis] “Autorisierungsanfragen (Authorization requests)” werden oft mit “Authentifizierungsanfragen (Authentication Requests)” im Kontext von OpenID Connect (OIDC) verwechselt. Siehe Authentifizierungsanforderung (Authentication request) für OIDC-spezifische Details.

Wie funktioniert eine Autorisierungsanfrage (Authorization request)?

Wenn ein Client (Anwendung) im Namen eines Benutzers auf geschützte Ressourcen zugreifen möchte, initiiert er eine Autorisierungsanfrage (Authorization request) an den Autorisierungsserver (Authorization server) . Der Client sollte den angeforderten Typ der Zugriffsgewährung zusammen mit den notwendigen Parametern in der Anfrage angeben.

Hier sind einige typische Arten von Zugriffsgewährungen (Flows) für die Endbenutzerautorisierung in OAuth 2.0:

• Autorisierungscode-Ablauf (Authorization code flow) : Der am meisten empfohlene Fluss für die Autorisierung von Endbenutzern. Er wird normalerweise mit Proof Key for Code Exchange (PKCE) für eine bessere Sicherheit verwendet und ist für die meisten Anwendungen geeignet.
• Impliziter Flow (Implicit flow) : Ein vereinfachter Fluss, der in OAuth 2.1 aufgrund von Sicherheitsbedenken veraltet ist.
• Ressourceninhaber-Passwort-Zugangsdaten (ROPC) Zugriffsgewährung : Eine Zugriffsgewährung (Flow), bei der die Zugangsdaten des Benutzers direkt gegen ein Zugriffstoken ausgetauscht werden. Dieser Fluss wird aufgrund von Sicherheitsrisiken nicht empfohlen.

Es gibt auch andere Erweiterungen, wie den Gerätefluss (Device flow) für Geräte mit begrenzten Eingabemöglichkeiten. Jeder Fluss hat seine eigenen Merkmale und Anwendungsfälle. Für die meisten Webanwendungen wird der Authorization Code Flow empfohlen.

Machine-to-Machine (M2M) -Autorisierung erfolgt typischerweise mit dem Client-Credentials-Flow , der keine Benutzerinteraktion erfordert.

Zum Beispiel kann ein Client (Anwendung) die Autorisierung anfordern, um auf die Google Drive-Dateien eines Benutzers zuzugreifen. Hier ist ein vereinfachtes Sequenzdiagramm des Authorization Code Flows:

Sobald das Zugriffstoken (Access token) erhalten wurde, kann der Client es verwenden, um im Namen des Benutzers auf die Google Drive-Dateien zuzugreifen.

Hauptparameter in einer Autorisierungsanfrage (Authorization request)

Die OAuth 2.0-Autorisierungsanfrage (Authorization request) enthält in der Regel die folgenden Parameter:

• response_type: Der Typ der Antwort, den der Client erwartet. Häufige Werte sind code für den Authorization Code Flow und token für den Implicit Flow.
• client_id: Die vom Autorisierungsserver ausgegebene Client-ID.
• redirect_uri: Die URI, an die der Autorisierungsserver den Benutzer nach dem Autorisierungsprozess sendet.
• scope: Die angeforderten Scopes (Berechtigungen) für das Zugriffstoken.
• resource: Der optionale Parameter, der den Ressourcenindikator (Resource indicator) für die angeforderten Ressourcen angibt. Der Autorisierungsserver muss RFC 8707 unterstützen, um diesen Parameter verwenden zu können.

Die oben genannten Parameter sind nicht erschöpfend. Die tatsächlichen Parameter und deren Werte hängen vom Typ der Zugriffsgewährung und den spezifischen Anforderungen der Anwendung ab.

Siehe auch

• OAuth 2.0
• Authentifizierungsanforderung (Authentication request)
• Autorisierungscode-Ablauf (Authorization code flow)
• Impliziter Flow (Implicit flow)
• Gerätefluss (Device flow)