web-dev-qa-db-fra.com

Quelle est la différence entre l'authentification basée sur OAuth et l'authentification basée sur les jetons?

Je pensais que OAuth est fondamentalement une spécification d'authentification basée sur un jeton, mais la plupart du temps, les frameworks agissent comme s'il y avait une différence entre eux. Par exemple, comme indiqué dans l'image ci-dessous Jhipster demande si une authentification basée sur OAuth ou sur un jeton est utilisée. 

N'est-ce pas la même chose? Quelle est exactement la différence puisque les deux incluent des jetons dans leurs implémentations?

 enter image description here

49
Cemre

C'est une bonne question - il y a beaucoup de confusion autour des jetons et de OAuth.

Tout d'abord, lorsque vous mentionnez OAuth, vous faites probablement référence à la norme OAuth2 . Ceci est la dernière version du protocole OAuth, et c'est ce dont la plupart des gens parlent spécifiquement quand ils disent «OAuth».

Le protocole OAuth prend en charge plusieurs types d'authentification et d'autorisation (4 pour être précis).

Deuxièmement, le protocole OAuth fonctionne en authentifiant les utilisateurs via des jetons. L'idée ici est la suivante:

Au lieu que votre utilisateur envoie ses informations d'identification réelles à votre serveur pour chaque requête (comme avec une authentification de base, lorsqu'un utilisateur envoie son nom d'utilisateur/mot de passe au serveur pour chaque demande), avec OAuth, vous échangez d'abord vos informations d'identification contre une "jeton", puis authentifiez les utilisateurs en fonction de ce "jeton".

OAuth a pour principe qu'en obligeant les utilisateurs à transmettre moins fréquemment leurs informations d'identification confidentielles sur le réseau, des incidents moins graves peuvent se produire. (C'est l'idée, de toute façon.)

Maintenant, voici où les jetons entrent en jeu: la spécification OAuth est construite autour du concept de jetons, mais ne précise pas ce qu'est un jeton.

Au sens le plus général, un jeton est simplement une chaîne qui identifie de manière unique un utilisateur. C'est tout.

Les gens l'ont compris et ont développé un nouveau standard pour la création de jetons, appelé JSON Web Token standard . Cette norme fournit essentiellement un ensemble de règles pour la création de jetons d’une manière très spécifique, ce qui rend les jetons plus utiles pour vous en général.

Les JWT vous permettent de faire des choses comme:

  • Signez de manière cryptographique un jeton afin de vous assurer qu'un utilisateur n'a pas altéré le jeton.
  • Cryptez les jetons pour que le contenu ne puisse pas être lu en texte brut.
  • Incorporer les données JSON À L'INTÉRIEUR d'une chaîne de jetons de manière standard.

Pour l’essentiel, pratiquement tous les membres de la communauté de développement ont convenu que si vous utilisez une sorte d’OAuth, les jetons que vous utilisez doivent être des jetons Web JSON.

==========

D'ACCORD! Maintenant que nous avons couvert l'historique, laissez-moi répondre à votre question.

Le choix que vous faites ci-dessus est de décider si vous souhaitez ou non activer la spécification OAuth2 complète pour l'authentification/autorisation (ce qui est assez complexe), ou si vous voulez simplement une "authentification par jeton" de base.

Étant donné que le protocole OAuth fournit de nombreuses façons différentes de s'authentifier de manière conforme à STANDARDS, il ajoute beaucoup de complexité à la plupart des systèmes d'authentification.

Pour cette raison, de nombreux frameworks offrent une version «simplifiée» du flux OAuth2 Password Grant, qui est essentiellement une méthode simple où:

  • Un utilisateur envoie son nom d'utilisateur/mot de passe à votre serveur à une URL telle que/login.
  • Votre serveur génère un jeton JWT pour l'utilisateur.
  • Votre serveur renvoie ce jeton à l'utilisateur.
  • L'utilisateur stocke ce jeton dans ses cookies, son appareil mobile ou son éventuel serveur API, où il l'utilise pour effectuer des requêtes.

Encore une fois: le flux ci-dessus n’est PAS conforme à OAuth, mais il s’agit d’une version légèrement plus simple qui utilise encore des jetons.

Le point principal ici est que les jetons (JWT) sont généralement utiles, et n’ONT PAS BESOIN d’être associés au flux OAuth.

Je réalise que c'est un mur de texte, mais j'espère que cela répond à votre question plus en profondeur =)

112
rdegges

Lorsque vous demandez une ressource à un service Web sécurisé, vous pouvez fournir un jeton d'authentification lors de l'appel. Le jeton agit comme un "code secret" pour accéder à la ressource.

OAuth est simplement un type spécifique de méthode d'authentification basée sur un jeton.

5
lipponen

OAuth est une spécification pour l'autorisation et non pour l'authentification

OAuth 2.0 est une spécification pour l'autorisation, mais PAS pour l'authentification. RFC 6749, 3.1. Autorisation Endpoint dit explicitement ce qui suit:

Le noeud final d'autorisation est utilisé pour interagir avec le propriétaire de la ressource et obtenir une autorisation d'autorisation. Le serveur d'autorisation DOIT d'abord vérifier l'identité du propriétaire de la ressource. La manière dont le Le serveur d’authentification authentifie le propriétaire de la ressource (par exemple, nom d’utilisateur et mot de passe de connexion, cookies de session) est au-delà de la portée de cette spécification.

N'utilisez OAuth que si vous souhaitez donner accès à un service tiers à vos apis. Même lorsque vous utilisez OAuth, une authentification (basée sur un jeton ou sur une session, etc.) est nécessaire pour authentifier les utilisations. OAuth n'est pas conçu pour l'authentification.

voir cette question .

0
nithin