Solucionado (ver solução)
Solucionado
(ver solução)
2
respostas

Uso da senha no signwith

Olá.

O signwith utiliza o algoritmo de criptografia e a senha que coloquei no aplication.properties. Essa senha é como se fosse um "seed" para a geração do meu token?

"Preciso dizer para ele quem é o algoritmo de criptografia e a senha da minha aplicação, que é usada para fazer a assinatura e gerar o HASH da criptografia do token."

O que quer dizer com fazer a assinatura do token no trecho acima?

Obrigado.

2 respostas

Consegui entender o funcionamento dessa senha, ela faz parte da assinatura. O JWT é dividido em três partes:

-cabeçalho

-payload

-assinatura

A assinatura é gerada com o meu algoritmo de criptografia e com a chave. Ela serve para validar o meu token por inteiro, verificar se ele é válido.

Essas três partes de unem e formam o token.

A única coisa que não ficou muito clara é em relação ao meu payload. As informações que estou passando no builder, com o setIssuer, setSubject, setIssuedAt, SetExpiration, são todas relacionadas ao payload?

Obrigado.

solução!

Olá Eduardo.

Sim, todas essas informações são claims do payload.

A segunda parte do token é o payload, que contém as claims. As claims são declarações sobre uma entidade (normalmente, o usuário) e dados adicionais. Existem três tipos de reivindicações: registradas , públicas e privadas .

Declarações registradas : trata-se de um conjunto de declarações predefinidas que não são obrigatórias, mas recomendadas, para fornecer um conjunto de declarações úteis e interoperáveis. Alguns deles são: iss (emissor), exp (prazo de validade), sub (assunto), aud (público) e outros .

Observe que os nomes das declarações têm apenas três caracteres, pois o JWT deve ser compacto.

Reivindicações públicas : podem ser definidas à vontade por aqueles que usam JWTs. Mas, para evitar colisões, eles devem ser definidos no IANA JSON Web Token Registry ou como um URI que contém um namespace resistente a colisões.

Reivindicações privadas : são as reivindicações personalizadas criadas para compartilhar informações entre as partes que concordam em usá-las e não sãoreivindicações registradas ou públicas .

Um exemplo de payload poderia ser:

{
  "sub": "1234567890",
  "name": "John Doe",
  "admin": true
}

O payload é então codificada em Base64 para formar a segunda parte do JSON Web Token.

Observe que, para tokens assinados, essas informações, embora protegidas contra adulteração, podem ser lidas por qualquer pessoa. Não coloque informações secretas no payload ou nos elementos do cabeçalho de um JWT, a menos que esteja criptografado.

Quer mergulhar em tecnologia e aprendizagem?

Receba a newsletter que o nosso CEO escreve pessoalmente, com insights do mercado de trabalho, ciência e desenvolvimento de software