En quoi consiste exactement le OAuth 2.0 Bearer Token?
Selon RFC675 - Le OAuth 2.0 Authorization Framework: Utilisation du jeton de support, le jeton de 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 la manière que toute autre partie en possession de celui-ci peut.
Pour moi, cette définition est vague et je ne trouve aucune spécification.
- Supposons que je mette en place un fournisseur d'autorisation. Puis-je fournir n'importe quel type de chaîne pour le jeton porteur?
- Cela peut-il être une chaîne aléatoire?
- Faut-il que ce soit un encodage base64 de certains attributs?
Devrait-il être haché? - Et le fournisseur de services doit-il interroger le fournisseur d'autorisation pour valider ce jeton?
Merci pour tout pointeur.
Jeton au porteur
Un jeton de sécurité avec le bien que toute partie en possession du jeton (un "porteur") peut utiliser le jeton de la manière que toute autre partie en possession du jeton 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 jeton porteur ou le jeton d'actualisation est créé pour vous par le serveur d'authentification. Lorsqu'un utilisateur authentifie votre application (client), le serveur d'authentification va générer pour vous un jeton de support (jeton d'actualisation) que vous pouvez ensuite utiliser pour obtenir un jeton d'accès.
Le jeton de porteur est normalement une sorte de valeur secrète 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 obtient l'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 porteur avec votre identifiant client. Ainsi, le serveur sait que l’application utilisant le jeton porteur est la même application pour laquelle le jeton porteur 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 au porteur que vous fournissez. La seule chose à laquelle je peux penser, c'est qu'il est agréable d'en autoriser plus d'un. Par exemple, un utilisateur peut authentifier l'application jusqu'à 30 fois et les anciens jetons porteurs continueront à fonctionner. oh et si on n'a pas été utilisé pendant 6 mois, par exemple, je le retirerais de votre système. C’est votre serveur d’authentification qui devra les générer et les valider afin de déterminer le formatage.
Mise à jour:
Un jeton de support est défini dans l'en-tête d'autorisation de chaque demande HTTP 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" dans l'exemple ci-dessus est le jeton d'autorisation support. Il s'agit d'un jeton cryptographique produit par le serveur d'authentification. Tous les jetons porteurs envoyés avec des actions ont le champ d'émission, le champ d'audience spécifiant le domaine de l'expéditeur en tant qu'URL de la forme https: //. Par exemple, si l'e-mail provient de [email protected], l'audience est https://example.com .
Si vous utilisez des jetons porteurs, vérifiez que la demande provient du serveur d'authentification et qu'elle est destinée au domaine de l'expéditeur. Si le jeton ne se vérifie pas, le service doit répondre à la demande avec un code de réponse HTTP 401 (non autorisé).
Les jetons de support font partie du standard OAuth V2 et sont largement adoptés par de nombreuses API.
En lisant votre question, j'ai essayé sans succès de chercher sur Internet comment les jetons de support sont cryptés ou signés. J'imagine que les jetons porteurs 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 à la fonctionnalité de jeton de porteur:
Supposons que je mette en place un fournisseur d'autorisation. Puis-je fournir n'importe quel type de chaîne pour le jeton porteur? Cela peut-il être une chaîne aléatoire? Faut-il que ce soit un encodage base64 de certains attributs? Devrait-il être haché?
Je vais donc essayer d'expliquer comment fonctionnent les jetons porteur et Refresh:
Lorsque l'utilisateur demande au serveur un jeton qui envoie l'utilisateur et le mot de passe via SSL, le serveur renvoie deux éléments: un jeton d'accès et un rafraîchir le jeton.
Un jeton d'accès est un jeton de support que vous devrez ajouter dans tous les en-têtes de requête pour être authentifié en tant qu'utilisateur concret.
Authorization: Bearer <access_token>
Un jeton d'accès est une chaîne chiffrée avec toutes les propriétés, revendications et rôles de l'utilisateur souhaités. (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 sera en mesure de le décrypter et de lire ces propriétés d'utilisateur. De cette façon, l'utilisateur sera validé et accordé avec toute l'application.
Les jetons d'accès ont une expiration courte (30 minutes). Si les jetons d'accès avaient une longue date d'expiration, ce serait un problème, car en théorie, il n'y a aucune possibilité de le révoquer. Alors imaginez un utilisateur avec un rôle = "Admin" qui devient "Utilisateur". Si un utilisateur conserve l'ancien jeton avec role = "Admin", il pourra y accéder jusqu'à l'expiration du jeton avec les droits d'administrateur. C'est pourquoi les jetons d'accès ont une expiration courte.
Mais un problème vient à l’esprit. Si un jeton d'accès a une expiration courte, nous devons envoyer chaque utilisateur pour la période courte et le mot de passe. Est-ce sécurisé? Non ce n'est pas. Nous devrions l'éviter. C'est alors que les jetons Actualiser semblent résoudre ce problème.
Les jetons d'actualisation sont stockés dans la base de données et expireront longtemps (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 qu'il a 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).
Si un jeton d'accès d'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 informatique tentera d'obtenir un nouveau jeton d'accès envoyant le jeton d'actualisation, cette action sera refusée.
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 codé en base64? , ce n'est pas le cas.
Pour aller un peu plus loin dans "HTTP/1.1, partie 7: Authentification" **, cependant, je vois que b64token est juste une définition de syntaxe ABNF permettant des caractères typiquement utilisés en base64, base64url, etc. Ainsi, b64token ne Définissez tout codage ou décodage, mais définissez simplement quels caractères peuvent être utilisés dans la partie de l'en-tête Authorization qui contiendra le jeton d'accès.