Bester HTTP-Autorisierungs-Headertyp für JWT

228

Ich frage mich, welcher AuthorizationHTTP-Headertyp für JWT-Token am besten geeignet ist .

Einer der wahrscheinlich beliebtesten Typen ist Basic. Zum Beispiel:

Authorization: Basic QWxhZGRpbjpvcGVuIHNlc2FtZQ==

Es verarbeitet zwei Parameter wie ein Login und ein Passwort. Daher ist es für JWT-Token nicht relevant.

Auch ich gehörte Bearer - Typ, zum Beispiel:

Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiYWRtaW4iOnRydWV9.TJVA95OrM7E2cBab30RMHrHDcEfxjoYZgeFONFh7HgQ

Ich weiß jedoch nicht, was es bedeutet. Hat es mit Bären zu tun?

Gibt es eine bestimmte Möglichkeit, JWT-Token im HTTP- AuthorizationHeader zu verwenden? Sollten wir verwenden Beareroder sollten wir vereinfachen und nur verwenden:

Authorization: eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiYWRtaW4iOnRydWV9.TJVA95OrM7E2cBab30RMHrHDcEfxjoYZgeFONFh7HgQ

Vielen Dank.

Bearbeiten:

Oder vielleicht nur ein JWTHTTP-Header:

JWT: eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiYWRtaW4iOnRydWV9.TJVA95OrM7E2cBab30RMHrHDcEfxjoYZgeFONFh7HgQ

http-headers jwt

— Zag zag ..
quelle

Antworten:

295

Der beste HTTP-Header für Ihren Client zum Senden eines Zugriffstokens (JWT oder eines anderen Tokens) ist der AuthorizationHeader mit dem BearerAuthentifizierungsschema.

Dieses Schema wird vom RFC6750 beschrieben .

Beispiel:

GET /resource HTTP/1.1
Host: server.example.com
Authorization: Bearer eyJhbGciOiJIUzI1NiIXVCJ9TJV...r7E20RMHrHDcEfxjoYZgeFONFh7HgQ

Wenn Sie einen stärkeren Sicherheitsschutz benötigen, können Sie auch den folgenden IETF-Entwurf in Betracht ziehen: https://tools.ietf.org/html/draft-ietf-oauth-pop-architecture . Dieser Entwurf scheint eine gute Alternative zu dem (aufgegebenen?) Https://tools.ietf.org/html/draft-ietf-oauth-v2-http-mac zu sein .

Beachten Sie, dass dieser RFC und die oben genannten Spezifikationen, auch wenn sie sich auf das OAuth2 Framework-Protokoll beziehen, in allen anderen Kontexten verwendet werden können, die einen Token-Austausch zwischen einem Client und einem Server erfordern.

Im Gegensatz zu dem benutzerdefinierten JWTSchema , das Sie in Ihrer Frage erwähnen, das Bearerist ein an der IANA registriert .

In Bezug auf die Basicund DigestAuthentifizierungsschemata sind sie der Authentifizierung unter Verwendung eines Benutzernamens und eines Geheimnisses (siehe RFC7616 und RFC7617 ) gewidmet, sodass sie in diesem Kontext nicht anwendbar sind.

— Florent Morselli
quelle

Danke dir! Gut zu sehen, woher dieses BearerKeyword stammt. Aber es kommt von OAuth. JWT kann jedoch ohne OAuth verwendet werden. Es ist völlig unabhängig von den OAuth-Spezifikationen.

— Zag Zag ..

Ja, es stammt aus dem OAuth2-Framework-Protokoll, kann aber in jedem anderen Kontext verwendet werden. Es steht Ihrem Server frei, JWT mithilfe anderer Header oder Methoden zu akzeptieren (z. B. in der Textanforderung oder in Authenticateder Abfragezeichenfolge ). Der Header ist jedoch besser geeignet und entspricht dem RFC7235, der ein Authentifizierungsframework in einem HTTP 1.1-Kontext beschreibt

— Florent Morselli

Ich stimme Zag Zag zu, ein benutzerdefiniertes Schema wie "JWT" scheint weitaus angemessener zu sein, als das OAuth2 Bearer-Schema dazu zu zwingen.

— 18.

Dies sollte die akzeptierte Antwort sein. Zitieren von jwt.io/introduction : "Der Benutzeragent sollte das JWT senden, normalerweise im Authorization-Header unter Verwendung des Bearer-Schemas. Der Inhalt des Headers sollte wie folgt aussehen: Authorization: Bearer <token>"

— wrschneider

Wenn es jemandem hilft - ich bin hierher gekommen, um nach diesem Beispiel zu suchen: - Curl-Anfrage mit dem Bearer-Schema:curl -H "Authorization: Bearer <TOKEN>" <the rest of your curl cmd>

— Kevin Friedheim

Kurze Antwort

Das BearerAuthentifizierungsschema ist genau das, wonach Sie suchen.

Lange Antwort

Hat es mit Bären zu tun?

Errr ... Nein :)

Nach den Oxford Dictionaries ist hier die Definition des Inhabers :

Inhaber _{^{/ ˈbɛːrə /}}
Substantiv

Eine Person oder Sache, die etwas trägt oder hält.

Eine Person, die einen Scheck oder eine andere Zahlungsanweisung vorlegt.

Die erste Definition enthält die folgenden Synonyme: Bote , Agent , Förderer , Abgesandter , Spediteur , Anbieter .

Und hier ist die Definition des Inhaber-Tokens gemäß RFC 6750 :

1.2. Terminologie

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. Für die Verwendung eines Inhaber-Tokens muss kein Inhaber den Besitz von kryptografischem Schlüsselmaterial nachweisen (Besitznachweis).

Das BearerAuthentifizierungsschema ist in IANA registriert und ursprünglich im RFC 6750 für das OAuth 2.0-Autorisierungsframework definiert. Nichts hindert Sie jedoch daran, das BearerSchema für Zugriffstoken in Anwendungen zu verwenden, die OAuth 2.0 nicht verwenden.

Halten Sie sich so weit wie möglich an die Standards und erstellen Sie keine eigenen Authentifizierungsschemata.

Ein Zugriffstoken muss im AuthorizationAnforderungsheader mithilfe des BearerAuthentifizierungsschemas gesendet werden:

2.1. Header-Feld für Autorisierungsanforderung

Beim Senden des Zugriffstokens in dem Authorizationdurch HTTP / 1.1 definierten Anforderungsheaderfeld verwendet der Client das BearerAuthentifizierungsschema, um das Zugriffstoken zu übertragen.

Beispielsweise:
GET /resource HTTP/1.1
Host: server.example.com
Authorization: Bearer mF_9.B5f-4.1JqM
[...]

Clients sollten authentifizierte Anforderungen mit einem Inhaber-Token unter Verwendung des AuthorizationAnforderungsheaderfelds mit dem BearerHTTP-Autorisierungsschema stellen. [...]

Im Falle eines ungültigen oder fehlenden Tokens sollte das BearerSchema in den WWW-AuthenticateAntwortheader aufgenommen werden:

3. Das WWW-Authenticate Response Header-Feld

Wenn die Anforderung für geschützte Ressourcen keine Authentifizierungsdaten enthält oder kein Zugriffstoken enthält, das den Zugriff auf die geschützte Ressource ermöglicht, MUSS der Ressourcenserver das HTTP- WWW-AuthenticateAntwortheaderfeld [...] enthalten.

Alle in dieser Spezifikation definierten Herausforderungen MÜSSEN den Wert des Authentifizierungsschemas verwenden Bearer. Diesem Schema MÜSSEN ein oder mehrere auth-param-Werte folgen. [...].

Zum Beispiel als Antwort auf eine geschützte Ressourcenanforderung ohne Authentifizierung:
HTTP/1.1 401 Unauthorized
WWW-Authenticate: Bearer realm="example"
Und als Antwort auf eine Anforderung einer geschützten Ressource mit einem Authentifizierungsversuch unter Verwendung eines abgelaufenen Zugriffstokens:
HTTP/1.1 401 Unauthorized
WWW-Authenticate: Bearer realm="example",
                         error="invalid_token",
                         error_description="The access token expired"

— Cassiomolin
quelle

Ja. Es ist verwandt mit Bären. Genauso wie Python mit Schlangen verwandt ist. Duh.

— Nicholas Hamilton

Bären .. Das macht es. Danke, dass du meinen Tag gemacht hast.

— user2501323

Ist es eine Sicherheitslücke, wenn: ich dem Benutzer das Token gebe, aber wenn er mir eine Anfrage senden möchte, muss er das Token im Anfragetext zurücksenden? Ich werde es dann von dort bekommen und validieren? Ich habe nicht wirklich andere Optionen, da die Art und Weise, wie sie die Anfrage senden, nicht von mir definiert wird, aber ich würde mich interessieren, ob das schlecht ist oder ob es eine Lösung gibt, um es sicherer zu machen.

— Daniel Jeney