Was genau ist das OAuth 2.0 Bearer Token?

169

Gemäß RFC6750 - Das OAuth 2.0-Autorisierungsframework: Verwendung von Bearer-Token lautet das Bearer-Token:

Ein Sicherheitstoken mit dem Eigentum, dass jede Partei, die den Token besitzt (ein "Inhaber"), den Token auf jede Weise verwenden kann, die jede andere Partei, die ihn besitzt, kann.

Für mich ist diese Definition vage und ich kann keine Spezifikation finden.

Angenommen, ich implementiere einen Autorisierungsanbieter. Kann ich eine beliebige Zeichenfolge für das Inhaber-Token angeben?
Kann es eine zufällige Zeichenfolge sein?
Muss es sich um eine Base64-Codierung einiger Attribute handeln?
Sollte es gehasht werden?
Und muss der Dienstanbieter den Autorisierungsanbieter abfragen, um dieses Token zu validieren?

Vielen Dank für jeden Hinweis.

oauth bearer-token

— Alex Beaupré
quelle

Angenommen, ich implementiere einen Autorisierungsanbieter. Kann ich eine beliebige Zeichenfolge für das Inhaber-Token angeben? Kann es eine zufällige Zeichenfolge sein? Zugriffstoken werden über die OAuth 2.0-Endpunkte von Auth0 ausgegeben: / authorize und / oauth / token. Sie können jede OAuth 2.0-kompatible Bibliothek verwenden, um Zugriffstoken zu erhalten. Wenn Sie noch keine bevorzugte OAuth 2.0-Bibliothek haben, bietet Auth0 Bibliotheken für viele Sprachen und Frameworks.

— Bharathkumar V

Antworten:

145

Inhaber-Token
Ein Sicherheitstoken mit dem Eigentum, dass jede Partei, die den Token besitzt (ein "Inhaber"), den Token auf jede Weise verwenden kann, die jede andere Partei, die ihn besitzt, kann. Die Verwendung eines Inhaber-Tokens erfordert nicht, dass ein Inhaber den Besitz von kryptografischem Schlüsselmaterial nachweist (Besitznachweis).

Das Inhaber-Token wird vom Authentifizierungsserver für Sie erstellt. Wenn ein Benutzer Ihre Anwendung (Ihren Client) authentifiziert, geht der Authentifizierungsserver und generiert für Sie ein Token. Inhabertoken sind die vorherrschende Art von Zugriffstoken, die mit OAuth 2.0 verwendet werden. Ein Inhaber-Token sagt im Grunde "Gib dem Träger dieses Token Zugriff".

Das Bearer Token ist normalerweise eine Art undurchsichtiger Wert, der vom Authentifizierungsserver erstellt wird. Es ist nicht zufällig; Es wird basierend auf dem Benutzer erstellt, der Ihnen Zugriff gewährt, und dem Client, auf den Ihre Anwendung Zugriff erhält.

Um beispielsweise auf eine API zugreifen zu können, müssen Sie ein Zugriffstoken verwenden. Zugangstoken sind von kurzer Dauer (ca. eine Stunde). Sie verwenden das Inhaber-Token, um ein neues Zugriffstoken zu erhalten. Um ein Zugriffstoken zu erhalten, senden Sie dem Authentifizierungsserver dieses Inhaber-Token zusammen mit Ihrer Client-ID. Auf diese Weise weiß der Server, dass die Anwendung, die das Inhaber-Token verwendet, dieselbe Anwendung ist, für die das Träger-Token erstellt wurde. Beispiel: Ich kann nicht einfach ein für Ihre Anwendung erstelltes Inhaber-Token verwenden und es mit meiner Anwendung verwenden. Es funktioniert nicht, da es nicht für mich generiert wurde.

Das Google Refresh-Token sieht ungefähr so aus: 1 / mZ1edKKACtPAb7zGlwSzvs72PvhAbGmB8K1ZrGxpcNM

kopiert aus dem Kommentar: Ich glaube, es gibt keine Einschränkungen für die von Ihnen gelieferten Inhaber-Token. Ich kann mir nur vorstellen, dass es schön ist, mehr als eine zuzulassen. Beispielsweise kann ein Benutzer die Anwendung bis zu 30 Mal authentifizieren, und die alten Inhaber-Token funktionieren weiterhin. Oh, und wenn man 6 Monate lang nicht benutzt wurde, würde ich es von Ihrem System entfernen. Es ist Ihr Authentifizierungsserver, der sie generieren und validieren muss, sodass es an Ihnen liegt, wie sie formatiert werden.

Aktualisieren:

Im Authorization-Header jeder Inline-Action-HTTP-Anforderung wird ein Bearer-Token festgelegt. Beispielsweise:

POST /rsvp?eventId=123 HTTP/1.1
Host: events-organizer.com
Authorization: Bearer AbCdEf123456
Content-Type: application/x-www-form-urlencoded
User-Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/1.0 (KHTML, like Gecko; Gmail Actions)

rsvpStatus=YES

Die Zeichenfolge "AbCdEf123456"im obigen Beispiel ist das Inhaberautorisierungstoken. Dies ist ein kryptografisches Token, das vom Authentifizierungsserver erstellt wird. Alle mit Aktionen gesendeten Inhaber-Token haben das Problemfeld, wobei das Zielgruppenfeld die Absenderdomäne als URL des Formulars https: // angibt. Wenn die E-Mail beispielsweise von noreply@example.com stammt, lautet die Zielgruppe https://example.com .

Wenn Sie Inhaber-Token verwenden, stellen Sie sicher, dass die Anforderung vom Authentifizierungsserver stammt und für die Absenderdomäne bestimmt ist. Wenn das Token nicht überprüft wird, sollte der Dienst auf die Anforderung mit einem HTTP-Antwortcode 401 (nicht autorisiert) antworten.

Bearer Tokens sind Teil des OAuth V2-Standards und werden von vielen APIs weitgehend übernommen.

— DaImTo
quelle

@ Xavier Egea Bearer-Token ist im Grunde Ihr Aktualisierungstoken und nicht das Zugriffstoken.

— Akhil Nambiar

Inhaber-Token bedeutet nicht, dass es sich um ein Aktualisierungstoken handelt @AqeelSmith tools.ietf.org/html/rfc6750#section-6.1.1

— Suman Kundu

Der erste Absatz impliziert, dass ein Inhaber-Token ein Aktualisierungstoken und kein Zugriffstoken ist. Das ist nicht der Fall. Aus der Bearer-Token-Spezifikation "Diese Spezifikation beschreibt, wie geschützte Ressourcenanforderungen gestellt werden, wenn das OAuth-Zugriffstoken ein Bearer-Token ist." RFC6750

— Daniel

Nachdem ich die Antwort gelesen hatte, dachte ich auch, dass Bearer-Token und Refresh-Token gleich sind. Die Antwort sollte aktualisiert werden, um dies zu verdeutlichen.

— KurioZ7

Diese Antwort ist sehr irreführend. Träger-Token sind KEINE Aktualisierungs-Token, wie in der ersten Aussage dieser Antwort angegeben. Bitte korrigieren.

— think01

Während ich Ihre Frage las, habe ich erfolglos versucht, im Internet zu suchen, wie Bearer-Token verschlüsselt oder signiert sind. Ich denke, Inhaber-Token werden nicht gehasht (möglicherweise teilweise, aber nicht vollständig), da es in diesem Fall nicht möglich ist, sie zu entschlüsseln und Benutzereigenschaften daraus abzurufen.

Ihre Frage scheint jedoch zu versuchen, Antworten auf die Bearer-Token-Funktionalität zu finden:

Angenommen, ich implementiere einen Autorisierungsanbieter. Kann ich eine beliebige Zeichenfolge für das Inhaber-Token angeben? Kann es eine zufällige Zeichenfolge sein? Muss es sich um eine Base64-Codierung einiger Attribute handeln? Sollte es gehasht werden?

Also werde ich versuchen zu erklären, wie Bearer-Token und Refresh-Token funktionieren:

Wenn der Benutzer beim Server ein Token anfordert, das Benutzer und Kennwort über SSL sendet, gibt der Server zwei Dinge zurück: ein Zugriffstoken und ein Aktualisierungstoken .

Ein Zugriffstoken ist ein Inhaber-Token, das Sie allen Anforderungsheadern hinzufügen müssen, um als konkreter Benutzer authentifiziert zu werden.

Authorization: Bearer <access_token>

Ein Zugriffstoken ist eine verschlüsselte Zeichenfolge mit allen gewünschten Benutzereigenschaften, Ansprüchen und Rollen. (Sie können überprüfen, ob die Größe eines Tokens zunimmt, wenn Sie weitere Rollen oder Ansprüche hinzufügen.) Sobald der Ressourcenserver ein Zugriffstoken erhält, kann er es entschlüsseln und diese Benutzereigenschaften lesen. Auf diese Weise wird der Benutzer zusammen mit der gesamten Anwendung validiert und gewährt.

Zugriffstoken haben einen kurzen Ablauf (dh 30 Minuten). Wenn Zugriffstoken einen langen Ablauf haben würden, wäre dies ein Problem, da theoretisch keine Möglichkeit besteht, sie zu widerrufen. Stellen Sie sich also einen Benutzer mit einer Rolle = "Admin" vor, die sich in "Benutzer" ändert. Wenn ein Benutzer das alte Token mit der Rolle "Admin" behält, kann er bis zum Ablauf des Tokens mit Administratorrechten darauf zugreifen. Aus diesem Grund haben Zugriffstoken einen kurzen Ablauf.

Es kommt jedoch ein Problem in den Sinn. Wenn ein Zugriffstoken kurz abläuft, müssen wir den Benutzer und das Passwort in jedem kurzen Zeitraum senden. Ist das sicher? Nein, ist es nicht. Wir sollten es vermeiden. In diesem Moment scheinen Token zu aktualisieren, um dieses Problem zu lösen.

Aktualisierungstoken werden in der Datenbank gespeichert und haben einen langen Ablauf (Beispiel: 1 Monat).

Ein Benutzer kann mithilfe eines Aktualisierungstokens, das der Benutzer bei der ersten Anforderung eines Tokens erhalten hat, ein neues Zugriffstoken erhalten (wenn es beispielsweise alle 30 Minuten abläuft). Wenn ein Zugriffstoken abläuft, muss der Client ein Aktualisierungstoken senden. Wenn dieses Aktualisierungstoken in der Datenbank vorhanden ist, gibt der Server ein neues Zugriffstoken und ein weiteres Aktualisierungstoken an den Client zurück (und ersetzt das alte Aktualisierungstoken durch das neue).

Falls ein Benutzerzugriffstoken kompromittiert wurde, muss das Aktualisierungstoken dieses Benutzers aus der Datenbank gelöscht werden. Auf diese Weise ist das Token nur so lange gültig, bis das Zugriffstoken abläuft. Wenn der Hacker versucht, ein neues Zugriffstoken zu erhalten, das das Aktualisierungstoken sendet, wird diese Aktion abgelehnt.

— Xavier Egea
quelle

Ich verstehe diesen Teil nicht: "Sobald der Autorisierungsserver ein Zugriffstoken erhalten hat, kann er es entschlüsseln und diese Benutzereigenschaften lesen. Auf diese Weise wird der Benutzer in der gesamten Anwendung validiert und gewährt." Ist der Autorisierungsserver nicht derjenige, der Zugriffstoken gewährt und nicht empfängt? Ich versuche, mich mit diesem Thema auseinanderzusetzen, und viele Beispiele unterscheiden deutlich zwischen Autorisierungsserver und Ressourcenserver. Was ich verstanden habe ist, dass Sie das Zugriffstoken vom Autorisierungsserver erhalten und es dann zusammen mit jeder Anforderung, die Sie an den Ressourcenserver richten, weiterleiten?

— Kivikall

@kivikall Du hast recht. Ich habe es in der Antwort geändert. Der Ressourcenserver empfängt das Token (das Token, das der Autorisierungsserver bei der Tokenerstellung verschlüsselt hat) in jeder Anforderung und entschlüsselt es.

— Xavier Egea

@kivikall Eigentlich sollte das Entschlüsseln eines Tokens etwas mit der Autorisierung zu tun haben, also sollte es zum Autorisierungsserver gehören. Deshalb hat a es in die Antwort geschrieben. In der Praxis würde dies jedoch bedeuten, dass Sie bei jeder Anforderung das empfangene Token mit dem Autorisierungsserver überprüfen müssen (möglicherweise eine andere Anforderung ausführen). Um Leistungseinbußen zu vermeiden, ist es daher besser, einige Funktionen zum Entschlüsseln des Tokens an den Ressourcenserver bereitzustellen. Überprüfen Sie den nächsten Link: stackoverflow.com/questions/12296017/…

— Xavier Egea

Bei jeder Anforderung sollte der Ressourcenserver jedoch prüfen, ob das bereitgestellte AccessToken für den Autorisierungsserver gültig ist. Wenn sich also eine Rolle ändert, kann die Änderung sofort vom Auth-Server übernommen werden, oder? Warum sollten wir auch das RefreshToken löschen, wenn das AccessToken kompromittiert wurde? Das RefreshToken kann nicht basierend auf dem AccessToken berechnet werden. Wenn es abläuft, wird der Hacker erneut blockiert.

— Mandarin

Wie gesagt, das Zugriffstoken enthält Benutzerinformationen wie die Rolle. Wenn sich eine Benutzerrolle ändert, wird diese Änderung im nächsten Token angezeigt, wenn das aktuelle Token abläuft. Dies bedeutet, dass der Benutzer in kurzer Zeit (bis zum Ablauf des Zugriffstokens) dieselbe Rolle behält und der Auth-Server dies zulässt, da das Token noch gültig ist. In Bezug auf die zweite Frage führt das Löschen eines Aktualisierungstokens dazu, dass der Benutzer seine Anmeldeinformationen erneut einfügt. Dies ist, was wir wollen, wenn ein Zugriffstoken kompomiert wird. In einem anderen Fall kann ein Hacker bis zum Ablauf der Aktualisierung (z. B. 1 Monat) autorisiert werden

— Xavier Egea

Inhaber-Token ist eine oder mehrere Wiederholungen von Alphabet, Ziffer, "-", "." , "_", "~", "+", "/" gefolgt von 0 oder mehr "=".

RFC 6750 2.1. Header-Feld für Autorisierungsanforderung (Format ist ABNF (Augmented BNF))

The syntax for Bearer credentials is as follows:

     b64token    = 1*( ALPHA / DIGIT /
                       "-" / "." / "_" / "~" / "+" / "/" ) *"="
     credentials = "Bearer" 1*SP b64token

Es sieht aus wie Base64, aber laut Sollte das Token im Header base64-codiert sein? , es ist nicht.

Wenn ich mich etwas eingehender mit "HTTP / 1.1, Teil 7: Authentifizierung" ** befasse, sehe ich jedoch, dass b64token nur eine ABNF-Syntaxdefinition ist, die Zeichen zulässt, die normalerweise in base64, base64url usw. verwendet werden. Das b64token also nicht Definieren Sie eine beliebige Codierung oder Decodierung, sondern definieren Sie nur, welche Zeichen in dem Teil des Autorisierungsheaders verwendet werden können, der das Zugriffstoken enthält.

Verweise

— mon
quelle

Sie erklären überhaupt nicht den Zweck von Inhaber-Token.

— Jaime Hablutzel