Was ist neu in OAuth 2.1?

Was ändert sich von OAuth 2.0 zu OAuth 2.1?

Der OAuth-Standard (Open Authorization) ermöglicht die sichere Kommunikation zwischen Diensten, ohne dass Passwörter offengelegt werden müssen.

Das OAuth Single Sign-On (SSO)-Protokoll ermöglicht Anwendungen den sicheren Zugriff auf und den Austausch von Informationen mit Unternehmenssystemen, und seine Funktionalität wird derzeit erweitert.

OAuth 2.0 wurde im Oktober 2012 eingeführt und markierte damit einen wichtigen Meilenstein in seiner Entwicklung. Nun wird OAuth 2.1 entwickelt, um die am häufigsten verwendeten Funktionen von OAuth 2.0 zu optimieren und zu vereinfachen und gleichzeitig Sicherheitsbedenken auszuräumen.

In OAuth 2.1 werden bestimmte Elemente von OAuth 2.0 als veraltet markiert und bewährte Sicherheitspraktiken durchgesetzt. Dieses Update fasst die in den letzten acht Jahren an OAuth 2.0 vorgenommenen Verbesserungen und Optimierungen zusammen und konzentriert sich dabei vor allem auf die Erhöhung der Sicherheit.

In OAuth 2.1 werden kleinere Anpassungen vorgenommen, um ein stärkeres Sicherheitsframework als bei OAuth 2.0 zu gewährleisten.

Schauen Sie sich gerne unser WordPress-Plugin an , das die Single Sign-On- Funktionalität nahtlos über das OAuth 2.0-Protokoll implementiert.

Wesentliche Unterschiede zwischen dem OAuth 2.0- und dem OAuth 2.1-Protokoll

1.) Die RFC 6749 OAuth-Kernspezifikation definiert vier Autorisierungsarten: Offener Autorisierungscode, Implizite Autorisierung, Passwort und Client-Anmeldeinformationen. Die wichtigsten Unterschiede zwischen OAuth 2.0 und OAuth 2.1 werden im Folgenden beschrieben.

2.) Für alle OAuth-Clients, die den Autorisierungscode-Flow verwenden, ist ein Proof Key for Code Exchange (PKCE) erforderlich.

3.)Redirect-URIs müssen mittels exakter Zeichenkettenübereinstimmung verglichen werden.

4.) Die implizite Gewährung (response_type=token) wird in dieser Spezifikation nicht behandelt.

5.) Die Berechtigung „Resource Owner Password Credentials“ wird in dieser Spezifikation nicht behandelt.

6.) Bei der Verwendung von Bearer-Tokens wird auf die Verwendung von Bearer-Tokens in der Abfragezeichenfolge von URIs verzichtet.

7.) Aktualisierungstoken für öffentliche Clients müssen entweder senderbeschränkt oder einmalig verwendbar sein.

Es ist Zeit für OAuth 2.1

Das OAuth-Protokoll wurde im letzten Jahrzehnt durch die Implementierung von Systemen, die es nutzen, umfassend angepasst und erweitert. Um dieser sich wandelnden Landschaft gerecht zu werden, hat die OAuth-Community die OAuth-Spezifikation über die Jahre hinweg aktualisiert und ergänzt. Die OAuth-Kernspezifikation (RFC 6749) definiert vier Autorisierungsarten: Autorisierungscode, implizite Autorisierung, Passwort und Client-Anmeldeinformationen.

PKCE ist die Abkürzung für Proof Key for Code Exchange (Beweisschlüssel für den Codeaustausch) . Es handelt sich um einen Mechanismus, der entwickelt wurde, um die Verwendung von OAuth 2.0-Autorisierungscodes in bestimmten Fällen sicherer zu gestalten.

Der Autorisierungscode ist ein Einmalcode, mit dem der Client ein Zugriffstoken erhält. Der Code wird vom Autorisierungsserver abgerufen. Dort kann der Benutzer einsehen, welche Informationen der Client anfordert, und diese akzeptieren oder ablehnen.

Der Autorisierungscode- Ablauf bietet gegenüber anderen Autorisierungsarten einige Vorteile. Nach der Autorisierung der Anwendung wird der Benutzer über eine URL mit einem temporären Code an die Anwendung zurückgeleitet. Dieser Code wird von der Anwendung gegen ein Zugriffstoken eingetauscht. Fordert die Anwendung das Zugriffstoken an, kann es mit dem Clientschlüssel authentifiziert werden. Dadurch wird das Risiko verringert, dass ein Angreifer den Autorisierungscode abfängt und selbst verwendet.

Die Autorisierungscode-Gewährung:

Die Funktionalität wurde um PKCE (RFC7636) erweitert , sodass die standardmäßige Verwendung des Autorisierungscodes gemäß dieser Spezifikation die Hinzufügung der PKCE-Parameter erfordert. Je nach API kann die Redirect-URI unnötig sein, wird aber dringend empfohlen. Dies ist die URL, zu der der Benutzer nach Abschluss der Autorisierung weitergeleitet werden soll. Sie muss mit der Redirect-URL übereinstimmen, die Sie bereits beim Dienst registriert haben.

Der implizite Grant (Antworttyp „Token“) und andere Antworttypen, die den Autorisierungsserver veranlassen, Zugriffstoken in der Autorisierungsantwort auszustellen, sind anfällig für Tokenlecks und Token-Replays. Der implizite Grant von OAuth 2.1 ist in Single-Page-Anwendungen (SPAs) grundsätzlich unsicher. Bei Verwendung dieses Grants ist Ihr Zugriffstoken gefährdet.

Um diese Probleme zu vermeiden, SOLLTEN Clients NICHT den impliziten Grant (Antworttyp „token“) verwenden … es sei denn, die Einschleusung des Zugriffstokens in die Autorisierungsantwort wird verhindert und die oben genannten Token-Leckage-Vektoren werden [abgeschwächt].

Die Berechtigung „Resource Owner Password Credentials“ wurde entfernt:{#password-creds-grant}

Diese Berechtigung wurde der OAuth 2.0-Spezifikation hinzugefügt, um die Migration zu OAuth-kompatiblen Servern zu vereinfachen. Dabei empfängt der Anwendungsserver Benutzername und Passwort (oder andere Anmeldeinformationen) und leitet sie an den OpenAuthorization-Server weiter. Ein Artikel, der jeden Schritt der Resource Owner Password Credentials-Berechtigung erläutert, ist hier verfügbar. Diese Berechtigung wird häufig für mobile Anwendungen verwendet. Obwohl sie die Migration von OAuth mit minimalen Anwendungsänderungen erleichtert, unterbricht sie das grundlegende Delegierungsmuster und verringert die Sicherheit des OAuth 2.1-Ablaufs.

Die Bearer-Authentifizierung (auch Token-Authentifizierung genannt) ist ein HTTP-Authentifizierungssystem, das Bearer-Token als Sicherheitstoken verwendet. „Bearer-Authentifizierung“ bedeutet wörtlich übersetzt „Zugriff nur dem Inhaber dieses Tokens erlauben“. Der Bearer-Token ist eine kryptische Zeichenkette, die der Server als Antwort auf eine Anmeldeanfrage generiert. Beim Senden von Anfragen an geschützte Ressourcen muss der Client diesen Token im Authorization-Header angeben. Heutzutage sind die meisten Token JWTs (JSON Web Tokens). Clients speichern diese sicher und verwenden sie dann für API-Aufrufe an den Anwendungsserver. JWT ist ein offener Standard zum Austausch von Sicherheitsinformationen zwischen Client und Server. Jedes JWT enthält kodierte JSON-Objekte, darunter eine Reihe von Ansprüchen (Claims).

Beschränkung von Aktualisierungstoken:

Aktualisierungstoken ermöglichen es einem Client, neue Zugriffstoken zu erhalten, ohne sich erneut beim Ressourceninhaber authentifizieren zu müssen. Aktualisierungstoken sind nützlich, wenn Sie länger als die Gültigkeitsdauer eines Zugriffstokens auf eine Ressource zugreifen müssen oder wenn Sie nur selten darauf zugreifen. Beispielsweise kann ein Aktualisierungstoken verwendet werden, wenn ein Benutzer über Wochen oder Monate in seinem E-Mail-Konto angemeldet ist. Läuft ein Zugriffstoken ab, kann der Client ein Aktualisierungstoken vorlegen, um ein neues zu erhalten. Der OAuth 2.1- Entwurf definiert zwei Arten von Aktualisierungstoken: solche zur einmaligen Verwendung und solche, die kryptografisch an den Absender gebunden sind. Bei der erstmaligen Verwendung eines Aktualisierungstokens (nennen wir es Aktualisierungstoken A) wird dieses ungültig, nachdem es zum Abrufen eines neuen Zugriffstokens verwendet wurde. Zusammen mit dem angeforderten Zugriffstoken kann der OAuth-Server ein neues Aktualisierungstoken (Aktualisierungstoken B) ausstellen.

OAuth 2.1 stellt die Weiterentwicklung des OAuth-Frameworks dar, indem es bewährte Sicherheitspraktiken (BCPs) mit der Entfernung irrelevanter und veralteter Spezifikationen kombiniert. miniOrange bietet kostengünstige Lösungen für sichere Identitätsverwaltung für alle Anwendungsfälle und stellt verschiedene Pakete bereit, die auf die individuellen Kundenbedürfnisse zugeschnitten sind. Mit unserem SSO-Plugin für WordPress können Sie Single Sign-On (SSO) auf Ihrer Website aktivieren und es mit jedem beliebigen Identitätsanbieter verbinden.

Kontaktieren Sie uns unter oauthsupport@xecurify.com und wir helfen Ihnen im Handumdrehen bei der Einrichtung von SSO mit allen erforderlichen Anbietern.

Weitere Informationen

• Kostenlose IDP-Testversion – Kostenlose Testversion für Single Sign-On (SSO) | 2FA-Testversion.
• Single Sign-On (SSO) für WordPress – OAuth & OpenID Connect
• OAuth Single Sign-On – SSO (OAuth-Client) – Plugin für WordPress
• OAuth-Einrichtungsanleitungen für WordPress
• Was ist neu in OAuth 2.1? – FusionAuth