Qu'est-ce que le jeton porteur OAuth 2.0 exactement?

171

Selon RFC6750 -The OAuth 2.0 Authorization Framework: Bearer Token Usage, le token support est:

Un jeton de sécurité avec la propriété que toute partie en possession du jeton (un «porteur») peut utiliser le jeton de n'importe quelle manière que n'importe quelle autre partie en possession de celui-ci peut.

Pour moi, cette définition est vague et je ne trouve aucune spécification.

Supposons que j'implémente un fournisseur d'autorisation, puis-je fournir n'importe quel type de chaîne pour le jeton de support?
Cela peut-il être une chaîne aléatoire?
Doit-il être un encodage base64 de certains attributs?
Doit-il être haché?
Et le fournisseur de services doit-il interroger le fournisseur d'autorisation afin de valider ce jeton?

Merci pour tout pointeur.

oauth bearer-token

— Alex Beaupré
source

Supposons que j'implémente un fournisseur d'autorisation, puis-je fournir n'importe quel type de chaîne pour le jeton de support? Cela peut-il être une chaîne aléatoire?. Les jetons d'accès sont émis via les points de terminaison OAuth 2.0 d'Auth0: / authorize et / oauth / token. Vous pouvez utiliser n'importe quelle bibliothèque compatible OAuth 2.0 pour obtenir des jetons d'accès. Si vous ne disposez pas déjà d'une bibliothèque OAuth 2.0 préférée, Auth0 fournit des bibliothèques pour de nombreux langages et frameworks.

— Bharathkumar V

Réponses:

146

Jeton au porteur
Un jeton de sécurité avec la propriété que toute partie en possession du jeton (un «porteur») peut utiliser le jeton de n'importe quelle manière que n'importe quelle autre partie en possession de celui-ci peut. L'utilisation d'un jeton au porteur n'exige pas que le porteur prouve la possession du matériel de clé cryptographique (preuve de possession).

Le jeton de support est créé pour vous par le serveur d'authentification. Lorsqu'un utilisateur authentifie votre application (client), le serveur d'authentification va alors et génère pour vous un Token. Les jetons au porteur sont le type de jeton d'accès prédominant utilisé avec OAuth 2.0. Un jeton porteur dit essentiellement "Donner l'accès au porteur de ce jeton".

Le jeton de support est normalement une sorte de valeur opaque créée par le serveur d'authentification. Ce n'est pas aléatoire; il est créé en fonction de l'utilisateur qui vous donne l'accès et du client auquel votre application a accès.

Pour accéder à une API par exemple, vous devez utiliser un jeton d'accès. Les jetons d'accès sont de courte durée (environ une heure). Vous utilisez le jeton porteur pour obtenir un nouveau jeton d'accès. Pour obtenir un jeton d'accès, vous envoyez au serveur d'authentification ce jeton de support avec votre identifiant client. De cette façon, le serveur sait que l'application utilisant le jeton de support est la même application pour laquelle le jeton de support a été créé. Exemple: je ne peux pas simplement prendre un jeton porteur créé pour votre application et l'utiliser avec mon application, cela ne fonctionnera pas car il n'a pas été généré pour moi.

Le jeton Google Refresh ressemble à ceci: 1 / mZ1edKKACtPAb7zGlwSzvs72PvhAbGmB8K1ZrGxpcNM

copié du commentaire: je ne pense pas qu'il y ait de restrictions sur les jetons de porteur que vous fournissez. La seule chose à laquelle je pense, c'est que c'est bien d'en autoriser plus d'un. Par exemple, un utilisateur peut authentifier l'application jusqu'à 30 fois et les anciens jetons de support fonctionneront toujours. oh et si l'un n'a pas été utilisé depuis, disons 6 mois, je le supprimerais de votre système. C'est votre serveur d'authentification qui devra les générer et les valider pour que le formatage soit à vous.

Mettre à jour:

Un jeton de support est défini dans l'en-tête d'autorisation de chaque requête HTTP d'action en ligne. Par exemple:

POST /rsvp?eventId=123 HTTP/1.1
Host: events-organizer.com
Authorization: Bearer AbCdEf123456
Content-Type: application/x-www-form-urlencoded
User-Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/1.0 (KHTML, like Gecko; Gmail Actions)

rsvpStatus=YES

La chaîne "AbCdEf123456"de l'exemple ci-dessus est le jeton d'autorisation du porteur. Il s'agit d'un jeton cryptographique produit par le serveur d'authentification. Tous les jetons de support envoyés avec des actions ont le champ de problème, le champ d'audience spécifiant le domaine de l'expéditeur sous la forme d'une URL de la forme https: //. Par exemple, si l'e-mail provient de noreply@example.com, l'audience est https://example.com .

Si vous utilisez des jetons de support, vérifiez que la demande provient du serveur d'authentification et est destinée au domaine de l'expéditeur. Si le jeton ne vérifie pas, le service doit répondre à la demande avec un code de réponse HTTP 401 (non autorisé).

Les jetons au porteur font partie de la norme OAuth V2 et sont largement adoptés par de nombreuses API.

— DaImTo
source

@ Le jeton Xavier Egea Bearer est essentiellement votre jeton d'actualisation et non le jeton d'accès.

— Akhil Nambiar

Le jeton du porteur ne signifie pas qu'il s'agit d'un jeton d'actualisation @AqeelSmith tools.ietf.org/html/rfc6750#section-6.1.1

— Suman Kundu

Le premier paragraphe implique qu'un jeton de support est un jeton d'actualisation et non un jeton d'accès. Ce n'est pas le cas. Extrait de la spécification de jeton de support "Cette spécification décrit comment effectuer des demandes de ressources protégées lorsque le jeton d'accès OAuth est un jeton de support." RFC6750

— Daniel

Après avoir lu la réponse, j'ai également pensé que le jeton porteur et les jetons d'actualisation sont les mêmes. La réponse doit être mise à jour pour clarifier cela.

— KurioZ7

Cette réponse est très trompeuse. Les jetons de support ne sont PAS des jetons d'actualisation, comme l'indique la déclaration initiale de cette réponse. Corrigez s'il vous plaît.

— think01

En lisant votre question, j'ai essayé sans succès de rechercher sur Internet comment les jetons Bearer sont chiffrés ou signés. Je suppose que les jetons de support ne sont pas hachés (peut-être partiellement, mais pas complètement) car dans ce cas, il ne sera pas possible de les décrypter et d'en récupérer les propriétés des utilisateurs.

Mais votre question semble essayer de trouver des réponses sur la fonctionnalité du jeton Bearer:

Supposons que j'implémente un fournisseur d'autorisation, puis-je fournir n'importe quel type de chaîne pour le jeton de support? Cela peut-il être une chaîne aléatoire? Doit-il être un encodage base64 de certains attributs? Doit-il être haché?

Donc, je vais essayer d'expliquer comment fonctionnent les jetons Bearer et Refresh:

Lorsque l'utilisateur demande au serveur un jeton envoyant un utilisateur et un mot de passe via SSL, le serveur renvoie deux choses: un jeton d'accès et un jeton d'actualisation .

Un jeton d'accès est un jeton porteur que vous devrez ajouter dans tous les en-têtes de demande pour être authentifié en tant qu'utilisateur concret.

Authorization: Bearer <access_token>

Un jeton d'accès est une chaîne cryptée avec toutes les propriétés utilisateur, revendications et rôles que vous souhaitez. (Vous pouvez vérifier que la taille d'un jeton augmente si vous ajoutez plus de rôles ou de revendications). Une fois que le serveur de ressources reçoit un jeton d'accès, il pourra le déchiffrer et lire ces propriétés utilisateur. De cette façon, l'utilisateur sera validé et accordé avec toute l'application.

Les jetons d'accès ont une courte expiration (c.-à-d. 30 minutes). Si les jetons d'accès avaient une longue expiration, ce serait un problème, car en théorie, il n'y a aucune possibilité de les révoquer. Imaginez donc un utilisateur avec un rôle = "Admin" qui se transforme en "Utilisateur". Si un utilisateur conserve l'ancien token avec role = "Admin", il pourra y accéder jusqu'à l'expiration du token avec les droits Admin. C'est pourquoi les jetons d'accès ont une courte expiration.

Mais, un problème vient à l'esprit. Si un jeton d'accès a une courte expiration, nous devons envoyer à chaque courte période l'utilisateur et le mot de passe. Est-ce sécurisé? Non, ça ne l'est pas. Nous devons l'éviter. C'est à ce moment que les jetons d'actualisation semblent résoudre ce problème.

Les jetons d'actualisation sont stockés dans la base de données et auront une longue expiration (exemple: 1 mois).

Un utilisateur peut obtenir un nouveau jeton d'accès (lorsqu'il expire, toutes les 30 minutes par exemple) à l'aide d'un jeton d'actualisation, que l'utilisateur avait reçu lors de la première demande de jeton. Lorsqu'un jeton d'accès expire, le client doit envoyer un jeton d'actualisation. Si ce jeton d'actualisation existe dans la base de données, le serveur retournera au client un nouveau jeton d'accès et un autre jeton d'actualisation (et remplacera l'ancien jeton d'actualisation par le nouveau).

Dans le cas où un jeton d'accès utilisateur a été compromis, le jeton d'actualisation de cet utilisateur doit être supprimé de la base de données. De cette façon, le jeton ne sera valide que jusqu'à l'expiration du jeton d'accès, car lorsque le pirate tente d'obtenir un nouveau jeton d'accès en envoyant le jeton d'actualisation, cette action sera refusée.

— Xavier Egea
source

Je ne comprends pas cette partie: "Une fois que le serveur d'autorisation aura reçu un jeton d'accès, il pourra le déchiffrer et lire ces propriétés utilisateur. De cette façon, l'utilisateur sera validé et accordé le long de toute l'application". Le serveur d'autorisation n'est-il pas celui qui accorde le jeton d'accès et non le recevoir? J'essaie de comprendre ce sujet et de nombreux exemples font une distinction claire entre le serveur d'autorisation et le serveur de ressources. Ce que j'ai compris, c'est que vous obtenez le jeton d'accès du serveur d'autorisation, puis que vous le transmettez avec chaque demande que vous faites au serveur de ressources?

— kivikall

@kivikall Vous avez raison. Je l'ai changé dans la réponse. Le serveur de ressources reçoit le jeton (le jeton que le serveur d'autorisation a chiffré dans le processus de création de jeton) dans chaque demande et le déchiffre.

— Xavier Egea

@kivikall En fait, décrypter un jeton doit être lié à l'autorisation, il doit donc appartenir au serveur d'autorisation. C'est pourquoi a l'a écrit dans la réponse. Mais en pratique, cela signifierait que dans chaque demande, vous devez valider avec le serveur d'autorisation le jeton reçu (peut-être en effectuant une autre demande). Par conséquent, pour éviter toute perte de performances, il est préférable de donner une partie des fonctionnalités permettant de décrypter le jeton au serveur de ressources. Vérifiez le lien suivant: stackoverflow.com/questions/12296017/…

— Xavier Egea

Mais à chaque demande, le serveur de ressources doit vérifier si le AccessToken fourni est valide par rapport au serveur d'autorisation. Donc, si un rôle change, le changement peut être reflété immédiatement par le serveur d'authentification, n'est-ce pas? Aussi pourquoi supprimerions-nous le RefreshToken si l'AccessToken était compromis? Le RefreshToken ne peut pas être calculé en fonction du AccessToken, donc quand il expire, le pirate est de nouveau bloqué.

— mandarin

Comme je l'ai dit, le jeton d'accès contient des informations sur l'utilisateur, comme le rôle. Si un rôle d'utilisateur change, ce changement sera reflété dans le jeton suivant lorsque le jeton actuel expirera. Cela signifie que dans un court laps de temps (jusqu'à l'expiration du jeton d'accès), l'utilisateur conservera le même rôle et le serveur d'authentification l'autorisera car le jeton est toujours valide. Concernant la deuxième question, la suppression d'un jeton d'actualisation oblige l'utilisateur à réinsérer ses informations d'identification. C'est ce que nous voulons si un jeton d'accès est compomisé. Dans les autres cas, un pirate peut être autorisé jusqu'à l'expiration du jeton de rafraîchissement (par exemple 1 mois)

— Xavier Egea

Le jeton porteur est une ou plusieurs répétitions d'alphabet, de chiffre, "-", "." , "_", "~", "+", "/" suivi de 0 ou plus "=".

RFC 6750 2.1. Champ d'en-tête de demande d'autorisation (le format est ABNF (BNF augmenté))

The syntax for Bearer credentials is as follows:

     b64token    = 1*( ALPHA / DIGIT /
                       "-" / "." / "_" / "~" / "+" / "/" ) *"="
     credentials = "Bearer" 1*SP b64token

Cela ressemble à Base64 mais selon le jeton dans l'en-tête doit-il être encodé en base64? , ce n'est pas.

En creusant un peu plus profondément dans "HTTP / 1.1, partie 7: Authentification" **, cependant, je vois que b64token est juste une définition de syntaxe ABNF permettant les caractères généralement utilisés en base64, base64url, etc. Donc le b64token ne le fait pas définir tout encodage ou décodage, mais définit plutôt simplement quels caractères peuvent être utilisés dans la partie de l'en-tête d'autorisation qui contiendra le jeton d'accès.

Références

— lun
source

Vous n'expliquez pas du tout le but des jetons de porteur.

— Jaime Hablutzel le