Der beste HTTP Authorization-Header-Typ für JWT

Frage ich mich, was ist die am besten geeignete Authorization HTTP-header-Typ für JWT Token.

Eines der wohl beliebteste Art ist Basic. Zum Beispiel:

Authorization: Basic QWxhZGRpbjpvcGVuIHNlc2FtZQ==

Er Griff sich zwei Parameter, wie ein login und ein Passwort. Es ist also nicht relevant für JWT Token.

Außerdem hörte ich über Träger geben, zum Beispiel:

Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiYWRtaW4iOnRydWV9.TJVA95OrM7E2cBab30RMHrHDcEfxjoYZgeFONFh7HgQ

Aber ich don T wissen, seine Bedeutung. Ist das mit dem Bären?

Gibt es eine bestimmte Art und Weise zu verwenden, JWT Token in den HTTP - Authorization header? Sollten wir Bearer soll, oder sollen wir vereinfachen und verwenden nur:

Authorization: eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiYWRtaW4iOnRydWV9.TJVA95OrM7E2cBab30RMHrHDcEfxjoYZgeFONFh7HgQ

Dank.

Edit:

Oder vielleicht, nur ein JWT HTTP-header:

JWT: eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiYWRtaW4iOnRydWV9.TJVA95OrM7E2cBab30RMHrHDcEfxjoYZgeFONFh7HgQ
Kommentar zu dem Problem
Es ist komisch 🙂 Kommentarautor: Gunhan
Ich glaube, dass kleine Bemerkung zum Bären beabsichtigt war, aber es machte mich trotzdem lacht Kommentarautor: Rodrigo
@Rodrigo verpasste den Teil über die Bären, aber sah den Kommentar und sah wieder. Gab mir ein gutes lachen. Kommentarautor: Steve Buzonas
Bitte, wenn möglich, ändern Sie die akzeptierte Antwort. Kommentarautor: Paulo Coghi

InformationsquelleAutor der Frage Zag zag.. | 2015-10-21

  1. -22

    Einen JWT token verwendet werden können, ohne OAuth.

    Somit ist eine einfache "Authorization: JWT <your_token>" wäre passender.

    Beispiel:

    curl -H "Authorization: JWT eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiYWRtaW4iOnRydWV9.TJVA95OrM7E2cBab30RMHrHDcEfxjoYZgeFONFh7HgQ" https://api.domain.tld/me/account

    InformationsquelleAutor der Antwort シリル

  2. 172

    Die besten HTTP-header für Ihre Kunden zu senden ein access-token (JWT oder andere token) ist die Authorization header mit der Bearer Authentifizierungsschema.

    Dieses Schema ist beschrieben durch die RFC6750.

    Beispiel:

    GET /resource HTTP/1.1
    Host: server.example.com
    Authorization: Bearer eyJhbGciOiJIUzI1NiIXVCJ9...TJVA95OrM7E20RMHrHDcEfxjoYZgeFONFh7HgQ

    Wenn Sie brauchen eine stärkere Sicherheits-Schutz, können Sie auch prüfen, die folgenden IETF-draft: https://tools.ietf.org/html/draft-ietf-oauth-pop-architecture. Dieser Entwurf scheint eine gute alternative zu den (verlassenen?) https://tools.ietf.org/html/draft-ietf-oauth-v2-http-mac.

    Beachten Sie, dass, auch wenn diese RFC und den oben genannten Spezifikationen beziehen sich auf die OAuth2-Framework-Protokoll, können Sie verwendet werden, in allen anderen Kontexten, die erfordern, dass ein token-Austausch zwischen einem client und einem server.

    Im Gegensatz zu den benutzerdefinierten JWT Schema, das Sie erwähnen in Ihrer Frage, die Träger ist eingetragen bei der IANA.

    Bezüglich der Basic und Digest Authentifizierungsschemas, diese sind für die Authentifizierung mit einem Benutzernamen und einem geheimen (siehe RFC7616 und RFC7617) so nicht zutreffend in diesem Zusammenhang.

    InformationsquelleAutor der Antwort Florent Morselli

  3. 9

    Ist das mit dem Bären?

    Ähhh... Nein!

    Hier ist die definition von Bearer-Token nach der RFC-6750:

    1.2. Terminologie

    Bearer-Token

    Einen Sicherheits-token mit der Eigenschaft, dass jede Partei, die im Besitz des token ("Träger") können das token in einer Weise, die einer anderen Partei in Besitz zu können. Mit einem bearer-token erfordert keine Träger, um zu beweisen, Besitz des kryptografischen Schlüssels-material (proof-of-possession).

    Den Bearer Schema ist ursprünglich definiert in der RFC-6750 für OAuth 2.0 authorization framework, aber nichts hält Sie von der Benutzung der Bearer System für access-Token in Anwendungen, die nicht die Verwendung von OAuth 2.0.

    Stick an die standards, so viel wie Sie können und don ' T erstellen Sie Ihre eigenen Authentifizierungs-Systeme.

    Einer access-token gesendet werden muss, in der Authorization - request-header, die Verwendung der Bearer authentication scheme:

    2.1. Authorization Request-Header-Feld

    Beim senden von Zugriffstoken in der Authorization Anfrage-header-Feld definiert HTTP/1.1, verwendet der client die Bearer Authentifizierungsschema zu übermitteln, die den Zugang token.

    Beispiel:

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

    [...]

    Kunden SOLLTEN authentifizierte Anfragen mit bearer-token mit der Authorization Anfrage-header-Feld mit der Bearer HTTP-authorization-Schema. [...]

    Im Fall von ungültigen oder fehlenden token, die Bearer Regelung einbezogen werden sollten in die WWW-Authenticate - header der Antwort:

    3. Der WWW-Authenticate Response-Header-Feld

    Wenn die geschützte Ressource-Anforderung enthält keine Authentifizierungsinformationen oder nicht enthalten ein access token, das ermöglicht den Zugriff auf die geschützte Ressource, die Ressource-server MUSS die HTTP - WWW-Authenticate Antwort-header-Feld [...].

    Alle Herausforderungen, die gemäß dieser Spezifikation MUSS der auth-Schema Wert Bearer. Dieses Schema MUSS gefolgt werden von einem oder mehreren auth-param-Werte. [...].

    Zum Beispiel, in Reaktion auf eine geschützte Ressource-request ohne Authentifizierung:

    HTTP/1.1 401 Unauthorized
WWW-Authenticate: Bearer realm="example"

    Und in Reaktion auf eine geschützte Ressource Anfrage mit ein Authentifizierungsversuch mit einem abgelaufenen token für den Zugriff:

    HTTP/1.1 401 Unauthorized
WWW-Authenticate: Bearer realm="example",
                         error="invalid_token",
                         error_description="The access token expired"

    InformationsquelleAutor der Antwort Cassio Mazzochi Molin

Schreibe einen Kommentar