Learn-json-web-tokens: Por que o "uso único" poderia resolver o MITM?

@ 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.