web-dev-qa-db-fra.com

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

Je me demande quel est le meilleur type d’en-tête HTTP Authorization pour jetons JWT .

Un des types probablement les plus populaires est Basic. Par exemple:

Authorization: Basic QWxhZGRpbjpvcGVuIHNlc2FtZQ==

Il gère deux paramètres tels qu'un identifiant et un mot de passe. Donc, ce n'est pas pertinent pour les jetons JWT.

De plus, j'ai entendu parler du type porteur , 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-tête HTTP Authorization? Devrions-nous utiliser Bearer, ou devrions-nous simplifier et utiliser simplement:

Authorization: eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiYWRtaW4iOnRydWV9.TJVA95OrM7E2cBab30RMHrHDcEfxjoYZgeFONFh7HgQ

Merci.

Modifier:

Ou peut-être juste un en-tête HTTP JWT:

JWT: eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiYWRtaW4iOnRydWV9.TJVA95OrM7E2cBab30RMHrHDcEfxjoYZgeFONFh7HgQ
http-headersjwt
192
Zag zag..

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

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

Exemple:

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

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

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 tout autre contexte nécessitant un échange de jetons entre un client et un serveur.

Contrairement au schéma personnalisé JWT que vous mentionnez dans votre question, le Bearer est enregistré auprès de l'IANA .

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

251
Florent Morselli

Réponse courte

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

Longue réponse

Est-ce lié aux ours?

Euh ... non :)

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

porteur  /bɛːrə/
nom

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

  2. Une personne qui présente un chèque ou un autre ordre pour payer de l'argent.

La première définition inclut les synonymes suivants: messager , agent , convoyeur , émetteur , porteuse , fournisseur .

Et voici la définition de jeton porteur selon le RFC 675 :

1.2. Terminologie

Jeton de support

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

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

Tenez-vous-en aux normes autant que vous le pouvez et ne créez pas vos propres schémas d'authentification.

Un jeton d'accès doit être envoyé dans l'en-tête de la requête Authorization à l'aide du schéma d'authentification Bearer:

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

Lors de l'envoi du jeton d'accès dans le champ d'en-tête de demande Authorization défini par HTTP/1.1, le client utilise le schéma d'authentification Bearer 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 porteur en utilisant le champ d'en-tête de demande Authorization avec le schéma d'autorisation HTTP Bearer. [...]

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

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

Si la demande de ressource protégée n'inclut pas d'informations d'identification 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 champ d'en-tête de réponse HTTP _WWW-Authenticate_ [...].

Tous les défis définis par cette spécification DOIVENT utiliser la valeur de schéma d'autorisation Bearer. Ce schéma DOIT être suivi d'une ou de plusieurs valeurs 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 accompagnée d'une tentative d'authentification à l'aide d'un jeton d'accès arrivé à expiration:

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