Meilleur type d'en-tête d'autorisation HTTP pour JWT


228

Je me demande quel est le meilleur Authorizationtype d'en-tête HTTP approprié pour les jetons JWT .

L'un des types probablement les plus populaires est Basic. Par exemple:

Authorization: Basic QWxhZGRpbjpvcGVuIHNlc2FtZQ==

Il gère deux paramètres tels qu'une connexion et un mot de passe. Il n'est donc pas pertinent pour les jetons JWT.

J'ai également entendu parler du type Bearer , par exemple:

Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiYWRtaW4iOnRydWV9.TJVA95OrM7E2cBab30RMHrHDcEfxjoYZgeFONFh7HgQ

Cependant, je ne connais pas sa signification. Est-ce lié aux ours?

Existe-t-il un moyen particulier d'utiliser des jetons JWT dans l'en- Authorizationtête HTTP ? Devrions-nous utiliser Bearer, ou devrions-nous simplifier et simplement utiliser:

Authorization: eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiYWRtaW4iOnRydWV9.TJVA95OrM7E2cBab30RMHrHDcEfxjoYZgeFONFh7HgQ

Merci.

Éditer:

Ou peut-être juste un JWTen-tête HTTP:

JWT: eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiYWRtaW4iOnRydWV9.TJVA95OrM7E2cBab30RMHrHDcEfxjoYZgeFONFh7HgQ

Réponses:


295

Le meilleur en-tête HTTP pour que votre client envoie un jeton d'accès (JWT ou tout autre jeton) est l'en- Authorizationtête avec le Bearerschéma d'authentification.

Ce schéma est décrit par le RFC6750 .

Exemple:

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

Si vous avez besoin d'une protection de sécurité renforcée, vous pouvez également envisager le brouillon IETF suivant: https://tools.ietf.org/html/draft-ietf-oauth-pop-architecture . Ce projet semble être une bonne alternative au https://tools.ietf.org/html/draft-ietf-oauth-v2-http-mac (abandonné?) .

Notez que même si cette RFC et les spécifications ci-dessus sont liées au protocole OAuth2 Framework, elles peuvent être utilisées dans tous les autres contextes qui nécessitent un échange de jetons entre un client et un serveur.

Contrairement au JWTschéma personnalisé que vous mentionnez dans votre question, celui- Bearerci est enregistré auprès de l'IANA .

Concernant les schémas Basicet d' Digestauthentification, ils sont dédiés à l'authentification à l'aide d'un nom d'utilisateur et d'un secret (voir RFC7616 et RFC7617 ), donc non applicables dans ce contexte.


3
Je vous remercie! Bon de voir l'origine de ce Bearermot - clé. Mais cela vient d'OAuth. Cependant, JWT peut être utilisé sans OAuth. Il est totalement indépendant avec les spécifications OAuth.
Zag zag ..

2
Oui, il provient du protocole de framework OAuth2, mais peut être utilisé dans n'importe quel autre contexte. Votre serveur est libre d'accepter JWT en utilisant d'autres en-têtes ou façons (par exemple dans la demande de corps ou dans la chaîne de requête), mais l'en- Authenticatetête est plus approprié et conforme au RFC7235 qui décrit un cadre d'authentification dans un contexte HTTP 1.1
Florent Morselli

1
Je suis d'accord avec Zag zag, un schéma personnalisé comme "JWT" ​​semble bien plus approprié que de contraindre le schéma OAuth2 Bearer à cela.
l8nite

50
Ce devrait être la réponse acceptée. Citant jwt.io/introduction : "l'agent utilisateur doit envoyer le JWT, généralement dans l'en-tête d'autorisation à l'aide du schéma Bearer. Le contenu de l'en-tête doit ressembler à ce qui suit: Autorisation: porteur <token>"
wrschneider

3
Si cela aide quelqu'un - je suis venu ici à la recherche de cet exemple: - requête curl en utilisant le schéma Bearer:curl -H "Authorization: Bearer <TOKEN>" <the rest of your curl cmd>
Kevin Friedheim

76

Réponse courte

Le Bearerschéma d'authentification est ce que vous recherchez.

Longue réponse

Est-ce lié aux ours?

Euh ... Non :)

Selon les dictionnaires Oxford , voici la définition du porteur :

porteur / ˈbɛːrə /
nom

  1. Une personne ou une chose qui porte ou détient quelque chose.

  2. Une personne qui présente un chèque ou un autre ordre de paiement.

La première définition comprend les synonymes suivants: messager , agent , convoyeur , émissaire , transporteur , fournisseur .

Et voici la définition du jeton de porteur selon la RFC 6750 :

1.2. Terminologie

Jeton de porteur

Un jeton de sécurité avec la propriété que toute partie en possession du jeton (un "porteur") peut utiliser le jeton de la même manière que toute autre partie en possession de celui-ci. L'utilisation d'un jeton de porteur n'exige pas d'un porteur qu'il prouve la possession de matériel de clé cryptographique (preuve de possession).

Le Bearerschéma d'authentification est enregistré dans IANA et défini à l'origine dans la RFC 6750 pour le cadre d'autorisation OAuth 2.0, mais rien ne vous empêche d'utiliser leBearer schéma pour les jetons d'accès dans les applications qui n'utilisent pas OAuth 2.0.

Respectez les normes autant que possible et ne créez pas vos propres schémas d'authentification.


Un jeton d'accès doit être envoyé dans l'en- Authorizationtête de la demande à l'aide du Bearerschéma d'authentification:

2.1. Champ d'en-tête de demande d'autorisation

Lors de l'envoi du jeton d'accès dans le Authorizationchamp d'en-tête de demande défini par HTTP / 1.1, le client utilise le Bearerschéma d'authentification pour transmettre le jeton d'accès.

Par exemple:

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

[...]

Les clients DEVRAIENT faire des demandes authentifiées avec un jeton de support en utilisant le Authorizationchamp d'en-tête de demande avec le Bearerschéma d'autorisation HTTP. [...]

En cas de jeton invalide ou manquant, le Bearerschéma doit être inclus dans l'en- WWW-Authenticatetête de réponse:

3. Le champ d'en-tête de réponse d'authentification WWW

Si la demande de ressource protégée n'inclut pas les informations d'authentification ou ne contient pas de jeton d'accès permettant l'accès à la ressource protégée, le serveur de ressources DOIT inclure le HTTP WWW-Authenticate champ d'en-tête de réponse [...].

Tous les défis définis par cette spécification DOIVENT utiliser la valeur du schéma d'authentification Bearer. Ce schéma DOIT être suivi d'une ou plusieurs valeurs d'auth-param. [...].

Par exemple, en réponse à une demande de ressource protégée sans authentification:

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

Et en réponse à une demande de ressource protégée avec une tentative d'authentification utilisant un jeton d'accès expiré:

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

5
Oui. Il est lié aux ours. De la même manière que le python est lié aux serpents. Duh.
Nicholas Hamilton

4
Ours .. Ça suffit. Merci d'avoir fait ma journée.
user2501323

Est-ce une vulnérabilité si: je donne à l'utilisateur le jeton, mais quand il veut m'envoyer une demande, il doit renvoyer le jeton dans le corps de la demande? Je vais ensuite le récupérer et valider? Je n'ai pas vraiment d'autres options, car la façon dont ils envoient la demande n'est pas définie par moi, mais je serais intéressé si cela était mauvais ou s'il y avait une solution pour la rendre plus sécurisée.
Daniel Jeney
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.