OAuth2: Quelle est la différence entre le droit d'autorisation JWT et le droit d'accès client avec authentification client JWT?
Le profil JA OAuth2 introduit la possibilité d'utiliser les JWT à la fois comme octroi d'autorisation et comme authentification client.
La fonction d'authentification du client JWT est indépendante d'un certain type de subvention et peut être utilisée avec n'importe quel type de subvention, également la subvention des informations d'identification du client.
Cependant, l'utilisation du type d'autorisation JWT semble faire exactement la même chose que l'utilisation de l'attribution des informations d'identification client avec l'authentification client JWT, sauf que la syntaxe est légèrement différente.
Dans les deux cas, le client contacte le point de terminaison du jeton pour obtenir un jeton d'accès:
POST /token.oauth2 HTTP/1.1
Host: as.example.com
Content-Type: application/x-www-form-urlencoded
grant_type=urn%3Aietf%3Aparams%3Aoauth%3Agrant-type%3Ajwt-bearer&assertion=[JWT]
contre
POST /token.oauth2 HTTP/1.1
Host: as.example.com
Content-Type: application/x-www-form-urlencoded
grant_type=client_credentials&client_assertion_type=urn%3Aietf%3Aparams%3Aoauth%3Aclient-assertion-type%3Ajwt-bearer&client_assertion=[JWT]
Une perspective légèrement différente sur la grande réponse de Josh C: car il se produit à la fois l'authentification du client et les informations d'identification de la subvention peuvent être exprimées en JWT mais la sémantique derrière elles est différente.
Il s'agit de séparer les préoccupations: les clients s'authentifient avec des informations d'identification qui les identifient c'est-à-dire qu'ils sont les soi-disant subject alors qu'ils utilisent des subventions qui leur ont été délivrées c'est-à-dire que ce sont les soi-disant audience. Ou comme la version 12 du projet de spécification ( https://tools.ietf.org/html/draft-ietf-oauth-jwt-bearer-12 ) dit:
Le JWT DOIT contenir une revendication "sub" (sujet) identifiant le principal qui fait l'objet du JWT. Deux cas doivent être différenciés:
A. Pour l'octroi d'autorisation, le sujet identifie généralement un accesseur autorisé pour lequel le jeton d'accès est demandé (c'est-à-dire le propriétaire de la ressource ou un délégué autorisé), mais dans certains cas, il peut s'agir d'un identifiant pseudonyme ou d'une autre valeur désignant un anonyme utilisateur.
B. Pour l'authentification client, le sujet DOIT être le "client_id" du client OAuth.
Probablement très peu. La façon dont un client est identifié et la façon dont les autorisations d'authentification sont demandées sont deux notions différentes dans OAuth, donc les questions abordent ces notions séparément:
- Un client peut-il s'authentifier auprès d'un serveur d'autorisation à l'aide d'un JWT? Oui.
- Un client peut-il faire une demande de subvention en utilisant un JWT? Oui.
La spécification semble laisser entendre que la séparation est simplement une décision de conception, renvoyant aux décideurs politiques pour trouver quels scénarios leur sont précieux:
L'utilisation d'un jeton de sécurité pour l'authentification client est orthogonale et séparable de l'utilisation d'un jeton de sécurité comme octroi d'autorisation. Ils peuvent être utilisés en combinaison ou séparément. L'authentification du client à l'aide d'un JWT n'est rien d'autre qu'un moyen alternatif pour un client de s'authentifier auprès du point de terminaison du jeton et doit être utilisée en conjonction avec un type de subvention pour former une demande de protocole complète et significative. Les octrois d'autorisation JWT peuvent être utilisés avec ou sans authentification ou identification du client. La question de savoir si l'authentification client est nécessaire ou non conjointement avec une autorisation d'autorisation JWT, ainsi que les types d'authentification client pris en charge, sont des décisions de politique à la discrétion du serveur d'autorisation.
Une possibilité concrète: la séparation pourrait permettre à un serveur d'autorisation de configurer différentes politiques le long des types de clients. Par exemple, dans le cas d'un client public (comme une application mobile), le serveur ne doit pas accepter le type d'octroi de crédits client. Au lieu de cela, le serveur peut accepter le type d'accord JWT pour les clients publics et émettre un jeton de privilège moindre.
En dehors de cela, je suppose que la conception offre simplement un degré de liberté aux clients et aux serveurs pour pivoter - garder cette partie de la poignée de main existante la même lors de la migration de cette partie - selon les besoins.