Je travaille sur l'implémentation d'OAuth 2.0 JWT access_token dans mon serveur d'authentification. Mais, je ne suis pas clair sur les différences entre la audrevendication JWT et la client_idvaleur d'en-tête HTTP. Sont-ils les mêmes? Sinon, pouvez-vous expliquer la différence entre les deux?

Je soupçonne que cela auddevrait faire référence au (x) serveur (s) de ressources, et que client_iddevrait faire référence à l'une des applications clientes reconnues par le serveur d'authentification (c'est-à-dire l'application Web ou l'application iOS).

Dans mon cas actuel, mon serveur de ressources est également mon client d'application Web.

En fin de compte, mes soupçons étaient justes. La audrevendication d' audience dans un JWT est censée faire référence aux serveurs de ressources qui doivent accepter le jeton.

Comme le dit simplement cet article:

L'audience 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 en cours d'accès, telle que https://contoso.com.

Le client_iddans OAuth fait référence à l'application cliente qui demandera des ressources au serveur de ressources.

L'application client (par exemple votre application iOS) demandera un JWT à votre serveur d'authentification. Ce faisant, il transmet son client_idet client_secretavec toutes les informations d'identification de l'utilisateur qui peuvent être requises. Le serveur d'autorisation valide le client à l'aide de client_idet client_secretet renvoie un JWT.

Le JWT contiendra une audrevendication qui spécifie les serveurs de ressources pour lesquels le JWT est valide. Si le audcontient www.myfunwebapp.com, mais que l'application cliente essaie d'utiliser le JWT sur www.supersecretwebapp.com, l'accès sera refusé car ce serveur de ressources verra que le JWT ne lui était pas destiné.

La audrevendication JWT (Audience)

Selon RFC 7519 :

La revendication "aud" (audience) identifie les destinataires auxquels le JWT est destiné. Chaque mandant destiné à traiter le JWT DOIT s'identifier avec une valeur dans la revendication d'audience. Si le principal traitant la réclamation ne s'identifie pas avec une valeur dans la réclamation "aud" lorsque cette réclamation est présente, alors le JWT DOIT ê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 un public, la valeur "aud" PEUT être une seule 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 allégation est FACULTATIVE.

La audrevendication Audience ( ) telle que 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. Ce que signifie un destinataire 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 audrevendication. Le créateur du jeton n'applique pas ce qui audest 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 qu'il souhaite valider que le jeton était destiné à être utilisé à ses fins, il DOIT déterminer quelle valeur auds'identifie, et le jeton ne doit valider que si l'ID déclaré du destinataire est présent dans la audréclamation. Peu importe s'il s'agit d'une URL ou d'une autre chaîne spécifique à une application. Par exemple, si mon système décide de s'identifier audavec la chaîne: api3.app.comil ne doit accepter le JWT que si la audrevendication contient api3.app.comdans sa liste des valeurs d'audience.

Bien sûr, les destinataires peuvent choisir de ne pas tenir compte aud, donc cela n'est utile que si un destinataire souhaite une validation positive que le jeton a été créé spécifiquement pour lui.

Mon interprétation basée sur la spécification est que la audrevendication est utile pour créer des JWT spécialement conçus qui ne sont valables qu'à certaines fins. Pour un système, cela peut signifier que vous souhaitez qu'un jeton soit valide pour certaines fonctionnalités, mais non valide pour d'autres. Vous pouvez émettre des jetons qui sont limités à un certain "public", tout en utilisant les mêmes clés et algorithme de validation.

Étant donné que dans le cas typique, un JWT est généré par un service de confiance et utilisé par d'autres systèmes de confiance (systèmes qui ne veulent pas utiliser de jetons non valides), ces systèmes doivent simplement coordonner les valeurs qu'ils utiliseront.

Bien sûr, audc'est complètement facultatif et peut être ignoré si votre cas d'utilisation ne le justifie pas. Si vous ne souhaitez pas restreindre l'utilisation des jetons par des publics spécifiques, ou qu'aucun de vos systèmes ne validera réellement le audjeton, alors il est inutile.

Exemple: jetons d'accès et de rafraîchissement

Un exemple artificiel (mais simple) auquel je peux penser est peut-être que nous voulons utiliser des JWT pour les jetons d'accès et d'actualisation sans avoir à implémenter des clés de chiffrement et des algorithmes séparés, mais que nous voulons simplement nous assurer que les jetons d'accès ne seront pas validés en tant que jetons d'actualisation, ou vice-versa. -versa.

En utilisant, audnous pouvons spécifier une revendication de refreshpour les jetons d'actualisation et une réclamation de accesspour 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 était un véritable jeton d'actualisation. La audvalidation décrite ci-dessus nous dira si le jeton était réellement un jeton d'actualisation valide en recherchant spécifiquement une revendication de refreshin aud.

ID client OAuth et audrevendication JWT

L'ID client OAuth est totalement indépendant et n'a aucune corrélation directe avec les audrevendications JWT . Du point de vue d'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 d'intérêt à spécifier l'ID client OAuth dans une audrevendication JWT .

Si vous êtes venu ici chercher OpenID Connect (OIDC): OAuth 2.0! = OIDC

Je reconnais que cela est étiqueté pour oauth 2.0 et PAS OIDC, cependant il y a fréquemment une confusion entre les 2 normes puisque les deux normes peuvent utiliser les JWT et la audrevendication. Et l'un (OIDC) est fondamentalement une extension de l'autre (OAUTH 2.0). (Je suis tombé sur cette question à la recherche d'OIDC moi-même.)

Jetons d'accès OAuth 2.0 ##

Pour les jetons d'accès OAuth 2.0 , les réponses existantes le couvrent assez bien. De plus, voici une section pertinente de OAuth 2.0 Framework (RFC 6749)

Pour les clients publics utilisant des flux implicites, cette spécification ne fournit aucune méthode permettant au client de déterminer à quel client un jeton d'accès a été émis.
... L'
authentification des propriétaires de ressources auprès des clients est hors de portée de cette spécification. Toute spécification qui utilise le processus d'autorisation comme forme d'authentification déléguée de l'utilisateur final au client (par exemple, service de connexion tiers) NE DOIT PAS utiliser le flux implicite sans mécanismes de sécurité supplémentaires qui permettraient au client de déterminer si l'accès le jeton a été émis pour son utilisation (par exemple, restreindre l'audience du jeton d'accès).

Jetons d'identification OIDC ##

OIDC a des jetons d'identification en plus des jetons d'accès. La spécification OIDC est explicite sur l'utilisation de la audrevendication dans les jetons d'identification. ( openid-connect-core-1.0 )

aud
REQUIS. Public (s) auquel ce jeton d'identification est destiné. Il DOIT contenir le client_id OAuth 2.0 de la partie utilisatrice comme valeur d'audience. Il PEUT également contenir des identifiants pour d'autres publics. Dans le cas général, la valeur aud est un tableau de chaînes sensibles à la casse. Dans le cas particulier courant lorsqu'il y a un seul public, la valeur aud PEUT être une seule chaîne sensible à la casse.

en outre, OIDC spécifie la azprevendication qui est utilisée en conjonction avec audquand auda plus d'une valeur.

azp
FACULTATIF. Partie autorisée - la partie à laquelle le jeton d'identité a été émis. S'il est présent, il DOIT contenir l'ID client OAuth 2.0 de cette partie. Cette revendication n'est nécessaire que lorsque le jeton d'identification a une seule valeur d'audience et que cette audience est différente de la partie autorisée. Il PEUT être inclus même lorsque la partie autorisée est la même que le seul public. La valeur azp est une chaîne sensible à la casse contenant une valeur StringOrURI.

Bien que ce soit vieux, je pense que la question est valable même aujourd'hui

Je soupçonne qu'aud devrait faire référence au (x) serveur (s) de ressources et que client_id devrait faire référence à l'une des applications clientes reconnues par le serveur d'authentification

Oui, aud doit faire référence à la partie consommatrice de jetons. Et client_id fait référence à la partie obtenant le jeton.

Dans mon cas actuel, mon serveur de ressources est également mon client d'application Web.

Dans le scénario du PO, l'application Web et le serveur de ressources appartiennent tous deux à la même partie. Cela signifie donc que le client et le public doivent être identiques. Mais il peut y avoir des situations où ce n'est pas le cas.

Pensez à un SPA qui consomme une ressource protégée OAuth. Dans ce scénario, SPA est le client. La ressource protégée est l'audience du jeton d'accès.

Ce deuxième scénario est intéressant. Il existe un projet de travail en place intitulé « Indicateurs de ressources pour OAuth 2.0 » qui explique où vous pouvez définir le public visé dans votre demande d'autorisation. Ainsi, le jeton résultant sera limité au public spécifié. En outre, Azure OIDC utilise une approche similaire dans laquelle il autorise l'inscription des ressources et autorise la demande d'authentification à contenir le paramètre de ressource pour définir le public cible du jeton d'accès. De tels mécanismes permettent aux adpotations OAuth d'avoir une séparation entre le client et la partie (audience) consommatrice de jetons.