OAuth 2.0-Berechtigungsgewährung (OAuth 2.0 grant)

Was ist eine OAuth 2.0-Berechtigungsgewährung (OAuth 2.0 grant)?

Eine OAuth 2.0-Berechtigungsgewährung (OAuth 2.0 grant) ist ein Autorisierungsprozess, der es einem Client ermöglicht, ein Zugriffstoken (Access token) von einem Autorisierungsserver (Authorization server) anzufordern. Es gibt auch andere Begriffe rund um dieses Konzept, daher klären wir sie, bevor wir tiefer eintauchen:

• OAuth 2.0-Berechtigungsgewährung (OAuth 2.0 grant): Auch bekannt als “OAuth 2.0 grant type”, “OAuth 2.0 flow” oder “OAuth 2.0 authorization grant”. In den meisten Kontexten beziehen sich diese Begriffe auf dasselbe Konzept.
• Autorisierungsserver (Authorization server) : Der Server, der Zugriffstoken (access tokens) an den Client ausgibt. In OpenID Connect (OIDC) ist der Autorisierungsserver derselbe wie der OpenID Provider (OP) .
• Autorisierungsanfrage (Authorization request) : Die Anfrage, die der Client an den Autorisierungsserver stellt, um ein Zugriffstoken zu erhalten. In OpenID Connect (OIDC) wird sie auch als Authentifizierungsanforderung (Authentication request) bezeichnet.

Aus Gründen der Klarheit werden wir in diesem Artikel durchgehend die oben aufgeführten Begriffe verwenden.

Der Prozess einer OAuth 2.0-Berechtigungsgewährung (OAuth 2.0 grant) auf hoher Ebene ist recht einfach:

Nachdem der Client das Zugriffstoken erhalten hat, kann er es verwenden, um geschützte Ressourcen (z. B. APIs) im Namen eines Benutzers oder im eigenen Namen zu nutzen.

Es ist zu beachten, dass der Client und der Autorisierungsserver je nach spezifischer Berechtigungsgewährung zusätzliche Informationen austauschen und weitere Schritte in den Prozess einbinden können. Zum Beispiel umfasst die Genehmigungsgewährung mit Autorisierungscode (authorization code grant) die Benutzer-Authentifizierung und -Autorisierung, die Generierung eines Codes und den Token-Austausch.

Verschiedene OAuth 2.0-Berechtigungsgewährungen (grants)

Die grundlegende OAuth 2.0-Spezifikation definiert vier Berechtigungen, die Clients verwenden können, um Zugriffstoken zu erhalten:

1. Genehmigungsgewährung mit Autorisierungscode (authorization code grant) : Die sicherste und empfohlene Berechtigung für die meisten Anwendungen. Der Einsatz von Proof Key for Code Exchange (PKCE) ist für alle Clients in OAuth 2.1 verpflichtend.
2. Implizite Berechtigung (implicit grant) : Eine vereinfachte Berechtigung, die in OAuth 2.1 aufgrund von Sicherheitsbedenken veraltet ist.
3. Berechtigung für Ressourceninhaber-Passwortanmeldeinformationen (ROPC) : Eine Berechtigung, bei der die Anmeldeinformationen des Benutzers direkt gegen ein Zugriffstoken ausgetauscht werden. Aus Sicherheitsgründen wird sie für die meisten Anwendungen nicht empfohlen.
4. Client-Anmeldeinformationen-Berechtigung (client credentials grant) : Eine Berechtigung, die von Vertrauliche Clients verwendet wird, um ein Zugriffstoken ohne Benutzereinbeziehung zu erhalten.

Mit der Weiterentwicklung der Branche werden implizite und ROPC-Berechtigungen zugunsten von sichereren und standardisierten Abläufen veraltet . Für neue Anwendungen sind die Entscheidungen einfach:

• Für die Benutzer-Authentifizierung und -Autorisierung die Genehmigungsgewährung mit Autorisierungscode (authorization code grant) mit PKCE verwenden.
• Für Machine-to-Machine (M2M) -Kommunikation die Client-Anmeldeinformationen-Berechtigung (client credentials grant) verwenden.

Andere OAuth 2.0-Berechtigungsgewährungen (grants)

Zusätzlich zu den vier grundlegenden Berechtigungen gibt es andere Erweiterungen, die neue Berechtigungen für spezifische Anwendungsfälle definieren. Zum Beispiel:

• Geräteautorisierungsberechtigung (device authorization grant) ist eine Berechtigung, die für Geräte mit eingeschränkten Eingabemöglichkeiten, wie Smart-TVs und IoT-Geräte, entwickelt wurde.
• Hybrid-Flow ist eine OpenID Connect-Berechtigung, die die Genehmigungsgewährung mit Autorisierungscode (authorization code grant) mit der impliziten Berechtigung (implicit grant) kombiniert.

Berechtigungsgewährungen (grants) in OpenID Connect (OIDC)

In OpenID Connect (OIDC) wird das Konzept der Berechtigungsgewährungen erweitert, um ID-Tokens einzubeziehen, die neben Zugriffstokens Identitätsinformationen des Benutzers darstellen. OIDC erweitert zwei OAuth 2.0-Berechtigungen (Autorisierungscode und implizit), um ID-Tokens zu beinhalten, und führt eine neue Berechtigung namens Hybrid-Flow ein, die beides kombiniert.

Wie bei OAuth 2.0 wird nur empfohlen, die Genehmigungsgewährung mit Autorisierungscode (authorization code grant) mit PKCE in OIDC für die Benutzer-Authentifizierung und -Autorisierung zu verwenden.

Da OIDC auf OAuth 2.0 aufbaut, können derweil auch andere Berechtigungen, wie die Client-Anmeldeinformationen-Berechtigung, auf demselben Autorisierungsserver verwendet werden, sofern der Server diese unterstützt.

Siehe auch

• Proof Key for Code Exchange (PKCE)
• OAuth 2.1
• Autorisierungscode-Ablauf (Authorization code flow)
• Impliziter Flow (Implicit flow)
• Client-Credentials-Flow
• Gerätefluss (Device flow)