Authentification API Web Basic vs Bearer

89

J'ai créé une authentification basée sur JWT dans mon application API Web. Je ne parviens pas à comprendre la différence entre

  1. Jeton de base
  2. Jeton porteur

Quelqu'un peut-il m'aider s'il vous plaît?

basic-authentication jwt bearer-token SharmaPattar
la source

Réponses:

117

Les schémas d'authentification Basic et Digest sont dédiés à l'authentification à l'aide d'un nom d'utilisateur et d'un secret (voir RFC7616 et RFC7617 ).

Le schéma d'authentification du support est dédié à l'authentification à l'aide d'un jeton et est décrit par la RFC6750 . Même si ce schéma provient d'une spécification OAuth2, vous pouvez toujours l'utiliser dans tout autre contexte où les jetons sont échangés entre un client et un serveur.

Concernant l'authentification JWT et comme il s'agit d'un jeton, le meilleur choix est le schéma d'authentification du porteur. Néanmoins, rien ne vous empêche d'utiliser un schéma personnalisé qui pourrait s'adapter à vos besoins.

Florent Morselli
la source
35

L'authentification de base transmet les informations d'identification sous forme de paires ID utilisateur / mot de passe, encodées en base64. Le client envoie des requêtes HTTP avec l'en-Authorizationtête qui contient le motBasicmot suivi d'un espace et d'unebase64-encodedchaîne nom d'utilisateur: mot de passe.

Autorisation: Basic ZGVtbzpwQDU1dzByZA ==

entrez la description de l'image ici Remarque: pour l'authentification de base, comme l'ID utilisateur et le mot de passe sont transmis sur le réseau sous forme de texte clair (il est encodé en base64, mais base64 est un encodage réversible), le schéma d'authentification de base n'est pas sécurisé. HTTPS / TLS doit être utilisé conjointement avec l'authentification de base.

L'authentification du porteur (également appelée authentification par jeton ) a des jetons de sécurité appelés jetons de support. Le nom «authentification du porteur» peut être compris comme « donner accès au porteur de ce jeton ». Le jeton de support est une chaîne cryptique, généralement générée par le serveur en réponse à une demande de connexion. Le client doit envoyer ce jeton dans l'en-tête Authorization lors de la demande aux ressources protégées:

Autorisation: porteur <jeton>

entrez la description de l'image ici

Remarque: comme pour l'authentification de base, l'authentification du porteur ne doit être utilisée que sur HTTPS (SSL) .

Pour plus d' informations link1 , lien2

fgul
la source
ce sont donc tous deux une autorisation et pas vraiment une autorisation. Dans le premier, vous envoyez une chaîne encodée en base64 et obtenez une autorisation, tandis que dans le second, vous récupérez un jeton et l'utilisez pour accéder à la ressource
brain storm
quel est l'avantage de passer le jeton sur le nom d'utilisateur / mot de passe?
Muhammad Umer
@MuhammadUmer vous pouvez révoquer les jetons et leur accorder un accès granulaire (c'est-à-dire uniquement un accès en lecture).
Mihai
J'ai trouvé la réponse et c'est que vous n'avez pas à faire de lecture de base de données avec un jeton, vous pouvez utiliser crypto pour valider le jeton, mieux pour les microservices qui n'ont pas d'état de session partagé, bien qu'il existe un équilibreur de charge qui peut réparer un utilisateur à un service, mais il est toujours performant.
Muhammad Umer