La normalisation de la signature JSON, appelée JSON Web Signature, a été lancée par le groupe de travail JOSE de l'IETF [1].
Le projet initial
Mon nom est mentionné parce que j'ai apporté à l'IETF quelque chose qui était examiné par le groupe de travail AB/C de la Fondation OpenID [2].
@ritou a dit : «Qu'est-ce qu'une requête signée à l'ère OAuth 2.0 ?», mais sur Facebook demande_signée très semblable à
La grande différence est que signé_request est
Signature du corps.
En revanche, dans JWS,
en-tête.body.signature
C’est devenu. Il y a une raison à cela.
Pourquoi « Header.Body.Signature » ?
Certains diront peut-être qu’il serait préférable de le rendre identique à celui du champion du monde, Facebook, mais il y a une raison logique pour laquelle il en est ainsi.
Pourquoi les en-têtes sont-ils séparés ?
Dans le cas de signé_request, le paramètre de signature est inclus dans le corps. Si vous souhaitez chiffrer le corps, vous ne pouvez pas adopter cette approche. En effet, même les paramètres de décryptage sont cryptés. Il est donc nécessaire de séparer ces paramètres liés au chiffrement dans la section d’en-tête.
Nous essayons de rendre JWS et JWE aussi communs que possible. J'ai donc dû séparer les en-têtes.
Pourquoi la signature est-elle à la fin ?
Une autre grande différence visuelle est que dans signé_request, la signature est en premier, alors que dans JWS, la signature est en dernier. JWS place la signature à la fin pour diffuser la création de la signature. En effet, si vous essayez d'abord d'ajouter une signature, vous devez mettre en mémoire tampon toutes les données jusqu'à ce que le processus de signature soit terminé, puis l'envoyer comme "Signature.Body". Si vous faites cela, vous pouvez en envoyer de plus en plus. données, il n'est donc pas nécessaire de mettre toutes les données en mémoire tampon, et c'est « facile » sur les ressources du serveur. Il n'y a pas de grande différence si vous ne signez qu'un petit morceau de données comme signé_request, mais JWS peut également signer une énorme quantité de données, cette considération est donc prise en compte.
caractéristiques communes
singed_request, JWS ont également des caractéristiques communes. Les typiques sont
- Pas de normalisation des données
- Utiliser base64url pour la sérialisation
- Utiliser JSON comme format de données
- Toutes les données peuvent être signées
Pas de normalisation des données
Il existe une norme appelée XML Digital Signature. Très polyvalent et flexible. Cependant, de nombreux développeurs l'ont détesté en raison de son manque de compatibilité entre les différentes implémentations. La principale raison semble être la normalisation des données XML. Ni signé_request ni JWS ne font de canonisation pour éviter ce problème. Utilisez les données originales telles quelles.
Utiliser base64url pour la sérialisation
On me demande souvent pourquoi j'utilise base64url au lieu de base64. La réponse est que base64 contient des caractères qui ne sont pas Web Safe, tels que « = ». JWS peut être placé dans les en-têtes HTTP ou dans les paramètres GET et POST. Il est préférable de ne pas utiliser de remplissage avec "=" plutôt que d'échapper "=" à chaque fois.
Utiliser JSON comme format de données
La raison pour laquelle JSON est utilisé à la place de XML est que JSON est plus compact, offre de meilleures performances de traitement et, surtout, est populaire parmi les développeurs.
Toutes les données peuvent être signées
Bien qu'il s'agisse d'une méthode de signature JSON, vous pouvez signer n'importe quelle donnée en entrant simplement des données codées en base64url comme l'un des paramètres JSON.
Qui utilise JWS ?
J'espère que vous comprenez pourquoi il y a une telle différence. Cependant, vous vous demandez peut-être : « Si je n'utilise pas Facebook, à quoi ça sert ? » Je voudrais répondre à cette question comme suit.
Tout d’abord, ce n’est pas comme si Facebook avait décidé de ne pas l’utiliser. Ils sont satisfaits de la wanted_request actuelle et ne ressentent tout simplement pas le besoin d'utiliser JWS à cette fin. Il peut être utilisé à d’autres fins. De plus, si JWS devient plus courant à long terme, Facebook pourrait peut-être fournir un support supplémentaire car il est plus « convivial pour les développeurs » ?
De plus, même si Facebook ne l'utilise pas, de nombreux acteurs devraient l'utiliser. Actuellement, il s'agit notamment de Microsoft, Google, Salesforce, AOL et eBay.
Quand dois-je répondre ?
Je pense que JWS est relativement sophistiqué. En fait, des entreprises comme Google et eBay l’ont mis en œuvre. Donc, je pense que vous pouvez commencer à suivre maintenant, à condition que certains changements ne vous dérangent pas.[3] Si vous avez des besoins en matière de signature, pensez à utiliser JWS.
[1] Dans le même temps, une norme de chiffrement appelée JSON Web Encryption a vu le jour.
[2] Nous avons décidé de le normaliser à l'IETF car il peut être utilisé non seulement pour les normes d'identité telles qu'OpenID Connect, mais également à des fins générales. JSON Web Token et Simple Web Discovery sont également des spécifications introduites de la même manière.
[3] Pendant ce temps, JWE est sur le point de subir une intervention chirurgicale mineure. Plus précisément, le contrôle d'intégrité DOIT être ajouté lors de l'utilisation du mode CBC. Donc jusqu'à la prochaine version
Je me demande s'il est déraisonnable d'appliquer la normalisation à la représentation de données semi-structurées. Je voulais prendre un hachage et le normaliser pour comparer rapidement les correspondances et les écarts entre les objets JSON, mais...