oauth 2.0

OAuth 2.1

OAuth 2.1 ist ein vorgeschlagenes Update des OAuth 2.0 Autorisierungs-Frameworks, das darauf abzielt, die Sicherheit und Benutzerfreundlichkeit zu verbessern, indem unsichere Flows abgeschafft und neue Best Practices eingeführt werden.

Was ist OAuth 2.1?

OAuth 2.1 ist ein vorgeschlagenes Update des OAuth 2.0 Autorisierungs-Frameworks. Es umfasst eine Reihe von Änderungen und Empfehlungen zur bestehenden OAuth 2.0 Spezifikation, die die besten Praktiken und Sicherheitsverbesserungen konsolidiert, die im Laufe der Jahre in der Branche weit verbreitet angenommen wurden.

Die Hauptupdates von OAuth 2.1 sind:

Abschaffung der implicit grant und der Ressourcenbesitzer Passwort-Anmeldeinformationen (ROPC) grant aufgrund von Sicherheitsbedenken.
Erzwingung der Verwendung von Proof Key for Code Exchange (PKCE) für alle Clients, einschließlich vertraulichen (privaten) Clients .
Exakte Übereinstimmung der Redirect URIs .
Klare Definition der Client -Typen (öffentliche und vertrauliche Clients).
Sicherheitsanforderungen für Refresh Tokens .

Abschaffung von implicit grant

Der implicit grant wurde für Single-Page-Anwendungen (SPAs) und browserbasierte Anwendungen entwickelt, die Client-Geheimnisse nicht sicher speichern können. Allerdings haben seine Sicherheitsrisiken zu seiner Abschaffung geführt: Der Grant liefert das access token im Front-Channel (URL-Fragment), was durch den Browser-Verlauf und Referrer-Headern Angreifern offenbart werden kann.

OAuth 2.1 empfiehlt die Verwendung des authorization code grant mit Proof Key for Code Exchange (PKCE) für browserbasierte Anwendungen.

Abschaffung von ROPC grant

Der ROPC grant erlaubt es dem Client, die Anmeldeinformationen des Benutzers direkt gegen ein access token auszutauschen. Es wurde für Legacy-Anwendungen entwickelt, die den authorization code flow nicht unterstützen können. Allerdings birgt der Grant Sicherheitsrisiken, indem er:

Die Anmeldeinformationen des Benutzers an den Client weitergibt.
Den Autorisierungsbildschirm des authorization server umgeht.
Die Fähigkeit des authorization server einschränkt, andere Sicherheitsmaßnahmen wie Multi-Faktor-Authentifizierung (Multi-factor authentication, MFA) zu erzwingen.

OAuth 2.1 empfiehlt die Nutzung des authorization code grant mit Proof Key for Code Exchange (PKCE) zur Benutzer-Authentifizierung und -Autorisierung.

Erzwingung von PKCE für alle Clients

Proof Key for Code Exchange (PKCE) ist eine Sicherheitsverlängerung des authorization code flow, die das Risiko von Autorisierungscode-Abfangangriffen mindert. Es beinhaltet, dass der Client einen Code-Verifizierer und eine Code-Challenge generiert und der authorization server die Challenge während des Token-Austausches überprüft.

Hier ist ein vereinfachtes Sequenzdiagramm des authorization code flow mit PKCE:

Zunächst wurde empfohlen, dass öffentliche Clients PKCE verwenden. OAuth 2.1 erweitert diese Empfehlung jedoch zu einer obligatorischen Anforderung für alle Clients, einschließlich vertrauliche (private) Clients .

Exakte Übereinstimmung der Redirect URIs

Redirect URIs werden vom Client verwendet, um Autorisierungsantworten vom authorization server zu erhalten. OAuth 2.1 führt eine neue Anforderung ein, dass die in der authorization request verwendete Redirect URI genau mit der vom Client beim authorization server registrierten übereinstimmen muss, einschließlich Schema, Host und Pfad.

In einigen OAuth 2.0 Implementierungen war die Übereinstimmung der Redirect URI nachgiebig, wobei Teilübereinstimmungen oder Platzhalterzeichen erlaubt waren. Diese Flexibilität kann jedoch Sicherheitsrisiken wie Open-Redirect-Schwachstellen einführen.

Klare Definition der Client-Typen

OAuth 2.0 definiert Client-Typen nicht explizit. In der Branche können Sie verschiedene Kategorisierungen sehen, z. B. nach Zugriffslevel (öffentlich vs. vertraulich) oder Anwendungstyp (Web-App vs. Mobile-App). Für das OAuth-Framework spielt es keine Rolle, wie der Client implementiert ist (da es mehr um die geschäftlichen Attribute des Clients geht), aber das Zugriffslevel macht einen Unterschied in den Sicherheitsanforderungen.

Daher führt OAuth 2.1 eine klare Definition der Client-Typen ein:

Öffentliche Clients : Clients, die die Vertraulichkeit ihrer Anmeldeinformationen NICHT aufrechterhalten können (z. B. SPAs, Mobile-Apps).
Vertrauliche Clients : Clients, die die Vertraulichkeit ihrer Anmeldeinformationen aufrechterhalten können (z. B. serverseitige Web-Apps, native Desktop-Apps).

Sicherheitsanforderungen für Refresh Tokens

Refresh Tokens sind langlebige Tokens, die vom Client verwendet werden, um neue access tokens ohne Benutzerinteraktion zu erhalten. Während ihrer Lebensdauer sind sie jedoch auch attraktive Ziele für Angreifer. Da öffentliche Clients Anmeldeinformationen nicht sicher speichern können, spezifiziert OAuth 2.1, dass der authorization server eine der folgenden Methoden verwenden sollte, um Refresh Tokens zu sichern:

Sender-gebundene Refresh Tokens ausstellen.
Refresh Token Rotation verwenden, um die Nutzbarkeit und Lebensdauer von Refresh Tokens zu begrenzen.

OAuth 2.1 und OpenID Connect (OIDC)

Da OpenID Connect (OIDC) auf OAuth 2.0 aufbaut, gelten die in OAuth 2.1 eingeführten Änderungen auch für OIDC. Zum Beispiel sollten alle OIDC Clients authorization code flow mit PKCE zur Benutzer-Authentifizierung und -Autorisierung verwenden.