A seção sobre MITM (Man-in-the-MiddleAttack) diz que "usar tokens de uso único (uso único) (que expiram depois que o link foi clicado)" é uma solução do MITM.
Minha dúvida é que se o token usar apenas uma vez, fará com que o usuário precise fazer login novamente após cada vez que a solicitação for enviada. Por outro lado, se o servidor destruir o token e retornar o novo token a cada vez, o novo token ainda pode ser interceptado pelo intermediário.
Se eu estiver errado, por favor me avise, obrigado!
@ NE-SmallTown boa pergunta.
Usar tokens de uso único é uma boa prática para a segurança do aplicativo.
Se quiser usar esse padrão, você pode configurar um gancho onPreResponse
que atualiza automaticamente o JWT para cada resposta.
a pergunta que você deve responder é: como você está planejando garantir que um token _não_ seja reutilizado?
você precisaria armazenar o identificador em algum tipo de banco de dados (_nós normalmente usamos redis
para isso em nossos aplicativos_) e verificar se o token já foi usado.
@nelsonic Obrigado pela sua resposta. Estou um pouco confuso.
Há uma pergunta.
Como você disse, o processo é:
o usuário acessa a página inicial e envia o token no cabeçalho (supondo que ele tenha feito login)
|
|
↓
servidor recebe o token e, em seguida, obtém o userId
decodificando o token e, em seguida, vai para o banco de dados (assumindo que eu uso o banco de dados em vez de redis
) para pegar o token correspondente de userId
e, em seguida, verifique se eles são iguais usando ==
operator. Se for, destrua o token e gere um novo token e envie-o para o banco de dados e responda com os dados ao cliente.
Há uma pergunta, nós apenas usamos o operador ==
para verificar, mas sabemos que o token em si tem o mecanismo vertify, não o usamos ? Ex:
JWT.require(Algorithm.RSA256((RSAKey) publicKey))
.withIssuer("auth")
.withSubject("ne-smalltown")
.withAudience(userId)
.withArrayClaim("jwt-role", userRole)
.build()
Se eu estiver errado, você poderia me dizer como e onde usar o mecanismo de verificação do token como acima?
IMO, o único lugar em que posso usar o próprio mecanismo de verificação do token é onde obtenho o parâmetro exp do token antigo e o coloco no novo token para que eu possa verificar se o token está desatualizado para fazer o usuário relogin.
|
|
↓
O cliente recebe o novo token e envia-o para localstorage
para substituir o token antigo. E na próxima solicitação, ele o usará.
@nelsonic Hello?
@ NE-SmallTown minhas desculpas por não responder imediatamente.
A especificação JWT não tem uma reivindicação / mecanismo para invalidação de uso único
consulte: http://self-issued.info/docs/draft-ietf-oauth-json-web-token.html#RegisteredClaimName
@jbspeakr tem uma postagem sobre como usar JWTs de uso único,
consulte: https://www.jbspeakr.cc/howto-single-use-jwt/
@nelsonic Obrigado por compartilhar o post.
A postagem diz:
Em teoria, isso também funciona com casos de uso além de tokens de redefinição de senha, por exemplo, ativação de e-mail, confirmação de conta
Concordo que esses casos são adequados para jwt de uso único, mas meu caso é o jwt incluir as informações da função constante , não gosta de redefinição de senha, ativação de email, confirmação de conta, etc.
Então, voltando à questão, no meu caso, agora acho que não é necessário vertificar o token, basta usar o operador == com o token do banco de dados.
Comentários muito úteis
@ NE-SmallTown minhas desculpas por não responder imediatamente.
A especificação JWT não tem uma reivindicação / mecanismo para invalidação de uso único
consulte: http://self-issued.info/docs/draft-ietf-oauth-json-web-token.html#RegisteredClaimName
@jbspeakr tem uma postagem sobre como usar JWTs de uso único,
consulte: https://www.jbspeakr.cc/howto-single-use-jwt/