812 VISTAS
Pinterest LinkedIn LINHA

A padronização para assinatura JSON, chamada JSON Web Signature, foi iniciada pelo Grupo de Trabalho JOSE da IETF [1].

O rascunho inicial

で す.

Meu nome é mencionado porque trouxe algo que estava sendo considerado pelo Grupo de Trabalho AB/C da OpenID Foundation para a IETF [2].

@ritou disse: “O que é uma solicitação assinada na era OAuth 2.0?”, mas no Facebook solicitação_assinada muito parecido com

A grande diferença é que Signed_request é

Assinatura.

Em contraste, no JWS,

cabeçalho.corpo.assinatura

Tornou-se. Há uma razão para isso.

Por que “Cabeçalho.Body.Signature”?

Alguns podem argumentar que seria melhor torná-lo igual ao campeão mundial, o Facebook, mas há uma razão lógica para que tenha se tornado assim.

Por que os cabeçalhos estão separados?

No caso de assinado_request, o parâmetro de assinatura está incluído no corpo. Se você deseja criptografar o corpo, não pode adotar essa abordagem. Isso ocorre porque até os parâmetros de descriptografia são criptografados. Portanto, é necessário separar esses parâmetros relacionados à criptografia na seção do cabeçalho.

Estamos tentando tornar o JWS e o JWE o mais comuns possível. Então eu tive que separar os cabeçalhos.

Por que a assinatura está no final?

Outra grande diferença visual é que em Signed_request a assinatura é a primeira, enquanto no JWS a assinatura é a última. JWS coloca a assinatura no final para transmitir a criação da assinatura. Isso significa que se você tentar adicionar uma assinatura primeiro, todos os dados deverão ser armazenados em buffer até que o processo de assinatura seja concluído e, em seguida, enviados como "signature.body", enquanto o título será adicionado no final. você pode enviar mais e mais dados, portanto não há necessidade de armazenar todos os dados em buffer e isso é "fácil" nos recursos do servidor. Não há grande diferença se você assinar apenas um pequeno pedaço de dados como assinado_request, mas o JWS também pode assinar uma grande quantidade de dados, portanto, essa consideração é levada em consideração.

características comuns

singed_request, JWS também possuem algumas características comuns. Os típicos são

  • Sem normalização de dados
  • Use base64url para serialização
  • Use JSON como formato de dados
  • Quaisquer dados podem ser assinados

Sem normalização de dados

Existe um padrão chamado Assinatura Digital XML. Muito versátil e flexível. No entanto, muitos desenvolvedores não gostaram dele devido à falta de compatibilidade entre diferentes implementações. O maior motivo parece ser a normalização dos dados XML. Nem Signed_request nem JWS fazem qualquer canonização para evitar esse problema. Use os dados originais como estão.

Use base64url para serialização

Muitas vezes me perguntam por que uso base64url em vez de base64. A resposta é que base64 contém caracteres que não são seguros para a Web, como “=”. JWS pode ser colocado em cabeçalhos HTTP ou em parâmetros GET e POST. Em vez de escapar de cada ``=", é melhor não usar o preenchimento ``=".

Use JSON como formato de dados

A razão pela qual JSON é usado em vez de XML é que JSON é mais compacto, tem melhor desempenho de processamento e, acima de tudo, é popular entre os desenvolvedores.

Quaisquer dados podem ser assinados

Embora este seja um método para assinar JSON, você pode assinar qualquer dado simplesmente inserindo dados codificados em base64url como um dos parâmetros JSON.

Quem usa JWS?

Espero que você entenda por que existe essa diferença. No entanto, você pode estar pensando: “Se eu não usar o Facebook, qual é o sentido?” Eu gostaria de responder a isso da seguinte maneira.

Em primeiro lugar, não é como se o Facebook tivesse decidido não usá-lo. Eles estão satisfeitos com o assinado_request atual e simplesmente não sentem necessidade de usar JWS para esse propósito. Pode ser usado para outros fins. Além disso, se o JWS se tornar mais comum no longo prazo, talvez o Facebook possa fornecer suporte adicional, pois é mais “amigável ao desenvolvedor”?

Além disso, mesmo que o Facebook não o utilize, espera-se que muitos jogadores o utilizem. Atualmente, estes incluem Microsoft, Google, Salesforce, AOL e eBay.

Quando devo responder?

Acho que o JWS é relativamente sofisticado. Na verdade, empresas como Google e eBay o implementaram. Então acho que você pode começar a acompanhar agora, desde que não se importe com algumas mudanças.[3] Se você tiver alguma necessidade de assinatura, considere usar JWS.

[1] Ao mesmo tempo, um padrão de criptografia chamado JSON Web Encryption foi iniciado.

[2] Decidimos padronizá-lo na IETF porque ele pode ser usado não apenas para padrões de identidade como OpenID Connect, mas também para fins gerais. JSON Web Token e Simple Web Discovery também são especificações introduzidas da mesma forma.

[3] Enquanto isso, JWE está prestes a passar por uma pequena cirurgia. Especificamente, a verificação de integridade DEVE ser adicionada ao usar o modo CBC. Então, até o próximo rascunho