JWT (Json Web Token) Audience "aud" versus Client_Id - Quelle est la différence?
Je travaille sur l'implémentation de OAuth 2.0 JWT access_token dans mon serveur d'authentification. Mais je ne comprends pas bien quelles sont les différences entre la revendication JWT aud et le client_id Valeur d'en-tête HTTP. Sont-ils les mêmes? Si non, pouvez-vous expliquer la différence entre les deux?
Je soupçonne que aud devrait faire référence au (x) serveur (s) de ressources, et le client_id doit faire référence à l’une des applications clientes reconnues par le serveur d’authentification (application Web, ou application iOS).
Dans mon cas actuel, mon serveur de ressources est également mon client d'application Web.
Il se trouve que mes soupçons étaient justes. La revendication d'audience aud dans un fichier JWT est destinée à faire référence aux serveurs de ressources qui doivent accepter le jeton.
Comme this post le dit simplement:
Le public d'un jeton est le destinataire prévu du jeton.
La valeur d'audience est une chaîne - généralement l'adresse de base de la ressource à accéder, telle que
https://contoso.com.
Le client_id Dans OAuth fait référence à l'application cliente qui demandera des ressources au serveur de ressources.
L'application client (votre application iOS, par exemple) demandera un JWT à votre serveur d'authentification. Ce faisant, il transmet ses client_id Et client_secret Avec les informations d'identification de l'utilisateur éventuellement requises. Le serveur d'autorisations valide le client à l'aide des paramètres client_id Et client_secret Et renvoie un fichier JWT.
Le JWT contiendra une revendication aud qui spécifie les serveurs de ressources pour lesquels le JWT est valide. Si aud contient www.myfunwebapp.com, Mais que l'application cliente tente d'utiliser le JWT sur www.supersecretwebapp.com, L'accès sera refusé car ce serveur de ressources verra que le JWT n'était pas destiné. pour ça.
La réclamation JWT aud (public)
Selon RFC 7519 :
La revendication "aud" (public) identifie les destinataires auxquels le fichier JWT est destiné. Chaque principal destiné à traiter le JWT DOIT s'identifier avec une valeur dans la revendication d'audience. Si le traitement principal, la revendication ne s'identifie pas avec une valeur dans la revendication "aud" lorsque cette revendication est présente, le JWT DOIT alors être rejeté. Dans le cas général, la valeur "aud" est un tableau de chaînes sensibles à la casse, chacune contenant une valeur StringOrURI. Dans le cas particulier où le JWT a une audience, la valeur "aud" PEUT être une chaîne sensible à la casse contenant une valeur StringOrURI. L'interprétation des valeurs d'audience est généralement spécifique à l'application. L'utilisation de cette revendication est FACULTATIVE.
La revendication Audience (aud) définie par la spécification est générique et spécifique à l'application. L'utilisation prévue est d'identifier les destinataires prévus du jeton. Qu'est-ce qu'un destinataire signifie est spécifique à l'application. Une valeur d'audience est soit une liste de chaînes, soit une seule chaîne s'il n'y a qu'une seule revendication aud. Le créateur du jeton n'impose pas que aud soit validé correctement. Il incombe au destinataire de déterminer si le jeton doit être utilisé.
Quelle que soit la valeur, lorsqu'un destinataire valide le JWT et souhaite valider que le jeton était destiné à être utilisé à ses fins, il DOIT déterminer quelle valeur dans aud s'identifie et le jeton doit uniquement valider. si l'ID déclaré du destinataire est présent dans la revendication aud. Peu importe qu'il s'agisse d'une URL ou d'une autre chaîne spécifique à l'application. Par exemple, si mon système décide de s’identifier dans aud avec la chaîne: api3.app.com alors il ne devrait accepter le JWT que si la revendication aud contient api3.app.com dans sa liste de valeurs d’audience.
Bien sûr, les destinataires peuvent choisir de ne pas tenir compte de aud. Ce n'est donc utile que si un destinataire souhaite une validation positive de la création spécifique du jeton.
Mon interprétation basée sur la spécification est que la revendication aud est utile pour créer des fichiers JWT spécialement conçus qui ne sont valables que pour certains objectifs. Pour un système, cela peut signifier que vous souhaitez qu'un jeton soit valide pour certaines fonctionnalités, mais pas pour d'autres. Vous pouvez émettre des jetons limités à un certain "public" tout en utilisant les mêmes clés et le même algorithme de validation.
Comme dans la plupart des cas, un JWT est généré par un service sécurisé et utilisé par d'autres systèmes sécurisés (systèmes ne souhaitant pas utiliser de jetons non valides), ces systèmes doivent simplement coordonner les valeurs qu'ils utiliseront.
Bien entendu, aud est complètement facultatif et peut être ignoré si votre cas d'utilisation ne le justifie pas. Si vous ne souhaitez pas limiter l'utilisation de jetons à des publics spécifiques, ou qu'aucun de vos systèmes ne valide le jeton aud, il est alors inutile.
Exemple: accès par rapport aux jetons d'actualisation
Un exemple artificiel (mais simple) auquel je peux penser est peut-être que nous souhaitons utiliser des JWT pour accéder à des jetons d'actualisation sans avoir à mettre en œuvre des clés de cryptage et des algorithmes distincts, mais simplement pour nous assurer que les jetons d'accès ne seront pas validés comme des jetons d'actualisation, ou vice versa. -versa.
En utilisant aud, nous pouvons spécifier une revendication de refresh pour les jetons d'actualisation et une revendication de access pour les jetons d'accès lors de la création de ces jetons. Lorsqu'une demande est faite pour obtenir un nouveau jeton d'accès à partir d'un jeton d'actualisation, nous devons valider que le jeton d'actualisation est un véritable jeton d'actualisation. La validation aud décrite ci-dessus nous dira si le jeton était réellement un jeton d'actualisation valide en recherchant spécifiquement une revendication de refresh dans aud.
ID client OAuth et JWT aud Revendication
L'ID client OAuth) est totalement indépendant et n'a aucune corrélation directe avec les revendications JWT aud. Du point de vue de OAuth, les jetons sont des objets opaques.
L'application qui accepte ces jetons est responsable de l'analyse et de la validation de la signification de ces jetons. Je ne vois pas beaucoup de valeur à spécifier OAuth ID client dans une revendication JWT aud.