(gerado a partir deste tópico, pois esta é realmente uma questão própria e não específica do NodeJS etc)
Estou implementando um servidor REST API com autenticação e implementei com êxito o manuseio de tokens JWT para que um usuário possa fazer login por meio de um ponto de extremidade / login com nome de usuário / senha, no qual um token JWT é gerado a partir de um segredo de servidor e retornado ao cliente. O token é então passado do cliente para o servidor em cada solicitação de API autenticada, na qual o segredo do servidor é usado para verificar o token.
No entanto, estou tentando entender as melhores práticas para saber exatamente como e em que medida o token deve ser validado, para fazer um sistema verdadeiramente seguro. O que exatamente deve estar envolvido na "validação" do token? É suficiente que a assinatura possa ser verificada usando o segredo do servidor ou devo também verificar o token e / ou carga útil do token em relação a alguns dados armazenados no servidor?
Um sistema de autenticação baseado em token só será tão seguro quanto passar nome de usuário / senha em cada solicitação, desde que seja tão ou mais difícil obter um token do que obter a senha de um usuário. No entanto, nos exemplos que vi, as únicas informações necessárias para produzir um token são o nome de usuário e o segredo do servidor. Isso não significa que, supondo por um minuto que um usuário malicioso obtenha conhecimento do segredo do servidor, ele agora pode produzir tokens em nome de qualquer usuário, tendo assim acesso não apenas a um determinado usuário, como aconteceria se uma senha fosse obtido, mas na verdade para todas as contas de usuário?
Isso me leva às perguntas:
1) A validação do token JWT deve se limitar a verificar a assinatura do próprio token, contando apenas com a integridade do segredo do servidor ou acompanhada por um mecanismo de validação separado?
Em alguns casos, tenho visto o uso combinado de tokens e sessões de servidor em que, após o login bem-sucedido por meio do endpoint / login, uma sessão é estabelecida. As solicitações de API validam o token e também comparam os dados decodificados encontrados no token com alguns dados armazenados na sessão. No entanto, usar sessões significa usar cookies e, de certa forma, isso vai contra o propósito de usar uma abordagem baseada em tokens. Também pode causar problemas para alguns clientes.
Pode-se imaginar o servidor mantendo todos os tokens atualmente em uso em um memcache ou semelhante, para garantir que, mesmo que o segredo do servidor seja comprometido para que um invasor possa produzir tokens "válidos", apenas os tokens exatos que foram gerados por meio do endpoint / login seria aceito. Isso é razoável ou apenas redundante / exagero?
2) Se a verificação da assinatura JWT for o único meio de validar tokens, ou seja, a integridade do segredo do servidor é o ponto de quebra, como os segredos do servidor devem ser gerenciados? Ler a partir de uma variável de ambiente e criar (aleatoriamente?) Uma vez por pilha implantada? Renovado ou girado periodicamente (e se sim, como lidar com tokens válidos existentes que foram criados antes da rotação, mas precisam ser validados após a rotação, talvez seja o suficiente se o servidor mantiver o segredo atual e o anterior a qualquer momento) ? Algo mais?
Talvez eu esteja simplesmente sendo paranóico demais quando se trata do risco de o segredo do servidor ser comprometido, o que é, obviamente, um problema mais geral que precisa ser resolvido em todas as situações criptográficas ...
RSAPrivateKey privateKey
??