Qu'est-ce que l'authentification par jeton?


Réponses:


544

Je pense que c'est bien expliqué ici - en ne citant que les phrases clés du long article:

Le concept général derrière un système d'authentification basé sur des jetons est simple. Autoriser les utilisateurs à entrer leur nom d'utilisateur et leur mot de passe afin d'obtenir un jeton qui leur permet de récupérer une ressource spécifique - sans utiliser leur nom d'utilisateur et leur mot de passe. Une fois son jeton obtenu, l'utilisateur peut proposer le jeton - qui donne accès à une ressource spécifique pendant une période donnée - au site distant.

En d'autres termes: ajouter un niveau d'indirection pour l'authentification - au lieu d'avoir à s'authentifier avec un nom d'utilisateur et un mot de passe pour chaque ressource protégée, l'utilisateur s'authentifie de cette façon une fois (dans une session de durée limitée), obtient en retour un jeton limité dans le temps et utilise ce jeton pour une authentification supplémentaire au cours de la session.

Les avantages sont nombreux - par exemple, l'utilisateur peut transmettre le jeton, une fois qu'il l'a obtenu, à un autre système automatisé auquel il est prêt à faire confiance pour un temps limité et un ensemble limité de ressources, mais ne serait pas disposé faire confiance à leur nom d'utilisateur et à leur mot de passe (c'est-à-dire à toutes les ressources auxquelles ils sont autorisés à accéder, pour toujours ou au moins jusqu'à ce qu'ils changent leur mot de passe).

Si quelque chose n'est toujours pas clair, veuillez modifier votre question pour clarifier ce qui n'est pas clair à 100% pour vous, et je suis sûr que nous pouvons vous aider davantage.


6
Ai-je raison de penser que dans une application Web, un (ou plusieurs) cookie (s) du site Web distant remplit la fonction du jeton?
AJP

29
Comme les jetons sont stockés sous forme de cookies, y a-t-il quelque chose en place pour empêcher une personne de voler ce cookie / jeton et de l'utiliser lui-même, incitant le serveur à penser qu'il est l'utilisateur autorisé? De toute évidence, ils ne pouvaient l'utiliser que pendant x périodes de temps, mais pendant cette période, ils pouvaient faire tous les dégâts dont ils avaient besoin.
BenM

40
En quoi est-ce différent de SessionAuthentication, où l'utilisateur peut obtenir un session_id en écoutant son nom d'utilisateur et son mot de passe, puis utilise ce session_id dans la demande suivante?
Saurabh Verma

4
si le jeton expire, l'utilisateur doit-il se reconnecter pour obtenir un nouveau jeton?
Anthony au

12
@SaurabhVerma c'est différent d'une session car vous n'avez pas besoin de stocker les informations dans un cookie. C'est génial pour les appareils mobiles, dont certains ont des restrictions sur l'utilisation des cookies.
Kebman

182

Depuis Auth0.com

L'authentification basée sur les jetons, repose sur un jeton signé envoyé au serveur à chaque demande.

Quels sont les avantages de l'utilisation d'une approche basée sur des jetons?

  • Cross-domain / CORS: les cookies + CORS ne fonctionnent pas bien sur différents domaines. Une approche basée sur des jetons vous permet d'effectuer des appels AJAX vers n'importe quel serveur, sur n'importe quel domaine car vous utilisez un en-tête HTTP pour transmettre les informations utilisateur.

  • Sans état (ou évolutivité côté serveur): il n'est pas nécessaire de conserver un magasin de sessions, le jeton est une entité autonome qui transmet toutes les informations utilisateur. Le reste de l'État vit dans les cookies ou le stockage local côté client.

  • CDN: vous pouvez servir tous les actifs de votre application à partir d'un CDN (par exemple javascript, HTML, images, etc.), et votre côté serveur n'est que l'API.

  • Découplage: vous n'êtes lié à aucun schéma d'authentification particulier. Le jeton peut être généré n'importe où, votre API peut donc être appelée de n'importe où avec une seule façon d'authentifier ces appels.

  • Prêt pour les mobiles: lorsque vous commencez à travailler sur une plate-forme native (iOS, Android, Windows 8, etc.), les cookies ne sont pas idéaux lorsque la consommation d'une approche basée sur des jetons simplifie beaucoup cela.

  • CSRF: puisque vous ne comptez pas sur les cookies, vous n'avez pas besoin de vous protéger contre les demandes intersites (par exemple, il ne serait pas possible de sib votre site, de générer une demande POST et de réutiliser le cookie d'authentification existant car il n'y en aura pas ).

  • Performances: nous ne présentons pas ici de références de performances , mais un aller-retour réseau (par exemple, trouver une session sur une base de données) prendra probablement plus de temps que de calculer un HMACSHA256 pour valider un jeton et analyser son contenu.


6
@Asik Tous les points ici sont valables sauf "Stateless" lorsque vous commencez à traiter la révocation de jetons, la liste noire, la prévention des attaques par réponse, etc.
svlada

Le site cité recommande un article plus récent sur le même sujet: auth0.com/blog/cookies-vs-tokens-definitive-guide
ASalazar

2
Vous voudrez peut-être lire "Cesser d'utiliser JWT pour les sessions": cryto.net/~joepie91/blog/2016/06/13/stop-using-jwt-for-sessions
Juraj Martinka

1
Asik, que diriez-vous de la validité du jeton et quand il arriverait à expiration? Si vous ajoutez ces informations, ce serait bien.
Arun Prakash

2
Le lien est maintenant rompu.
Vue elliptique du

95

A tokenest un élément de données qui Server Xn'aurait pu qu'être créé et qui contient suffisamment de données pour identifier un utilisateur particulier.

Vous pouvez présenter vos informations de connexion et demander Server Xun token; puis vous pourriez présenter votre tokenet demander Server Xd'effectuer une action spécifique à l'utilisateur.

Tokens sont créés en utilisant diverses combinaisons de diverses techniques du domaine de la cryptographie ainsi qu'avec des contributions du domaine plus large de la recherche en sécurité. Si vous décidez de créer votre propre tokensystème, il vaut mieux être vraiment intelligent.


4
En règle générale, si vous souhaitez une authentification basée sur des jetons, vous devez commencer par OAuth.
Bob Aman

6
OAuth est certainement viable dans une application Web. Mais, par exemple, les sessions de connexion au système d'exploitation utilisent également des systèmes à jetons, comme le font de nombreux autres types de logiciels, cette idée n'est donc pas limitée au Web.
yfeldblum

1
Un jeton est probablement également préférable pour un système de support client non public. La société contrôle le nom d'utilisateur / mot de passe et émet et contrôle le jeton.
KevinManx

chrs - mais en quoi ce système est-il différent d'un système basé sur une session?
BKSpurgeon

@BKSpurgeon - Les jetons sont un moyen courant d'implémenter des sessions authentifiées.
yfeldblum

40

Un jeton est un élément de données créé par le serveur et contient des informations permettant d'identifier un utilisateur particulier et la validité du jeton. Le jeton contiendra les informations de l'utilisateur, ainsi qu'un code de jeton spécial que l'utilisateur peut transmettre au serveur avec chaque méthode prenant en charge l'authentification, au lieu de transmettre directement un nom d'utilisateur et un mot de passe.

L'authentification basée sur les jetons est une technique de sécurité qui authentifie les utilisateurs qui tentent de se connecter à un serveur, un réseau ou un autre système sécurisé, à l'aide d'un jeton de sécurité fourni par le serveur.

Une authentification réussit si un utilisateur peut prouver à un serveur qu'il est un utilisateur valide en transmettant un jeton de sécurité. Le service valide le jeton de sécurité et traite la demande de l'utilisateur.

Une fois le jeton validé par le service, il est utilisé pour établir le contexte de sécurité du client, afin que le service puisse prendre des décisions d'autorisation ou auditer l'activité pour les demandes d'utilisateurs successives.

visiter la source


22

Basé sur les jetons (sécurité / authentification)

signifie que pour que nous puissions prouver que nous avons accès, nous devons d'abord recevoir le jeton. Dans un scénario réel, le jeton pourrait être une carte d'accès au bâtiment, il pourrait être la clé de la serrure de votre maison. Pour que vous puissiez récupérer une carte-clé pour votre bureau ou la clé de votre domicile, vous devez d'abord prouver qui vous êtes et que vous avez en fait accès à ce jeton. Cela peut être aussi simple que de montrer votre identité à quelqu'un ou de lui donner un mot de passe secret. Imaginez donc que j'ai besoin d'accéder à mon bureau. Je descends au bureau de sécurité, je leur montre ma carte d'identité et ils me donnent ce jeton qui me permet d'entrer dans le bâtiment. Maintenant, j'ai un accès illimité pour faire tout ce que je veux à l'intérieur du bâtiment, tant que j'ai mon jeton avec moi.

Quel est l'avantage de la sécurité basée sur les jetons?

Si nous repensons à l'API non sécurisée, ce que nous devions faire dans ce cas était que nous devions fournir notre mot de passe pour tout ce que nous voulions faire.

Imaginerque chaque fois que nous entrons dans une porte de notre bureau, nous devons donner à tout le monde assis à côté de la porte notre mot de passe. Maintenant, ce serait assez mauvais, car cela signifie que n'importe qui dans notre bureau pourrait prendre notre mot de passe et nous usurper l'identité, et c'est assez mauvais. Au lieu de cela, ce que nous faisons, c'est que nous récupérons le jeton, bien sûr avec le mot de passe, mais nous le récupérons d'une seule personne. Et puis nous pouvons utiliser ce jeton où nous voulons à l'intérieur du bâtiment. Bien sûr, si nous perdons le jeton, nous avons le même problème que si quelqu'un d'autre connaissait notre mot de passe, mais cela nous amène à des choses comme comment nous assurer que si nous perdons le jeton, nous pouvons révoquer l'accès, et peut-être le jeton ne devrait pas vivre plus de 24 heures, donc le lendemain que nous venons au bureau, nous devons montrer à nouveau notre pièce d'identité. Mais encore, il n'y a qu'une seule personne à qui nous montrons l'ID,


15

La question est ancienne et la technologie a avancé, voici l'état actuel:

JSON Web Token (JWT) est une norme ouverte basée sur JSON (RFC 7519) pour le transfert de réclamations entre les parties dans un environnement d'application Web. Les jetons sont conçus pour être compacts, sûrs pour les URL et utilisables en particulier dans le contexte de l'authentification unique (SSO) du navigateur Web.

https://en.wikipedia.org/wiki/JSON_Web_Token


1
Je ne pense pas que JWT représente l'état actuel de la technologie pour implémenter l'authentification basée sur les jetons. Ce n'est qu'une façon de le mettre en œuvre et avec de nombreux défauts qui sont éloquemment mis en avant par des articles tels que cryto.net/~joepie91/blog/2016/06/13/stop-using-jwt-for-sessions
Sung Cho

3

C'est juste du hachage qui est associé à l'utilisateur dans la base de données ou d'une autre manière. Ce jeton peut être utilisé pour authentifier puis autoriser un utilisateur à accéder aux contenus liés à l'application. Pour récupérer ce jeton du côté client, une connexion est requise. Après la première connexion, vous devez enregistrer le jeton récupéré, pas d'autres données comme la session, l'identifiant de session, car ici tout est un jeton pour accéder à d'autres ressources de l'application.

Le jeton est utilisé pour garantir l'authenticité de l'utilisateur.


3

L'approche la plus préférée de nos jours pour sécuriser les ressources de l'API Web consiste à authentifier les utilisateurs du serveur API Web en utilisant le jeton signé (qui contient suffisamment d'informations pour identifier un utilisateur particulier) qui doit être envoyé au serveur par le client avec chacun et chaque demande. C'est ce qu'on appelle l'approche d'authentification basée sur les jetons.

L'authentification basée sur les jetons fonctionne comme suit:

Un utilisateur entre le nom et le mot de passe dans le client (client signifie le navigateur ou les appareils mobiles, etc.).

Le client envoie ensuite ces informations d'identification (c'est-à-dire nom d'utilisateur et mot de passe) au serveur d'autorisation.

Ensuite, le serveur d'autorisation authentifie les informations d'identification du client (c'est-à-dire le nom d'utilisateur et le mot de passe), puis il génère et renvoie un jeton d'accès. Ce jeton d'accès contient suffisamment d'informations pour identifier un utilisateur et contient également l'heure d'expiration du jeton.

L'application client inclut ensuite le jeton d'accès dans l'en-tête d'autorisation de la demande HTTP pour accéder aux ressources restreintes à partir du serveur de ressources jusqu'à l'expiration du jeton.

L'article suivant montre comment implémenter étape par étape l'authentification basée sur les jetons dans l'API WEB.

https://dotnettutorials.net/lesson/token-based-authentication-web-api/


-2

Lorsque vous vous inscrivez à un nouveau site Web, vous recevez souvent un e-mail pour activer votre compte. Cet e-mail contient généralement un lien sur lequel cliquer. Une partie de ce lien contient un jeton, le serveur le connaît et peut l'associer à votre compte. Le token aurait généralement une date d'expiration qui lui est associée, vous ne pouvez donc avoir qu'une heure pour cliquer sur le lien et activer votre compte. Rien de tout cela ne serait possible avec des cookies ou des variables de session, car on ne sait pas quel appareil ou navigateur le client utilise pour vérifier ses e-mails.


11
Le jeton / lien unique est un concept différent de l'authentification basée sur un jeton.
Emile Bergeron

Le nom de ce que vous dites est également symbolique. Mais ce n'est pas la question
sajjad Yosefi
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.