Qual é a vantagem de usar JWTs em vez de sessões em situações como autenticação?
É usado como uma abordagem independente ou é usado na sessão?
Qual é a vantagem de usar JWTs em vez de sessões em situações como autenticação?
É usado como uma abordagem independente ou é usado na sessão?
Respostas:
O JWT não tem uma vantagem sobre o uso de "sessões" por dizer. Os JWTs fornecem um meio de manter o estado da sessão no cliente em vez de fazê-lo no servidor.
O que as pessoas geralmente querem dizer quando perguntam isso é "Quais são os benefícios de usar JWTs em vez de sessões do lado do servidor "
Com as sessões do lado do servidor, você terá que armazenar o identificador da sessão em um banco de dados ou mantê-lo na memória e certificar-se de que o cliente sempre acesse o mesmo servidor. Ambos têm desvantagens. No caso do banco de dados (ou outro armazenamento centralizado), isso se torna um gargalo e algo a ser mantido - essencialmente uma consulta extra a ser feita a cada solicitação.
Com uma solução in-memory, você limita sua escala horizontal, e as sessões serão afetadas por problemas de rede (clientes em roaming entre Wifi e dados móveis, reinicialização de servidores, etc)
Mover a sessão para o cliente significa remover a dependência de uma sessão do lado do servidor, mas impõe seu próprio conjunto de desafios.
Esses problemas são compartilhados por JWTs e outros mecanismos de sessão do lado do cliente.
O JWT em particular aborda o último deles. Pode ajudar a entender o que é um JWT:
É um pouco de informação. Para sessões de usuário, você pode incluir o nome de usuário e a hora em que o token expira. Mas pode ser qualquer coisa, até mesmo o ID da sessão ou o perfil completo do usuário. (No entanto, não faça isso) Ele tem uma assinatura segura que impede que partes mal-intencionadas gerem tokens falsos (você precisa acessar a chave privada do servidor para assiná-los e pode verificar se eles não foram modificados após serem assinados) Você envie-os com cada solicitação, assim como um cookie ou Authorizationcabeçalho seria enviado. Na verdade, eles são normalmente enviados no Authorizationcabeçalho HTTP, mas usar um cookie também é bom.
O token é assinado e, portanto, o servidor pode verificar sua origem. Assumiremos que o servidor confia em sua própria capacidade de assinar com segurança (você deve usar uma biblioteca padrão: não tente fazer isso sozinho e proteja o servidor adequadamente)
Sobre o problema de transporte seguro do token, a resposta geralmente é enviá-lo por meio de um canal criptografado, geralmente httpS.
Com relação ao armazenamento seguro do token no cliente, você precisa garantir que os bandidos não consigam acessá-lo. Isso (principalmente) significa evitar que o JS de sites ruins leiam o token e o envie de volta. Isso é atenuado usando as mesmas estratégias usadas para atenuar outros tipos de ataques XSS.
Se você precisar invalidar JWTs, definitivamente há maneiras de fazer isso. Armazenar um período por usuário apenas para usuários que solicitaram o encerramento de suas "outras sessões" é um método muito eficiente que provavelmente será bom o suficiente. Se um aplicativo precisa de invalidação por sessão, um ID de sessão pode ser mantido da mesma maneira e a tabela de "tokens eliminados" ainda pode ser mantida para ser muito menor do que a tabela de usuário completa (você só precisa reter registros mais recentes que o mais longa vida útil permitida do token.) Portanto, a capacidade de invalidar o token nega parcialmente o benefício das sessões do lado do cliente, pois você teria que manter esse estado de sessão encerrada. É mais do que provável que esta seja uma tabela muito menor do que a tabela de estado de sessão original, portanto, as pesquisas são ainda mais eficientes.
Um outro benefício de usar tokens JWT é que é razoavelmente fácil de implementar usando bibliotecas disponíveis em provavelmente todas as linguagens que você pode esperar ter. Ele também é completamente divorciado de seu esquema inicial de autenticação do usuário - se você mudar para um sistema baseado em impressão digital, não precisará fazer nenhuma alteração no esquema de gerenciamento de sessão.
Um benefício mais sutil: como o JWT pode transportar "informações" e isso pode ser acessado pelo cliente, você agora pode começar a fazer algumas coisas inteligentes. Por exemplo, lembre o usuário de que sua sessão irá expirar alguns dias antes de ele ser desconectado, dando a ele a opção de reautenticar, com base na data de expiração do token. O que você pode imaginar.
Resumindo: os JWTs respondem a algumas das perguntas e deficiências de outras técnicas de sessão.
Embora os JWTs não respondam a outros problemas, como armazenamento ou transporte seguro, eles não apresentam novos problemas de segurança.
Existe muita negatividade em torno dos JWTs, mas se você implementar a mesma segurança que faria para outros tipos de autenticação, não terá problemas.
Uma nota final: também não é Cookies vs Tokens. Os cookies são um mecanismo para armazenar e transportar bits de informação e também podem ser usados para armazenar e transportar tokens JWT.
A resposta curta é: Nenhum.
Uma versão mais longa é:
Implementei JWTs para gerenciamento de sessão depois de ler esta recomendação nos documentos do GraphQL :
Se você não estiver familiarizado com nenhum desses mecanismos de autenticação, recomendamos o uso de express-jwt porque é simples, sem sacrificar qualquer flexibilidade futura.
A implementação foi realmente simples, pois apenas acrescentou um pouco de complexidade. Depois de um tempo, no entanto, eu (como você) comecei a me perguntar quais eram os benefícios. Acontece que há muito poucos (ou possivelmente nenhum) para o JWT no que diz respeito ao gerenciamento de sessão, como esta postagem do blog explica em detalhes:
Meus dois centavos, que no caminho adicionam algum contraste à famosa postagem do blog de joepie91.
Considerando que os aplicativos de hoje (e de amanhã) são (em sua maioria) nativos da nuvem
Há um benefício econômico para a Autenticação JWT sem estado , que é escalonada conforme o aplicativo é dimensionado: os
aplicativos em nuvem geram custos junto com cada respiração .
Esse custo é reduzido quando os usuários não precisam mais se autenticar "em" um armazenamento de sessão.
Processamento
Administrar uma sessão de armazenamento 24 horas por dia, 7 dias por semana, custa dinheiro.
Você não pode fugir com soluções baseadas em memória no mundo do K8S, pois os pods são efêmeros.
Sessões pegajosas não vão bem pelo mesmo motivo.
Armazenamento O
armazenamento de dados custa dinheiro. armazenar dados em um SSD custa ainda mais.
As operações relacionadas à sessão precisam ser resolvidas rapidamente, portanto, uma unidade óptica não é uma opção.
E / S
Alguns provedores de nuvem cobram dinheiro para E / S relacionadas a discos.
Largura de banda
Alguns provedores de nuvem cobram pela atividade de rede entre as instâncias do servidor.
Isso se aplica já que é quase certo que a API e o armazenamento de sessão são instâncias separadas.
Agrupando o armazenamento de sessão
O custo aumenta ainda mais todos os custos mencionados acima.
Eu tive uma pergunta semelhante ao escolher entre JWT e token + cache para autenticação do usuário.
Depois de ler esses artigos, ficou claro para mim que os benefícios que o JWT promete não superam os problemas que ele traz. Portanto, token + cache (Redis / Memcached) é o caminho a percorrer para mim.