4. Revendications JSON Web Token et paramètres de réponse d'introspection

Il est utile d'avoir des mécanismes définis pour exprimer la délégation au sein d'un jeton ainsi que pour exprimer l'autorisation de déléguer ou d'usurper l'identité. Bien que le protocole d'échange de jetons décrit ici puisse être utilisé avec n'importe quel type de jeton, cette section définit des revendications pour exprimer une telle sémantique spécifiquement pour les JWT et dans une réponse d'introspection de jeton OAuth 2.0 [RFC7662]. Des définitions similaires pour d'autres types de jetons sont possibles mais dépassent le cadre de cette spécification.

Notez que les revendications non établies ici mais utilisées dans les exemples et les descriptions, telles que "iss", "sub", "exp", etc., sont définies par [JWT].

4.1. Revendication "act" (Actor)

La revendication "act" (acteur) fournit un moyen au sein d'un JWT d'exprimer qu'une délégation a eu lieu et d'identifier la partie agissante à laquelle l'autorité a été déléguée. La valeur de la revendication "act" est un objet JSON, et les membres de l'objet JSON sont des revendications qui identifient l'acteur. Les revendications qui composent la revendication "act" identifient et fournissent éventuellement des informations supplémentaires sur l'acteur. Par exemple, la combinaison des deux revendications "iss" et "sub" pourrait être nécessaire pour identifier de manière unique un acteur.

Cependant, les revendications au sein de la revendication "act" concernent uniquement l'identité de l'acteur et ne sont pas pertinentes pour la validité du JWT contenant de la même manière que les revendications de niveau supérieur. Par conséquent, les revendications de non-identité (par exemple, "exp", "nbf" et "aud") n'ont pas de sens lorsqu'elles sont utilisées dans une revendication "act" et ne sont donc pas utilisées.

La Figure 5 illustre la revendication "act" (acteur) dans un ensemble de revendications JWT. Les revendications du jeton lui-même concernent [email protected] tandis que la revendication "act" indique que [email protected] est l'acteur actuel.

{
  "aud":"https://consumer.example.com",
  "iss":"https://issuer.example.com",
  "exp":1443904177,
  "nbf":1443904077,
  "sub":"[email protected]",
  "act":
  {
    "sub":"[email protected]"
  }
}

Figure 5 : Revendication Actor

Une chaîne de délégation peut être exprimée en imbriquant une revendication "act" dans une autre. La revendication "act" la plus externe représente l'acteur actuel tandis que les revendications "act" imbriquées représentent les acteurs précédents. L'acteur le moins récent est le plus profondément imbriqué. Les revendications "act" imbriquées servent de piste historique qui relie la demande initiale et le sujet à travers les différentes étapes de délégation entreprises avant d'atteindre l'acteur actuel. En ce sens, l'acteur actuel est considéré comme incluant tout l'historique d'autorisation/délégation, conduisant naturellement à la structure imbriquée décrite ici.

Dans le but d'appliquer la politique de contrôle d'accès, le consommateur d'un jeton NE DOIT considérer que les revendications de niveau supérieur du jeton et la partie identifiée comme l'acteur actuel par la revendication "act". Les acteurs précédents identifiés par toute revendication "act" imbriquée sont uniquement informatifs et ne doivent pas être pris en compte dans les décisions de contrôle d'accès.

L'exemple suivant de la Figure 6 illustre les revendications "act" (acteur) imbriquées dans un ensemble de revendications JWT. Les revendications du jeton lui-même concernent [email protected] tandis que la revendication "act" indique que le système <https://service16.example.com> est l'acteur actuel et <https://service77.example.com> était un acteur précédent. Un tel jeton pourrait résulter de la réception par service16 d'un jeton dans un appel de service77 et de son échange contre un jeton approprié pour appeler service26 pendant que le serveur d'autorisation note la situation dans le jeton nouvellement émis.

{
  "aud":"https://service26.example.com",
  "iss":"https://issuer.example.com",
  "exp":1443904100,
  "nbf":1443904000,
  "sub":"[email protected]",
  "act":
  {
    "sub":"https://service16.example.com",
    "act":
    {
      "sub":"https://service77.example.com"
    }
  }
}

Figure 6 : Revendication Actor imbriquée

Lorsqu'elle est incluse en tant que membre de niveau supérieur d'une réponse d'introspection de jeton OAuth, "act" a la même sémantique et le même format que la revendication du même nom.

4.2. Revendication "scope" (Scopes)

La valeur de la revendication "scope" est une chaîne JSON contenant une liste de portées séparées par des espaces associées au jeton, dans le format décrit dans la section 3.3 de la [RFC6749].

La Figure 7 illustre la revendication "scope" dans un ensemble de revendications JWT.

{
  "aud":"https://consumer.example.com",
  "iss":"https://issuer.example.com",
  "exp":1443904177,
  "nbf":1443904077,
  "sub":"dgaf4mvfs75Fci_FL3heQA",
  "scope":"email profile phone address"
}

Figure 7 : Revendication Scopes

L'introspection de jeton OAuth 2.0 [RFC7662] définit déjà le paramètre "scope" pour transmettre les portées associées au jeton.

4.3. Revendication "client_id" (Client Identifier)

La revendication "client_id" transporte l'identifiant client du client OAuth 2.0 [RFC6749] qui a demandé le jeton.

L'exemple suivant de la Figure 8 illustre la revendication "client_id" dans un ensemble de revendications JWT indiquant un client OAuth 2.0 avec "s6BhdRkqt3" comme identifiant.

{
  "aud":"https://consumer.example.com",
  "iss":"https://issuer.example.com",
  "exp":1443904177,
  "sub":"[email protected]",
  "client_id":"s6BhdRkqt3"
}

Figure 8 : Revendication d'identifiant client

L'introspection de jeton OAuth 2.0 [RFC7662] définit déjà le paramètre "client_id" comme identifiant client pour le client OAuth 2.0 qui a demandé le jeton.

4.4. Revendication "may_act" (Authorized Actor)

La revendication "may_act" fait une déclaration selon laquelle une partie est autorisée à devenir l'acteur et à agir au nom d'une autre partie. La revendication peut être utilisée, par exemple, lorsqu'un "subject_token" est présenté au point de terminaison de jeton dans une demande d'échange de jeton et la revendication "may_act" dans le jeton sujet peut être utilisée par le serveur d'autorisation pour déterminer si le client (ou la partie identifiée dans le "actor_token") est autorisé à s'engager dans la délégation ou l'usurpation d'identité demandée.

La valeur de la revendication est un objet JSON, et les membres de l'objet JSON sont des revendications qui identifient la partie qui est déclarée comme étant éligible pour agir pour la partie identifiée par le JWT contenant la revendication. Les revendications qui composent la revendication "may_act" identifient et fournissent éventuellement des informations supplémentaires sur l'acteur autorisé. Par exemple, la combinaison des deux revendications "iss" et "sub" est parfois nécessaire pour identifier de manière unique un acteur autorisé, tandis que la revendication "email" peut être utilisée pour fournir des informations utiles supplémentaires sur cette partie.

Cependant, les revendications au sein de la revendication "may_act" concernent uniquement l'identité de cette partie et ne sont pas pertinentes pour la validité du JWT contenant de la même manière que les revendications de niveau supérieur. Par conséquent, des revendications telles que "exp", "nbf" et "aud" n'ont pas de sens lorsqu'elles sont utilisées dans une revendication "may_act" et ne sont donc pas utilisées.

La Figure 9 illustre la revendication "may_act" dans un ensemble de revendications JWT. Les revendications du jeton lui-même concernent [email protected] tandis que la revendication "may_act" indique que [email protected] est autorisé à agir au nom de [email protected].

{
  "aud":"https://consumer.example.com",
  "iss":"https://issuer.example.com",
  "exp":1443904177,
  "nbf":1443904077,
  "sub":"[email protected]",
  "may_act":
  {
    "sub":"[email protected]"
  }
}

Figure 9 : Revendication Authorized Actor

Lorsqu'elle est incluse en tant que membre de niveau supérieur d'une réponse d'introspection de jeton OAuth, "may_act" a la même sémantique et le même format que la revendication du même nom.