Learn-json-web-tokens: Informações perigosas e incorretas no README

Alguns muito bem pensados ​​e expressaram de forma articulada preocupações que certamente estão me dando o que pensar, como alguém que acabou de começar a olhar para o repo. Eu estava procurando um exemplo rápido para criar um exemplo de trabalho de autenticação JWT com o Node. Meu interesse no JWT é fornecer uma abordagem de prática recomendada moderna para gerenciamento de sessão para a API REST e o cliente js, evitando problemas de CORS. Estou ligeiramente interessado em segurança, mas esta não é minha motivação para usar o JWT, embora aprecie o papel que os tokens podem desempenhar em abordagens seguras mais abrangentes, como o OAUTH. Quando li este repo pela primeira vez, me pareceu que incluía muitas notas que o autor coletou enquanto estava construindo seu conhecimento sobre o uso do JWT, etc. Embora eu tenha pouco investimento neste repo, estou inclinado a acreditar que há um lugar para um exemplo de trabalho minimalista e específico de plataforma de login / logout com algumas ferramentas de suporte, referências. Como uma base para as habilidades de integração e como um iniciante, acho que os objetivos deste repo são bons, mas talvez o README precise ser reescrito seriamente e um novo foco nos objetivos desse tipo de uso de JWTs. Eu ficaria feliz em tentar sugerir algo .. joepie91 - você claramente tem uma boa compreensão dos problemas .. você poderia fornecer algumas idéias sobre quais são os reais benefícios desse tipo de uso dos JWTs?

Olá @ joepie91 , estamos _sperados_ que você encontrou e _ler_ nossas notas sobre o JWT!
obrigado por abrir esta questão para levantar suas preocupações. ❤️
Ficaríamos _satisfeitos_ se você dividisse cada uma de suas preocupações em uma questão _separada_ ou, pelo menos, numerasse-as para facilitar a discussão.

Nós _respeitosamente_ discordamos que o conteúdo dessas notas seja "_Perigoso_".

_Cookies _> no considerando 25 da diretiva de privacidade eletrônica da UE, cookies _são explicitamente mencionados _ 5 vezes:

Vejo:
https://en.wikipedia.org/wiki/Directive_on_Privacy_and_Electronic_Communications#Cookies
ou:
http :

Concedido, _muitos_ sites / aplicativos (_que não estão usando cookies de rastreamento de terceiros_) se enquadram na categoria ‘strictly necessary for the delivery of a service requested by the user’ ... razão pela qual _usamos_ cookies em nossos aplicativos da web _progressivamente aprimorados_. consulte: https://github.com/dwyl/hapi-auth-jwt2#want -to-sendstore-your-jwt-in-a-cookie

Armazenando JWT em _localStorage _> Embora _concordemos_ que armazenar dados / tokens de sessão em localStorage significa que JavaScript é _requirido _ (_nós também não gostamos disso, preferimos aprimoramento progressivo , o objetivo era observar uma opção alternativa ..._). localStorage é como _todos os _ aplicativos construídos com um "_Backend-as-a-Service_" são feitos, porque BaaS normalmente não aceita cookies ... Você está sugerindo que meio milhão de desenvolvedores que usam o Google Firebase são fazendo isto errado_"...? (_isto seria um ótimo - separado - discussão ...! _)

Sessões sem estado são _possíveis_ com JWTs porque têm uma opção embutida exp (_tempo de expiração_), no entanto, _escolhemos / prefer_ _não _ deixar nossas sessões sem estado em vez de optar por armazenar um id de sessão ( jti ) _dentro_ o JWT que é procurado em uma loja do Redis _após_ o JWT ter sido verificado. Isso significa que podemos _invalidar _ uma sessão quando uma pessoa se desconecta ou se seu dispositivo é roubado e ela precisa revogar uma sessão ativa.

Sim, o propósito _primário_ dos JWTs é pass claims between parties in web application environment , é _exatamente_ para o que os estamos usando.

Nossos ids ou tokens de sessão _podem_ ser simplesmente uma string aleatória que é verificada no lado do servidor, mas nós _decidimos_ usar JWTs para _formatar_ e _sign_ os dados da sessão.

Conclusão: vamos atualizar o readme para _clarificar_ as coisas. 👍

Em vez de dividir as questões levantadas em um conjunto de questões, conforme sugerido por @nelsonic , tendo a concordar que a intenção e os objetivos da implementação devem ser esclarecidos no escopo do README. Eu não li as edições de @ joepie91 como sendo uma crítica ao uso de JWTs no contexto de aplicativos da web como tais, ou o suporte de cookies como superiores; em vez disso, considero a crítica como sendo que a descrição do JWT é apresentada de uma forma que exagera ou deturpa o motivo da escolha do JWT.
A mesma preocupação é expressa também no # 55 (esclareça que JWT não é criptografia ...)

Para mim, é suficiente ser capaz de operar o Firebase e meus próprios serviços usando uma reivindicação comum que expira. Posso estendê-lo para incluir algum estado em alguns casos e não em outros e ainda preferir a abordagem de usar cookies ou abordagens de autenticação http de controle de acesso mais antigas.
Gosto de poder usar tokens JWT como parte de uma abordagem mais sofisticada, mas ainda concordo que o foco nos benefícios do README deve estar nos problemas que estamos tentando resolver com eles, em vez de nos desviar para um terreno menos sólido. Muito do material de referência no README poderia talvez ser relegado a notas ou mesmo ao Wiki como um material de discussão?

Não sei se diria necessariamente que o README é perigoso - parece um pouco forte

Cookies> na diretiva de privacidade eletrônica da UE, Considerando 25, os cookies são mencionados explicitamente 5 vezes:

Desculpas, parece que eu disse algo vagamente. Embora o texto contenha a palavra "cookie" em vários lugares, ele não a identifica como um conceito específico a ser legislado; em vez disso, é fornecido como um exemplo (e, portanto, o resto do meu ponto permanece aplicável, e "não usar cookies" não removerá magicamente a necessidade de consentimento).

localStorage é como todos os aplicativos construídos com um "Backend-as-a-Service" são feitos, porque BaaS normalmente não aceita cookies ...

Isso é irrelevante e um problema desses serviços. Isso _não_ justifica o uso do JWT para sessões em seu próprio aplicativo.

Você está sugerindo que meio milhão de desenvolvedores que usam o Google Firebase estão fazendo isso "errado" ...?

Além do fato de que o Firebase é extremamente mal projetado, isso é um apelo à autoridade e não tem lugar em uma discussão técnica. Não estou interessado em discutir as decisões de uma empresa específica para um produto específico; Estou apenas interessado em discutir os méritos e as desvantagens de uma determinada abordagem.

Sessões sem estado são possíveis com JWTs porque têm uma opção interna de exp (tempo de expiração), no entanto, escolhemos / preferimos não tornar nossas sessões sem estado em vez de optar por armazenar um id de sessão (jti) dentro do JWT que é pesquisado em um Loja do Redis após o JWT ter sido verificado. Isso significa que podemos invalidar uma sessão quando uma pessoa se desconecta ou se seu dispositivo é roubado e ela precisa revogar uma sessão ativa.

Nesse ponto, não há mais nenhum benefício real em usar o JWT. Por que você não está apenas usando express-session ou alguma outra solução de sessão testada em batalha e revisada por pares que se encaixa em sua pilha? A recomendação para JWT não faz sentido aqui, porque as pessoas _não deveriam estar rolando seu próprio gerenciamento de sessão em primeiro lugar_.

Sem mencionar que a expiração da sessão deve ser tratada _server-side_ e, portanto, exp em seu JWT é essencialmente inútil.

Sim, o objetivo principal dos JWTs é passar reivindicações entre as partes no ambiente de aplicativo da web, é exatamente para isso que os estamos usando.

Os JWTs não estão nem um pouco relacionados a "ambientes de aplicativos da web".

Nossos ids ou tokens de sessão podem ser simplesmente uma string aleatória que é verificada no lado do servidor, mas decidimos usar JWTs para formatar e assinar os dados da sessão.

Novamente, basta usar uma implementação de sessão testada em batalha para sua pilha. JWT é a recomendação errada a se fazer aqui.

Respeitosamente discordamos que o conteúdo dessas notas seja "Perigoso".

Você pode discordar, mas é isso. Existem tantas maneiras de usar o JWT incorretamente - várias das quais são mencionadas pelo README neste repositório - que as pessoas estão _conduzidas_ a dar um tiro no próprio pé. Sim, é prejudicial.

@ pscott-au: joepie91 - você claramente tem uma boa compreensão dos problemas .. poderia fornecer algumas reflexões sobre quais são os reais benefícios desse tipo de uso dos JWTs?

Não há benefícios em usar o JWT para aplicativos da web padrão, a menos que você esteja executando na escala do Reddit. Alguns exemplos comuns de casos em que JWTs _são_ úteis:

• Mecanismos de logon único (onde o JWT é usado como um token de autenticação única que o usuário troca por uma sessão no aplicativo de destino),
• Tokens de acesso temporário para imagens privadas em que os URLs devem ser compartilháveis,
• Basicamente, qualquer cenário em que dois sistemas que confiam um no outro precisam trocar alguns dados por meio de uma parte não confiável, sem estar em contato direto ou compartilhar um back-end.

Para sessões de aplicativo da web padrão, você deve apenas usar uma implementação de sessão bem testada para qualquer pilha que estiver usando (por exemplo, express-session quando estiver usando Express).

É ótimo ter essa discussão, pois realmente desafia um pouco da minha experiência. Talvez algum contexto para meu interesse pessoal em usar o JWT (além do fato de que eu uso o Firebase, que estaria interessado em aprender sobre os problemas de engenharia inadequados que examinarei). Ao criar aplicativos móveis / SPA e, particularmente, ao usar serviços originados de vários servidores / domínios, acho que geralmente exijo um recurso de logon único para o qual o JWT parece se adequar bem. Meu entendimento é que o uso de cookies de sessão evoluiu ao longo de um período em que a segurança foi reforçada no navegador e no espaço JS e a introdução do CORS evoluiu para lidar com exceções a isso, deixando-nos com uma solução bastante hacky que a JWT vai de alguma forma abordar .
Durante anos, as abordagens de sessão de cookie certamente proporcionaram uma abordagem muito melhor do que a autenticação http original e básica e muitas vezes eu usaria uma solução de gerenciamento de sessão de cookie para um aplicativo baseado na web.
Mas ... acho que a maioria dos aplicativos que estou construindo agora são móveis ou SPA e fazem uso intenso do REST APIS. Gosto de poder testar facilmente com solicitações curl simples sem agrupar as coisas de manipulação de cookies ou lidar com várias solicitações para estabelecer a sessão. Portanto, acho que implementar APIs rapidamente faz com que as coisas simplesmente funcionem quando uso o JWT. No meu íntimo, parece mais apropriado usar JWT para sessões de longa duração do que cookies, embora eu vá ruminar sobre isso, pois pode ser mais preguiça do que boa intuição. Posso estender a segurança ao longo das linhas do OAUTH, se necessário, e quero proteger as coisas de maneira mais completa, mas na maioria das vezes a sessão não é algo que julgo precisar desse nível de segurança. O importante para mim é a flexibilidade que uma abordagem de autenticação baseada em JWT oferece em relação a mudanças arquitetônicas no futuro. Descobri que o código mais antigo foi refatorado para fornecer autenticação JWT como uma opção e isso introduziu surpreendentemente pouca complexidade de manutenção, mas na maioria dos casos simplificou o desenvolvimento futuro e não vejo nenhuma parte dele como sendo inerentemente inferior às sessões de cookies.
Existem, de fato, vantagens em usar os recursos de tempo limite do JWT, especialmente em dispositivos móveis e algumas bibliotecas de suporte fazem uso disso. Você poderia, por exemplo, fazer com que um aplicativo desconecte o usuário ou deixe-o conectado com base neste tempo limite quando o dispositivo não estiver conectado à rede.
Para mim, não vejo nenhum argumento convincente sobre as vantagens de escala do JWT em relação aos cookies de sessão.
Vejo pessoas sugerindo que o JWT pode ser usado como um cookie de sessão, o que para mim faz mais mal do que bem, pois os cookies têm seu próprio período de tempo limite (não totalmente gerenciado no lado do servidor) e a combinação deles pode causar confusão.
Muitos frameworks JS modernos estão fornecendo maior suporte para JWT do que para cookies, o que sugere que a solução revisada por pares testada em batalha para a pilha pode de fato estar tendendo para JWT para muitos aplicativos. Embora a popularidade do JWT para serviços da Web não seja um argumento técnico, rejeitar isso como irrelevante porque todos eles são igualmente falaciosos. Express não é um elemento central da pilha usada pelo grupo dwyl da melhor forma que eu posso dizer, então não há razão para alinhar com ele.
Espero que haja alguma linha de minha intenção com a qual você possa concordar, pois continuo preocupado, mas não inteiramente convencido por seus argumentos.
Concordo que o README precisa de uma revisão séria e que há linhas que ele segue que devem ser removidas ou colocadas de volta em um texto de discussão de fundo e não no README principal.

(além do fato de que eu uso o Firebase, que estou interessado em aprender sobre os problemas de engenharia ruins que irei analisar)

Alguns dos problemas são que sua biblioteca de cliente JS é de código fechado e ofuscada com uma saída de erro bastante inútil, não existe algo como "matrizes", existem muitos bugs estranhos na biblioteca de cliente onde você pode simplesmente não obter uma resposta para motivos pouco claros, o sistema ACL usa uma variante JSON não padrão que nem mesmo seu próprio editor suporta, a API JS requer o uso de uma API de pseudoevento em vez de uma API de retorno de chamada normal (mas não se comporta de forma consistente), e em breve.

Ao criar aplicativos móveis / SPA e, particularmente, ao usar serviços originados de vários servidores / domínios, acho que geralmente exijo um recurso de logon único para o qual o JWT parece se adequar bem. Meu entendimento é que o uso de cookies de sessão evoluiu ao longo de um período em que a segurança foi reforçada no navegador e no espaço JS e a introdução do CORS evoluiu para lidar com exceções a isso, deixando-nos com uma solução bastante hacky que a JWT vai de alguma forma abordar .

Não é muito preciso. Seu aplicativo e APIs de terceiros são coisas diferentes, com requisitos de autenticação diferentes. Considerando que um sistema de autenticação baseado em token pode fazer sentido em um aplicativo ao se comunicar com uma API de terceiros, isso não faz sentido para seu próprio aplicativo, mesmo se for um SPA. Isso também não está relacionado ao "logon único", que se refere a vários serviços de usuário final usando o mesmo serviço de logon.

CORS é um problema separado, e não está realmente relacionado a isso.

Mas ... acho que a maioria dos aplicativos que estou construindo agora são móveis ou SPA e fazem uso intenso do REST APIS. Gosto de poder testar facilmente com solicitações curl simples sem agrupar as coisas de manipulação de cookies ou lidar com várias solicitações para estabelecer a sessão. Portanto, acho que implementar APIs rapidamente faz com que as coisas simplesmente funcionem quando uso o JWT.

No desenvolvimento, você pode ter certos requisitos de teste, mas eles não devem afetar a abordagem que você adota na produção. Tirando o fato de que a maioria das coisas que são um SPA realmente não deveriam ser um SPA para começar (SPAs são para webapps, não sites!), Não há razão para que você não possa usar sessões com eles.

Além disso, cURL oferece suporte a cookies sem problemas, e há muitos outros clientes de teste de API melhores, como httpie ou mesmo http-prompt .

Posso estender a segurança ao longo das linhas do OAUTH, se necessário, e quero proteger as coisas de maneira mais completa, mas na maioria das vezes a sessão não é algo que julgo precisar desse nível de segurança.

A sessão é um dos aspectos mais importantes da sua aplicação. Se não for suficientemente seguro, seu aplicativo está essencialmente corrompido e completamente vulnerável. É por isso, por exemplo. armazenar JWTs em LocalStorage é uma ideia terrível.

O importante para mim é a flexibilidade que uma abordagem de autenticação baseada em JWT oferece em relação a mudanças arquitetônicas no futuro. Descobri que o código mais antigo foi refatorado para fornecer autenticação JWT como uma opção e isso introduziu surpreendentemente pouca complexidade de manutenção, mas na maioria dos casos simplificou o desenvolvimento futuro e não vejo nenhuma parte dele como sendo inerentemente inferior às sessões de cookies.

Nenhuma flexibilidade é introduzida aqui que 99,99% dos desenvolvedores irão precisar, e eu já destaquei alguns dos problemas que isso apresenta, como dados desatualizados e incapacidade de invalidar tokens.

Existem, de fato, vantagens em usar os recursos de tempo limite do JWT, especialmente em dispositivos móveis e algumas bibliotecas de suporte fazem uso disso. Você poderia, por exemplo, fazer com que um aplicativo desconecte o usuário ou deixe-o conectado com base neste tempo limite quando o dispositivo não estiver conectado à rede.

Isso não é exclusivo do JWT; você pode fazer isso com sessões do lado do servidor muito bem. Na verdade, os JWTs não podem ser invalidados sem a introdução de uma arquitetura com estado (complexa), de modo que as sessões realmente vencem aqui.

Para mim, não vejo nenhum argumento convincente sobre as vantagens de escala do JWT em relação aos cookies de sessão.

A vantagem de escalonamento é que você não precisa de um único servidor canônico contendo todas as sessões (uma vez que os dados podem ser armazenados diretamente no token), o que significa que você pode remover um gargalo. Mas, como eu disse, quase nenhum desenvolvedor enfrentará esse problema na prática. Só é útil para projetos de escala extremamente grande.

Muitos frameworks JS modernos estão fornecendo maior suporte para JWT do que para cookies, o que sugere que a solução revisada por pares testada em batalha para a pilha pode de fato estar tendendo para JWT para muitos aplicativos.

Ainda estou para ver uma estrutura que não oferece suporte a cookies de sessão.

Express não é um elemento central da pilha usada pelo grupo dwyl da melhor forma que eu posso dizer, então não há razão para alinhar com ele.

Esse é o problema deles. Express foi simplesmente um exemplo, existem implementações de sessão bem testadas para basicamente todos os frameworks comumente usados.

O resultado final é que, para qualquer desenvolvedor que esteja lendo este repositório, haverá exatamente zero vantagens no mundo real para o JWT e várias desvantagens ou até mesmo problemas de segurança. Simplesmente não é uma boa escolha ou recomendação técnica, e ponto final.

@ joepie91 Não posso te dizer o quão _delicioso_ estou por você ter encontrado nosso repositório / notas e investido seu tempo para lê-lo e nos dar feedback! Sério, se algum dia eu te encontrar pessoalmente, vou te dar uma _palete_ de tudo o que você gosta de beber! 🍺

Se eu torná-lo um contribuidor neste repo, você revisará meu Pull Request para _melhorá-lo? 📝

Além disso, @AshleyPinner , @alfiepates , @ sunny-g, como _você_ cavalheiros se depararam com esta discussão _particular_? o problema foi compartilhado no Redit / Hackernews? (_Estou curioso em saber como as pessoas encontram nossas postagens ..._)

Venho pensando nisso há alguns dias e simplesmente não consigo aceitar muitos dos argumentos contra o uso do JWT como opção padrão antes dos cookies de sessão tradicionais em SPA modernos e aplicativos móveis.
Eu estava pensando em construir uma matriz de decisão para pesar os prós e contras das abordagens de autenticação de cookies / JWT para requisitos específicos ou detalhando os prós e contras em um conjunto de casos de uso antes de pensar em reescrever o README. Parece-me que muitos dos desafios do mundo real que as pessoas encontram ao criar aplicativos complexos são, em sua maioria, resolvidos de forma menos elegante ou, pelo menos, tão problemáticos usando sessões de cookies. A percepção que o autor do problema cria é que o JWT é uma tecnologia imatura, hackeada e não confiável, inadequada para aplicativos modernos, e essa afirmação talvez seja ainda mais perigosa do que fornecer um exemplo completo de como usá-lo para autenticar um usuário.
Achei este artigo do OATH útil . Acho que uma das coisas que desencadeou uma reação tão forte a este repo, mas o relator do problema é a discussão dos recursos que são normalmente esperados em sessões de cookie usando JWT que prejudicam alguns dos principais benefícios do JWT, principalmente envolvendo que ele pode ser sem estado. Ao introduzir o estado ao incorporar armazenamento persistente, estamos eliminando um dos principais casos de uso do JWT e reimplementando coisas que estão maduras usando cookies.
Dito isso, aplicativos complexos são propensos a exigir alguma descoberta de estado - mesmo que apenas para solicitações transacionais para ações que são processadas além da vida de uma única solicitação HTTP. Isso não deve impedir o uso do JWT, mas deve nos dar uma pausa para considerar o papel que o JWT desempenha na transação. Eu considero normal ter um JWT que concede acesso a um recurso e o recurso tem um estado para o usuário que nega acesso a um serviço; neste caso, não é o JWT que precisa ser expirado, mas o estado do usuário acessando o serviço usando o JWT.

Estender ainda mais o uso de cookies como mecanismo de transporte elimina outro dos benefícios e nos leva de volta ao uso de cookies, mas ignorando a funcionalidade usual da biblioteca e reescrevendo recursos do zero, o que introduz mais ambiguidade porque acabamos com tempos limites duplicados etc. Quando mencionei CORS anteriormente talvez fosse melhor ser explícito ao apontar as dificuldades de usar vários domínios com cookies. Claro, você pode definir domínios curinga, mas se eles forem suficientemente diferentes, os cookies de sessão tradicionais rapidamente se tornam difíceis de controlar. Pode-se argumentar que a maioria dos desenvolvedores não precisa de seu cliente autenticado para acessar recursos protegidos em vários domínios, mas isso está se tornando muito mais uma prática comum do que um caso exótico.
Em certo sentido, como uma nova pessoa que está começando a explorar o gerenciamento de sessões autenticadas, entendo que esta pode não ser uma maneira apropriada de aprender sobre como limitar o acesso a um recurso em um aplicativo da web para usuários autenticados no sentido mais simples, mas o uso de JWT só vai se tornar mais proeminente como o ponto de partida para sessões autenticadas, então descartar isso porque usamos cookies de sessão por um longo tempo não é suficiente para eu acreditar que todos deveriam começar com cookies de sessão e apenas aprender e usar JWT quando eles descobrem que não podem compartilhar cookies entre domínios ou precisam acessar uma API de terceiros ou precisam ser capazes de determinar a expiração sem verificar o servidor, ou questionar o armazenamento das credenciais de login do usuário no dispositivo móvel etc etc etc .

É incorreto subestimar as vantagens dos tokens sem estado como algo irrelevante, a menos que você esteja executando um site com tráfego de nível superior. Mesmo quando confundimos as coisas introduzindo uma nova camada de estado, o desacoplamento da sessão do servidor tem inúmeras vantagens.

@nelsonic Olhando para 4744cd1bb8991bc4057c749f86007fcecac19d1d, parece uma formulação muito mais clara. O cabeçalho não parece refletir as mudanças, no entanto.

@ pscott-au: em SPA modernos e aplicativos móveis.

Isso é _completamente_ ortogonal à sua escolha de mecanismo de sessão. Sem falar que a maioria das coisas que hoje são um SPA, não deveriam ser. Usar um SPA para um site (em oposição a um aplicativo da web) quebra a web.

Parece-me que muitos dos desafios do mundo real que as pessoas encontram ao criar aplicativos complexos são, em sua maioria, resolvidos de forma menos elegante ou, pelo menos, tão problemáticos usando sessões de cookies.

Tal como?

A percepção que o autor do problema cria é que o JWT é uma tecnologia imatura, hackeada e não confiável, inadequada para aplicativos modernos

Não, não é. O JWT como uma tecnologia não é terrível (mesmo se houver _existem_ algumas decisões questionáveis ​​na especificação) - as sessões simplesmente não são o propósito pretendido e é um ajuste inadequado para esse caso de uso.

Não estou dizendo que a ferramenta seja ruim, estou dizendo que você está usando errado.

e esta afirmação é talvez ainda mais perigosa do que

Qual é a sua razão para isso?

Achei este artigo do OATH útil.

Abordando ponto por ponto:

• Sem estado, escalável e desacoplado: já reconheci que este é um benefício teórico, mas que na prática quase ninguém realmente precisa. Você também deve considerar que Auth0 tem um interesse pessoal aqui, que _não_ beneficia você como desenvolvedor: _ "Serviços de terceiros como Auth0 podem lidar com a emissão de tokens e então o servidor só precisa verificar a validade do token. "_ Terceirizar sua autenticação é uma idéia _terrível_, aliás.
• Cross Domain e CORS: um disparate completo e absoluto. Fala sobre o _método de armazenamento_, que é totalmente separado do fato de o token _contém_ os dados da sessão ou não. Você pode ter uma ID de sessão enviada manualmente ou pode armazenar um JWT em um cookie. Não tem nada a ver com JWT vs. sessões - o que também mostra o preconceito / ignorância do autor do artigo, já que comparar "cookies vs. tokens" _não faz sentido para começar_. Ele também ignora completamente esse problema de segurança .
• Armazenar dados no JWT: não é um recurso. O mesmo se aplica às sessões. E biscoitos, por falar nisso.
• Desempenho: Esta é apenas uma repetição do ponto "sem estado", principalmente - além do fato de que não está _de modo algum_ claro se a verificação criptográfica pode necessariamente superar algo como o Redis no desempenho de manipulação de dados da sessão (sua comparação com um RDBMS não é realista) , também é uma otimização de desempenho completamente insignificante para quase todos os aplicativos da web. Isso é chamado de "otimização prematura" e é amplamente não recomendado por um bom motivo.
• Pronto para celular: um disparate. Se sua biblioteca HTTP não suporta cookies, _procure uma biblioteca HTTP melhor_. Os cookies são suportados muito bem, eles são apenas cabeçalhos HTTP.

Portanto, não, esse artigo não traz nenhum benefício novo do JWT que eu ainda não tenha abordado. Ele apenas representa erroneamente o às vezes um benefício (apatridia) como algo que se aplica a todos os aplicativos (não se aplica) e, em seguida, faz comparações sem sentido e enfatiza excessivamente o desempenho da sessão para o restante.

Acho que uma das coisas que desencadeou uma reação tão forte a este repo, mas o relator do problema é a discussão dos recursos que são normalmente esperados em sessões de cookie usando JWT que prejudicam alguns dos principais benefícios do JWT, principalmente envolvendo que ele pode ser sem estado.

Como eu disse, isso quase nunca é um benefício na prática. Você pode repetir esse mesmo ponto de apatridia indefinidamente, mas isso não o tornará mais válido ou aplicável. Não é _absolutamente_ um requisito de propósito geral.

Eu considero normal ter um JWT que concede acesso a um recurso e o recurso tem um estado para o usuário que nega acesso a um serviço; neste caso, não é o JWT que precisa ser expirado, mas o estado do usuário acessando o serviço usando o JWT.

Nesse caso, você não tem exatamente nenhum benefício em relação a algum tipo de ID de sessão regular.

[...] Quando mencionei o CORS anteriormente, talvez fosse melhor ser explícito ao apontar as dificuldades de usar múltiplos domínios com cookies. Claro, você pode definir domínios curinga, mas se eles forem suficientemente diferentes, os cookies de sessão tradicionais rapidamente se tornam difíceis de controlar.

Isso é, também, completamente ortogonal ao ponto. Isso é puramente sobre onde você _armazena_ seus identificadores, não sobre se eles _contêm_ os dados da sessão por si próprios. E novamente, risco de segurança .

mas o uso de JWT só vai se tornar mais proeminente como o ponto de partida para sessões autenticadas

E isso me preocupa muito, porque esse uso proeminente é baseado na ignorância e no exagero, e vem com muitos problemas de segurança. Este é um grande passo para trás.

então, para ignorar isso porque usamos cookies de sessão por muito tempo

Eu nunca disse nada disso. Eu forneci várias razões _muito_ claras de porque JWT é _objetivamente inferior_ para gerenciamento de sessão.

e apenas aprender e usar o JWT quando descobrirem que não podem compartilhar cookies entre domínios

Nesse caso, problema de segurança . Cookies _não são opcionais_.

ou precisa acessar uma API de terceiros

Irrelevante para as sessões.

ou precisa ser capaz de determinar a expiração sem verificar o servidor

Não é possível, porque o servidor precisa reter a capacidade de invalidar explicitamente uma sessão - por exemplo, quando o usuário muda sua senha ou fecha outras sessões à força.

ou questionar o armazenamento das credenciais de login do usuário no dispositivo móvel etc etc etc.

Biscoitos. Feito.

É incorreto subestimar as vantagens dos tokens sem estado como algo irrelevante, a menos que você esteja executando um site com tráfego de nível superior. Mesmo quando confundimos as coisas introduzindo uma nova camada de estado, o desacoplamento da sessão do servidor tem inúmeras vantagens.

No entanto, você não menciona nenhum deles que eu já não tenha abordado e levado em consideração em minhas conclusões. Sinto muito, mas você está defendendo novas abordagens por serem novas abordagens e ignorando completamente o _objetivo, propriedades técnicas_ das diferentes abordagens.

Isso é o que se chama de "hype" e é extremamente prejudicial.

Stateless: importante quando um aplicativo precisa funcionar offline e reter algum tipo de significado.

Aplicativos offline não precisam de autenticação, _at all_. Por definição, não há interação com outros sistemas.

Autenticação de credencial de domínio cruzado: importante se você dividir seu aplicativo em microsserviços usando vários servidores

Correto. Mas, neste caso, você não usa JWT _como seu mecanismo de sessão_, você o usa como um token de uso único que pode ser _trocado_ por uma sessão. Há uma diferença muito grande entre os dois e as vantagens e desvantagens que eles apresentam.

( EDITAR: É claro que isso pressupõe microsserviços _stateful_ e com 'stateful' _não_ estou me referindo à sessão, mas ao próprio serviço. Para microsserviços que realizam tarefas sem estado, tokens de uso único _sem_ usando uma sessão é suficiente, com os tokens de uso único sendo emitidos pelo servidor de aplicativos. Para servidores de aplicativos que se comunicam com microsserviços, o JWT também funciona - não há conceito de "sessão" aqui e a revogação do token pode ser feita alterando a chave de assinatura.)

Você pode continuar a negar a utilidade do JWT

Novamente, eu não estou fazendo tal coisa. Estas são inteiramente suas palavras.

Quando tento fornecer mais detalhes, você apenas descarta meus casos como irrelevantes ou de má prática .. na minha opinião incorretamente.

Então espero que você explique _porquê_ está incorreto, não apenas diga "isso está incorreto!" e espera que eu considere o valor de face. Estou abordando concretamente cada ponto que você fornece precisamente por esse motivo.

Depender de um cookie para gerenciar uma sessão de login do iOS não é a melhor solução por padrão.

Porque?

cookies podem ser usados ​​indevidamente

Essa é uma declaração vazia. _Como_ mal usado? E como isso não se aplica aos valores armazenados no armazenamento local? E o que isso tem a ver com JWT _at all_ dado que "cookies" é um método de armazenamento, não um mecanismo de sessão? Comparar "JWT vs. cookies" é comparar maçãs e laranjas, eles nem são da mesma classe de coisa!

O uso do JWT para gerenciamento de sessão é diferente e tem propriedades diferentes das sessões de cookie - isso não o torna inferior, mas simplesmente tem critérios de parâmetros operacionais diferentes para arquitetar uma solução apropriada. Se você deseja usar cookies, use cookies - se eles atenderem aos seus requisitos, use-os - por que deseja evitar que outras pessoas considerem qualquer outra abordagem?

Eu não estou. Eu indiquei _muito claramente_ exceções em que JWT _é_ a solução certa. Eu também _muito claramente_ indiquei que o JWT não é adequado como um mecanismo de sessão de propósito geral . Pare de colocar palavras na minha boca.

Sua noção de sessões de login como sendo de valor apenas para autenticação em seu servidor web com armazenamento persistente ignora o fato de que eu posso querer ter alguns serviços de dados fornecidos por provedores alternativos que validem o mesmo JWT e não exijam a criação de novos cookies . De que forma isso é irrelevante para as sessões ???

Porque não há razão para que você não possa usar _both_ JWT e sessões, para propósitos diferentes. Tentar encaixar tudo em um único mecanismo é _completamente_ errado. Use a ferramenta apropriada - "não exigir a criação de novos cookies" é uma métrica completamente arbitrária e realisticamente, não o benefício que você está sugerindo.

Se você encontrar problemas de segurança, identifique-os e sinalize-os - eles podem não atrapalhar, mas podem ser úteis para estar ciente ao tomar uma decisão. Suas palavras vitriólicas não reconhecem isso ou até mesmo consideram isso uma possibilidade porque você continua a afirmar que os cookies de sessão devem ser usados ​​para todos os aplicativos http, o que é simplesmente ridículo.

Novamente. Não. Eu disse. Pare de colocar palavras na minha boca.

Os exemplos que você citou da função das sessões para impor regras específicas, como encerrar em alterações de senha ou para gerenciar restrições de serviço, não é uma função embutida dos cookies de sessão, apenas uma função normalmente utilizada por essa abordagem.

É um recurso que _requer_ sessões com monitoração de estado de algum tipo, arquiteturalmente. Não estou argumentando que isso seja fornecido por cookies de sessão - estou argumentando que é _impossível_ com tokens sem estado.

Se sua solução é bastante confortável para fornecer acesso autenticado sem verificar um banco de dados para acessar um recurso durante a duração da sessão, por que você insiste que isso é uma falha dessa abordagem?

Novamente, não o que eu disse.

Quando sugerimos que os controles específicos (caso eles exijam algum tipo de sessão encerrável) possam ser introduzidos conforme necessário, você responde que os cookies têm isso integrado e que você nunca deve tentar olhar para outras abordagens. A implementação desse tipo de controle não é uma sobrecarga significativa a ponto de impedir as sessões de autenticação do JWT sobre os cookies.

A questão não é sobrecarga. A questão é usar soluções testadas e comprovadas que funcionam bem . Reimplementar sua própria segurança é uma ideia terrível em _qualquer_ situação, e isso inclui esta.

Você ignora o número de solicitações de cookies e sugere que a única consideração de desempenho é a consulta. A necessidade de coordenar atualizações etc e depender de .. ah, deixa pra lá ... (desisti aqui)

Sobre o que é mesmo que você está falando? As "atualizações" de cookies são tratadas em linha nas respostas HTTP com o envio de um novo cookie - não há nada extra envolvido aqui, além da atualização do armazenamento de sessão, que já abordei em meu exemplo do Redis. Se você acha que há outras considerações de desempenho, _liste-as_.

Você pode adorar o fato de os cookies serem restritos a domínios e considerar que permitir que eles sejam usados ​​em domínios cruzados apresenta problemas de segurança que impedem seu uso - tudo bem - eu não.

Novamente, não o que eu disse.

Os JWT não são a próxima coisa a substituir todos os cookies de sessão, mas também não são uma abominação tão séria (quando usados ​​para gerenciar sessões) como você indica.

Sim, eles estão. O único motivo pelo qual você desejaria usar o JWT para sessões é porque as alternativas são piores ou impossíveis, e esse é um caso extremo _extremamente_ raro.

Você trata a segurança como algo absoluto, sem nenhuma menção aos vários refinamentos que podem ser feitos nesta abordagem se / quando necessário e como a complexidade dessa evolução se compara às abordagens tradicionais baseadas em sessão.

Só estou tratando a segurança como um absoluto quando _é_ um absoluto. Eu também abordei possíveis maneiras de resolver isso, _e_ expliquei como elas não são uma boa solução em comparação com as sessões porque o resultado líquido é ainda pior. Se você acha que estou faltando um caso ou solução, mencione-o. Pare de aludir vagamente a "outras opções", sem nunca realmente explicar quais são. Agora, pelo que posso dizer, você está blefando.

Não é exagero - não é baseado em ignorância, mas é uma solução válida para problemas enfrentados regularmente ao criar aplicativos híbridos que exigem autenticação cruzada para serviços que não visam fornecer a segurança mais rígida que a tecnologia pode oferecer e por um bom motivo - muito prático - de forma ampla adotado - não faz tudo virar uma merda.

Repetir sua afirmação não a torna mais verdadeira. Já abordei por que isso é falso e comprometer a segurança por motivos de exagero não é aceitável.

Para alguns de nós, ter a flexibilidade de controlar a sessão com granularidade mais fina do que a fornecida pelos cookies oferece maior flexibilidade - se você não vir os casos de uso, tudo bem - espero que, se você construir muitos aplicativos híbridos, você irá e talvez então você será capaz de articular melhor os contra-argumentos a alguns dos pontos que você apresenta do que eu.

_Existe_ "maior flexibilidade". Novamente, se você acha que existe, explique como.

De qualquer forma - você é muito mais eloqüente do que eu e é claramente inabalável em sua posição

Não. Eu apenas espero que alguém forneça argumentos sólidos, bem fundamentados e tecnicamente corretos, se eles quiserem mudar meus pontos de vista. Você não fez isso.

Lembro que a última vez que tive um apego tão implacável a uma abordagem foi quando alguém estava argumentando que o digest auth nunca deveria ser substituído por cookies de sessão.

... e isso seria um exemplo perfeito de tal falácia.

O resultado final é que metade de suas declarações estão colocando na minha boca palavras que eu nunca disse, nem impliquei, nem tive a intenção. A outra metade argumenta a favor do comprometimento desnecessário da segurança ou faz alegações vagas sobre a existência de "outros benefícios" ou "outras soluções", sem nunca entrar em detalhes.

Francamente, estou cansado disso - não acho que essa discussão vá em uma direção construtiva e está atrapalhando o assunto. A única razão pela qual continuo respondendo é o risco de as pessoas serem mal informadas por seus não argumentos.

Se você quiser continuar acreditando que JWT é o Santo Graal, apesar de não ter argumentos técnicos para apoiar essa noção, então essa é sua escolha - mas você _não me convencerá_ a menos que venha com _discussões técnicos reais_ e continue a repetir as mesmas afirmações e de novo não vai ajudar ninguém.

Para resumir meus pontos para aqueles que examinam toda a discussão:

• O JWT não foi projetado para sessões, mas para transferir reivindicações assinadas, geralmente de uso único.
• O JWT não é adequado para sessões, devido à incapacidade de invalidar tokens, problemas com dados obsoletos e a necessidade de gravar implementações não testadas para fazê-lo funcionar. Essas são questões de segurança.
• "Cookies vs. JWT" não é uma comparação válida; um é um mecanismo de armazenamento enquanto o outro é um formato de token. Os cookies não são
• Às vezes você _não_ pode usar sessões com monitoração de estado porque está operando em uma escala muito grande e, nesses casos, JWT _pode_ ser a opção 'menos ruim' disponível - mas esses casos são raros, e a menos que você trabalhe para um grande site do tamanho de Reddit, você provavelmente nunca os encontrará.

(Reddit usa sessões com monitoração de estado, a propósito.)

Acredito que a intenção deste repo é pavimentar o caminho para a implementação de um SPA híbrido móvel e o uso de JWT como um substituto para sessões de cookies é uma abordagem comum e quase padrão.
Um dos motivadores para isso é o problema que os cookies têm ao serem vinculados a um domínio quando um SPA pode de fato exigir acesso a microsserviços em vários domínios em plataformas diferentes. O JWT é uma abordagem elegante para as limitações dos cookies neste contexto. Usar uma abordagem OAUTH ou OAUTH2 seria mais robusto do ponto de vista da segurança, mas introduz uma complexidade que pode não ser necessária para muitos aplicativos. As sessões de suporte JWT que não dependem da negociação de um token AUTH não são um uso indevido do JWT, mas uma aplicação de uma abordagem menos segura a fim de obter simplicidade e para aplicativos que têm mais a ganhar com a implementação rápida do que a segurança adicional fornecida por um mais abordagem robusta. Ao mesmo tempo que agiliza a implementação rápida, ele fornece um caminho de migração mais claro para tokens de uso único do que outras abordagens.
Algumas das reações e críticas contra o uso de cabeçalhos de token do JWT Bearer como um substituto para cookies de sessão são de fato baseadas em algumas pessoas os apresentando como uma evolução ou melhoria em relação aos cookies de forma mais ampla, o que eu concordo que não é o caso. Peço que você considere meus casos de uso e como você os abordaria usando cookies.
o uso do JWT para gerenciamento de sessão de autenticação deve ser feito com cuidado e as deficiências devem ser explicitadas, no entanto, descartá-las como um exagero inútil, sendo sempre usado fora do contexto, é enganoso e incorreto.
Usar o JWT significa que você não precisa atualizar os cookies toda vez que o cliente entrar em contato com o servidor. Uma confiança razoável pode ser assegurada sem verificar o banco de dados, embora seja tão fácil estender essa verificação quanto usar cookies de sessão.
Usar o JWT significa que os clientes com cookies bloqueados não serão forçados a voltar a usar variáveis ​​de postagem ocultas etc. como preenchimento.
Usar o JWT em vários serviços permite um serviço que não requer autenticação, mas deseja alguma indicação da validade de um campo de dados simples, como uid, que pode ser agrupado em um JWT e passado.
As abordagens JWT se prestam a abordagens OAUTH mais sofisticadas.
As solicitações JWT REST podem ser feitas sem postar credenciais ou exigir uma solicitação de cookie antes de acessar o serviço, o que pode simplificar a implementação de REST / SPA.
Usar um cabeçalho de portador ou um cabeçalho de cookie não é drasticamente diferente quando se trata de segurança (exceto para restrições de domínio que podem ser validamente indesejáveis. (NB, não estou colocando palavras em sua boca, mas tentando interpretar o que você está aludindo, dizendo que a segurança é pior)
Onde períodos prolongados de ausência são comuns / esperados, como com aplicativos móveis, os cookies podem ser menos desejáveis ​​do que uma abordagem JWT. Ter um caminho mais claro para o autoexame de credenciais pode facilitar o comportamento sem fazer check-in no servidor.
Se você aceitar que há casos de uso para sessões que podem ter períodos offline prolongados, as sessões não são necessariamente com monitoração de estado.
Se você for capaz de aceitar que as sessões podem existir com sucesso com vários estados da perspectiva do cliente e do servidor, então talvez você possa se aproximar de casos de uso que incluem períodos de não conectividade prolongada com o servidor (por exemplo, coleta de dados do usuário para atualização em lote ao reconectar). Existem casos em que o cliente pode operar de forma mais eficaz sabendo que a sessão expirou e uma atualização é necessária sem gerenciar outra camada de dados. Também poder usar o JWT como uma validação de sessão, mesmo depois que a senha foi alterada, etc, pode ser útil em alguns casos para permitir que os dados sejam passados ​​para a camada de lógica de negócios e fazer com que decida como aceitar a solicitação.
Você sempre me diz que os cookies são seguros, o que suponho que alude à implementação em navegadores, etc. - fora de um navegador, não consigo ver por que eles são inerentemente mais seguros - talvez você possa explicar?
Em aplicativos SPA / híbridos, a dependência de cookies não é necessariamente a única posição inicial - confiar no manuseio de cookies pelo navegador não o aproxima do nativo, mas introduz uma dependência no UIWebView ou qualquer outro e não tenho certeza de que sempre será comporte-se como eu esperava.
Os tokens podem ser retidos na memória durante a execução de um aplicativo sem necessariamente serem persistidos - isso não é realmente a mesma coisa que confiar na integridade dos cookies - há um controle mais granular no iOS, pelo menos nas permissões de armazenamento que existem além do navegador e isso me parece mais apropriado do que estar vinculado a abordagens de armazenamento do navegador.
Os cookies são realmente opcionais - não há nenhuma lei que estabeleça que você só deve usar cookies.
O desacoplamento da sessão do servidor pode, em alguns casos, ser uma coisa ruim, mas nem sempre - as abordagens modernas, incluindo o uso de JWT, introduzem novas preocupações, mas também uma nova flexibilidade e essa flexibilidade não inclui apenas as abordagens menos ruins.

Para resumir minha posição:
O uso de JWT como parte de uma solução de sessão de autenticação nem sempre é superado por cookies de sessão
O JWT é adequado para sessão se você estiver ciente dos benefícios e tiver um motivo para não exigir a invalidação simplista.
Os cookies não são a única solução.
Grande escala não é o único caso de uso para sessão sem estado - usar cabeçalhos JWT para autenticar domínios / serviços é um motivo válido para usá-los como uma alternativa aos cookies de sessão.

Peço que você considere meus casos de uso e como você os abordaria usando cookies.

Certo.

Usar o JWT significa que você não precisa atualizar os cookies toda vez que o cliente entrar em contato com o servidor.

Isso é o mesmo para cookies de sessão, cookies contendo JWT, _e_ tokens JWT propriamente ditos - você só precisa 'atualizá-los' explicitamente se eles estiverem prestes a expirar. Não há diferença aqui.

Usar o JWT significa que os clientes com cookies bloqueados não serão forçados a voltar a usar variáveis ​​de postagem ocultas etc. como preenchimento.

Os usuários que bloqueiam cookies quase certamente também bloquearão o armazenamento local e outras medidas de persistência (precisamente pela mesma razão que bloqueiam os cookies). As extensões de privacidade fazem o mesmo. Novamente, "JWT vs. cookies" _não é uma comparação válida_ e, se um usuário bloquear cookies, você não poderá persistir um token _de qualquer forma_. JWT ou não, não importa.

(Se um usuário bloqueia cookies no atacado, ele já escolhe não ter persistência de dados de qualquer maneira, então tentar oferecer suporte à autenticação para usuários que bloqueiam cookies é uma causa perdida. Essa é a compensação que vem com isso, e é totalmente tecnicamente razoável troca.)

Usar o JWT em vários serviços permite um serviço que não requer autenticação, mas deseja alguma indicação da validade de um campo de dados simples, como uid, que pode ser agrupado em um JWT e passado.

Veja a edição do meu post anterior (terceiro parágrafo), que trata de tokens de uso único em arquiteturas distribuídas. Essas não são sessões nem devem ser persistentes, portanto, os problemas que descrevi não se aplicam aqui.

As abordagens JWT se prestam a abordagens OAUTH mais sofisticadas.

OAuth usa tokens de uso único. Não é um substituto para as sessões. Novamente, veja a edição do meu post anterior.

As solicitações JWT REST podem ser feitas sem postar credenciais ou exigir uma solicitação de cookie antes de acessar o serviço, o que pode simplificar a implementação de REST / SPA.

Eles não podem. Você ainda precisa obter um JWT _de alguma forma_, o que significa que ele precisa ser emitido pelo servidor, o que significa que você precisa solicitá-lo ao servidor. Não importa se o servidor retorna um cookie ou um cabeçalho ou valor diferente. E novamente, "cookies vs. JWT" não é uma comparação válida.

Usar um cabeçalho de portador ou um cabeçalho de cookie não é dramaticamente diferente quando se trata de segurança (exceto para restrições de domínio que podem ser validamente indesejáveis.

Não vendo um argumento aqui.

Onde períodos prolongados de ausência são comuns / esperados, como com aplicativos móveis, os cookies podem ser menos desejáveis ​​do que uma abordagem JWT. Ter um caminho mais claro para o autoexame de credenciais pode facilitar o comportamento sem fazer check-in no servidor.

Isso não traz nenhum benefício - você não _precisa_ do token até que pretenda se comunicar com um servidor de qualquer maneira, portanto, você pode apenas tentar fazer uma solicitação e lidar com o 403 quando isso acontecer. Tentar evitar pedir ao servidor algo que inerentemente envolva falar com um servidor (ou seja, fazer uma solicitação autenticada) não faz sentido.

Sem falar que, se você quiser saber com antecedência se sua sessão terá expirado, basta enviar um cookie separado para isso. Uma vez que é apenas uma dica de experiência do usuário para o aplicativo, você nem precisa verificar sua autenticidade - e você precisa lidar com falhas de autenticação inesperadas _de qualquer forma_ devido à distorção do relógio e chaves de assinatura alteradas.

Em aplicativos SPA / híbridos, a dependência de cookies não é necessariamente a única posição inicial - confiar no manuseio de cookies pelo navegador não o aproxima do nativo, mas introduz uma dependência no UIWebView ou qualquer outro e não tenho certeza de que sempre será comporte-se como eu esperava.

Não é verdade. Qualquer biblioteca HTTP razoável - navegador ou não - oferecerá suporte a cookies. Os cookies _de forma alguma_ são exclusivos dos navegadores, eles são um recurso HTTP como qualquer outro.

O desacoplamento da sessão do servidor pode, em alguns casos, ser uma coisa ruim, mas nem sempre - as abordagens modernas, incluindo o uso de JWT, introduzem novas preocupações, mas também uma nova flexibilidade e essa flexibilidade não inclui apenas as abordagens menos ruins.

Ainda não vi nenhum exemplo concreto dessa 'flexibilidade'.

O uso de JWT como parte de uma solução de sessão nem sempre é superado por cookies de sessão

Essa é uma declaração muito ambígua. Você está comparando o uso de JWT como _parte da_ solução com o uso de cookies de sessão como a solução _entira_. Eles não são opostos - muitas arquiteturas complexas exigirão uma combinação de cookies de sessão e tokens JWT de uso único, por exemplo, para sistemas SSO ou arquiteturas distribuídas.

O JWT é adequado para sessão se você estiver ciente dos benefícios e tiver um motivo para não exigir a invalidação simplista.

Não. Os tokens JWT são um _último resort_ quando você não pode atender aos requisitos com cookies de sessão.

Os cookies não são a única solução.

Tecnicamente correto.

Grande escala não é o único caso de uso para sessão sem estado.

_É_ o único caso de uso que conheço, e não vi nenhum outro válido mencionado ao longo deste tópico. Lembre-se de que estou falando especificamente sobre _sessões_ sem estado, não sobre tokens sem estado _ em geral_.

Eu pergunto a você - como faço para implantar um aplicativo que usa 3 serviços diferentes (talvez em uma infraestrutura de contêiner diferente, etc.) e integrá-los ao aplicativo que conta com cookies de sessão? Se eu configurar um serviço de autenticação e desejar separá-lo de outro serviço, é a melhor abordagem para executar um manipulador de sessão de cookie de proxy compartilhado? Este é um caso extremo?
Como os cookies me fornecem maior segurança, flexibilidade e conformidade com os padrões do que usar um JWT de longa duração para rastrear minha sessão. Supondo que eu não queira ou me preocupe em poder encerrar a sessão sob demanda (embora isso não seja exatamente um benefício inerente dos cookies, mas sim no tratamento de solicitações), estou usando o cabeçalho do Bearer em cada postagem e respondendo a falha com um prompt / postagem de autenticação para obter um JWT de sessão a ser incluído em todos os cabeçalhos - posso ser estúpido, mas não vejo como isso é menos seguro. Os detalhes do cookie estão disponíveis no aplicativo híbrido assim como o token, embora haja menos controle sobre a persistência ... Acho que não entendi por que essa abordagem é tão ruim. Claro, você precisa fornecer credenciais para obter o JWT, mas você faz isso uma vez - não em cada serviço.

Eu pergunto a você - como faço para implantar um aplicativo que usa 3 serviços diferentes (talvez em uma infraestrutura de contêiner diferente, etc.) e integrá-los ao aplicativo que conta com cookies de sessão?

Depende do que os 3 serviços fazem. Você pode elaborar?

Se eu configurar um serviço de autenticação e desejar separá-lo de outro serviço, é a melhor abordagem para executar um manipulador de sessão de cookie de proxy compartilhado? Este é um caso extremo?

Você faria com que o serviço de autenticação emitisse um token JWT de uso único indicando autenticação bem-sucedida, opcionalmente incluindo 'informações de perfil' para o usuário, dependendo de sua arquitetura. Então, dependendo da aplicação:

1. Se for um site normal: O serviço de autenticação redireciona para uma página de autenticação no servidor de aplicativos, por exemplo. passando o token JWT como um parâmetro de consulta. O servidor de aplicativos valida o token e fornece ao usuário um cookie de sessão.
2. Se for um SPA: o serviço de autenticação retorna o token gerado em sua resposta (JSON?). O aplicativo front-end faz uma solicitação HTTP para o endpoint de autenticação do servidor de aplicativos, incluindo o token como um parâmetro, e após a validação pelo servidor de aplicativos, recebe um cookie de sessão em troca.
3. Se for um aplicativo autônomo (desktop ou móvel): Como para um SPA, mas usando uma biblioteca HTTP que oferece suporte a cookies, em vez de um aplicativo front-end em um navegador.

Em ambos os casos, o token JWT só será válido por algo como 5 minutos (para contabilizar a distorção do relógio) e usado uma vez - para trocá-lo por uma sessão no servidor de aplicativos. Se você incluir informações de perfil no token, o serviço de autenticação permanecerá completamente desacoplado do aplicativo.

EDIT: Adicionado caso de aplicação autônomo.

Vamos supor que estejamos no cenário de desenvolvimento de aplicativos móveis SPA / Híbrido. Suponha também que estamos usando apenas JWT para sessão - não OUATH com tokens de autenticação e de portador - apenas faça o login e receba o token de portador.
Vamos imaginar que temos um aplicativo em tempo real com cada sessão fazendo solicitações para todos os 3 serviços a cada 5-15 segundos. Muitos usuários fazem login para verificação rápida de status ou para postar dados GIS ou algo assim, o tempo médio de uso é inferior a 1 minuto, mas desejam iniciar o aplicativo - fechá-lo - reiniciar 3 dias depois sem credenciais etc. (adicionar detalhes que são irrelevantes aqui, mas coisas que me afastariam dos cookies)

Como exemplo, digamos que criei um serviço AWS com um serviço de consulta de gráfico, um mapeamento ou serviço GIS em um docker rackspace e uma interface REST para postgres db para gerenciar dados de perfil de usuário. Posso usar o mesmo JWT em solicitações de cabeçalho para todos os serviços REST e validar em relação a um segredo comum para ter a validação compartilhada do JWT emitida uma vez.
Vamos supor que eles tenham estado dentro de seu próprio contexto, mas apenas vagamente em um contexto compartilhado.
Estas são as especificações do problema que correspondem à minha solução proposta usando JWT como um token de sessão como um token do portador e, em um ambiente semelhante, estou perguntando como você abordaria o uso de cookies de sessão para que possamos comparar.

Digamos que todos eles exijam uma confiança razoável de que o usuário é quem diz ser.
Minha solução seria gerar um token JWT em resposta à postagem da credencial que é usada em todos os serviços dentro do cabeçalho HTTP para autenticação - com a validação sendo feita com o segredo JWT compartilhado em todos os serviços.
O serviço de autenticação gera o token e o retorna no login. O token é incluído nas solicitações de cabeçalho para todos os outros serviços em domínios diferentes. Se usar cookies, precisamos estabelecer novos cookies para cada domínio. Por que eu desejaria que os serviços que fazem novas solicitações validem ou obtenham um cookie para cada http recebido, quando posso confiar com segurança no JWT? Se eu tiver 5 serviços, agora preciso gerenciar 5 cookies de sessão diferentes e garantir a coordenação entre todos eles. Em muitos casos, essa pode ser a abordagem certa, mas em muitos parece-me excessivamente complexa para algo que é rápido e simples de implementar e não expõe brechas de segurança sérias que posso ver claramente.
Por que limitar o período de tempo do JWT? Os cookies são tradicionalmente de curta duração porque pressupõem contato regular com o servidor - e se eu não quiser expirar rapidamente, mas estou feliz por ter sessões desatualizadas de longa duração porque decido que a compensação de reautenticar é um risco maior.

Se bem entendi em sua situação, tenho 9 solicitações saltando a cada período em vez de 3. Tenho um servidor de autenticação sendo invadido para confirmar as sessões estabelecidas. Tenho mais código e mais peças móveis. Tenho a vantagem de poder encerrar as sessões a cada período, mas e se isso não for um requisito. E se eu não me importar em receber os dados postados por mais 48 horas após o desligamento do usuário e usar o servidor de autenticação para novas solicitações, ainda puder filtrar o que não preciso?

Nesse caso de uso, o menor desvio de tempo é irrelevante porque a granularidade da sessão está configurada apropriadamente e, como acontece com os cookies da sessão, eu implementaria o cliente atualizando o JWT por meio do servidor de autenticação no período de tempo limite apropriado. No que diz respeito ao 'perfil', vamos ficar com um uid de compartilhamento como o id comum (se bem entendi) e as implementações do lado do servidor contêm um segredo compartilhado para assinar / validar o JWT.

Em minha arquitetura proposta, não preciso revogar os tokens em uma granularidade mais fina do que a fornecida pelo tempo limite do JWT, então por que devo usar cookies de sessão?
Em minha arquitetura proposta, você poderia criar dependências entre os estados dos serviços, mas poderia arquitetar isso em vez de depender de ele ser centralizado e precisar conectar tudo de volta à autenticação por padrão. A chave é a flexibilidade - e isso tem o custo de perceber as dependências, mas isso está na sua cara desde o início e não uma camada sobre algo que, embora implementado em todas as plataformas, é tratado de forma diferente nos frameworks. Pode não ser trivial atualizar a expiração do cookie para uma sessão com nó, php e manipulação padrão de sessão de cookie exótico sem realmente e, portanto, você pode ser encorajado a apenas postar uma solicitação de servidor de autenticação diretamente para não apenas disparar 3 x o solicitações, mas há 3x as solicitações para o cliente.

Se eu alinhar com sua arquitetura proposta, então realmente preciso lidar com os tempos limite em vários cookies. Por exemplo, se o cliente fizer login e receber um cookie de sessão autenticado que expira em 1 hora
e, 40 minutos depois, eles postam esse valor de cookie de sessão em nosso primeiro serviço, que consulta o servidor de autenticação antes de emitir um cookie de domínio local, hackeamos a expiração do cookie de autenticação original interno ou definimos um tempo limite no cookie de serviço para 20 minutos e quando ele expira, acionar uma atualização do cookie de autenticação. A menos que eu esteja perdendo uma solução óbvia, isso pode facilmente se transformar em uma grande pilha de spagetti que poderia ser totalmente evitada usando um único JWT com um único ttl que poderia ser atualizado por qualquer um dos serviços (entendendo como isso possivelmente estende o token life) ou exigindo uma atualização por meio do servidor de autenticação.

Eu poderia discutir abordagens para dados obsoletos, mas o escopo do problema neste caso de uso não depende da invalidação de credenciais obsoletas (da perspectiva do servidor de autenticação), então isso não seria relevante.

É meu entendimento que estamos discutindo sua afirmação de que usar JWT como uma abordagem de gerenciamento de sessão autenticada é inerentemente inferior e incorreto em comparação com o uso de cookies de sessão como uma abordagem de gerenciamento de sessão autenticada para serviços de domínio cruzado em um aplicativo móvel híbrido a ser executado dispositivos de forma intermitente sem reabastecimento de credenciais.

Estou tentando verificar se você argumentaria que a abordagem proposta é inerentemente menos segura ou menos "correta" de alguma forma. A meu ver, há vantagens significativas na simplicidade desta arquitetura e nenhuma vantagem oferecida pela solução mais pesada e complexa necessária para gerenciar sessões em todos os serviços que não foram contabilizados e trocados pela arquitetura mais simples. Se você pudesse apontar como esta solução enfrentaria problemas que não ocorriam com o uso de cookies para gerenciar sessões, isso realmente me ajudaria a entendê-los explicitamente (ou seja, como a segurança está comprometida)

Os serviços quase não importam - não tem certeza do que está se referindo?

Há uma diferença entre serviços com e sem estado.

Digamos [...]

Isso descreve como você resolveria o problema, não qual é o problema _é_. Não é útil quando me pede para explicar como abordá-lo com sessões, porque já assume que você _não_ estará usando sessões. Em vez disso, descreva o problema.

quando posso confiar com segurança no JWT?

Você não pode.

Se eu tiver 5 serviços, agora preciso gerenciar 5 cookies de sessão diferentes e garantir a coordenação entre todos eles.

Improvável. Veja meu comentário sobre serviços com estado versus serviços sem estado.

Em muitos casos, essa pode ser a abordagem certa, mas em muitos parece-me excessivamente complexa para algo que é rápido e simples de implementar e não expõe brechas de segurança sérias que posso ver claramente.

Autenticação e gerenciamento de sessão, especialmente em arquiteturas distribuídas, _é_ complexo. Há uma razão pela qual os engenheiros evitaram arquiteturas distribuídas sempre que possível no passado. "Basta usar JWT" ignora isso e finge que é mais fácil do que realmente é, ignorando completamente a desatualização de dados e a invalidação de sessão.

As brechas de segurança estão aí, e eu fiz várias tentativas de explicá-las - que você não pode vê-las claramente, não é algo que eu possa fazer, se você não fizer perguntas específicas sobre as partes que não são claras para você .

Por que limitar o período de tempo do JWT?

No exemplo que dei? Porque eles são destinados como tokens de troca de uso único, não identificadores persistentes. Você não quer que eles sejam identificadores persistentes, porque você não pode revogá-los.

Os cookies são tradicionalmente de curta duração porque pressupõem contato regular com o servidor - e se eu não quiser expirar rapidamente, mas estou feliz por ter sessões desatualizadas de longa duração porque decido que a compensação de reautenticar é um risco maior.

Não há risco em atualizar uma sessão.

ignore profile or clock skew - detalhes que não têm um grande impacto em nossa discussão neste caso hipotético, visto que os mesmos problemas se aplicam ao usar cookies para um cenário semelhante.

Eles são uma parte tão importante de um sistema de autenticação robusto quanto todos os outros pontos mencionados. Ignorá-los não é uma opção. E, novamente, _não_ se trata de "cookies", trata-se de sessões.

Para sessões, não, os mesmos problemas _não_ se aplicam; um armazenamento de sessão centralizado / com estado significa que os dados não ficam obsoletos e as informações de perfil podem ser recuperadas a qualquer momento, e o clock skew é um problema para quaisquer tokens de validade limitada que são trocados entre sistemas diferentes.

Parece que poderíamos resumir sua objeção ao JWT, já que uma abordagem de gerenciamento de sessão pode se resumir a você anexar a uma definição de sessões que exige revogação por solicitação (e alguns outros recursos que tradicionalmente fazem parte da garantia de que um usuário está autorizado acessar) e o perigo associado ao atualizá-los (se forem interceptados). O processamento distribuído é a nova norma - vários serviços são muito comuns - se quisermos adotar esse tipo de abordagem para a arquitetura de vários serviços, precisamos entender totalmente as consequências. Os bancos de dados distribuídos existem há muito tempo. Armazenamentos de dados distribuídos, como DNS, existem desde o início. Às vezes, a simplicidade da arquitetura oferece mais benefícios do que tentar espremer o padrão dominante existente além de seus limites de design. Se estivermos cientes dos problemas de ACID transacionais em nossas sessões de solicitação de serviço, então não há razão para não adotarmos uma abordagem de gerenciamento de sessão JWT para autenticar serviços para explorar totalmente as possibilidades sem ser restringido pelo que rapidamente se torna uma infraestrutura complexa se insistirmos em restrições rígidas e tente cookies de sessão de calça de sapato como a solução que é superior.
@ joepie91 - quando apropriado, você pode usar autenticação de sessão de cookie para autenticação primária e exigir isso para atualizar o JWT. Novamente - o uso de JWT para acesso ao serviço de sessão de domínio cruzado pode ser usado como parte da solução e a sessão de cookie também pode ser usada se apropriado. A questão é que o JWT como parte do gerenciamento de sessão - mesmo para acessar um subconjunto de serviços - não é, acredito, uma abordagem maligna que não tem função.
Os cookies de sessão https também apresentam riscos - é surpreendente quantos sites têm o sinalizador ssl desmarcado e passam o cookie como texto simples ao se comunicarem com SSL. Isso torna as sessões de cookies perigosas?
O maior risco que pareço encontrar é que o codificador permite que o token seja enviado para o servidor errado e que o token permite efetivamente que um terceiro acesse esses recursos de usuário secundários. Isso deve ser sinalizado com grandes letras vermelhas em algum lugar e coloca um forte ônus sobre o desenvolvedor para garantir que isso não aconteça. O desenvolvedor deve tomar as medidas adequadas para garantir que as medidas de segurança necessárias tenham sido tomadas e um repo como este deve explicar algumas dessas abordagens e incluí-las nos exemplos. Em minha opinião, este é um preço aceitável a pagar pela flexibilidade da autenticação de serviço com limite de tempo entre domínios para serviços não críticos.
Ao arquitetar uma solução complexa, é provável que inclua cookies de sessão no final de autenticação e pode ser estendido para incluir tokens únicos etc. quando apropriado. A questão é que isso é possível e, embora haja lugares em que pode dar errado e expor riscos, oferece a oportunidade de construir aplicativos mais ricos e mais enxutos em muitos casos e, por esse motivo, não acredito que este repo deva ser descartado como sugerido pelo registrador de problemas.
A inclinação para tentar obter o melhor dos dois mundos usando JWT como string de sessão para mim parece introduzir problemas - mais notavelmente os períodos de tempo limite / TTL possivelmente conflitantes. Ele também impõe as mesmas restrições de acesso ao domínio que podemos ter tentado evitar em primeiro lugar, então colocar isso no exemplo básico pode levar as pessoas a perguntarem por que usar o JWT em primeiro lugar?

O uso de JS como uma dependência é muito pequeno - no contexto do SPA móvel híbrido, é improvável que você precise acomodar um cliente livre JS. Sugerir que isso é um problema enquanto afirma que o redis fornece uma opção eficiente para armazenamento de sessão parece um pouco contraditório.
A expiração no JWT não é inútil, pois fornece um tempo limite de sessão que deve ser tratado por atualização (exatamente como as sessões de cookie são atualizadas) ou requer reautenticação. Ter o JWT assinado garante que ele não foi adulterado e, portanto, elimina o requisito absoluto de validação em relação ao armazenamento persistente do lado do servidor, embora isso possa ser feito se desejável e obtenha o mesmo resultado que as sessões de cookies sem tanta implementação opinativa e com o capacidade de utilizar domínios cruzados, se adequado. Em um aplicativo móvel híbrido, o armazenamento de cookies ou JWT no armazenamento local oferece mais controle. Objeções ao uso de armazenamento local sobre a segurança da implementação do navegador é uma questão de confiança no fornecedor e aceitação do manuseio dessas credenciais.
A flexibilidade é útil para muitos desenvolvedores de SPA híbridos móveis, mas requer uma compreensão de quais são as limitações.
O JWT pode ser invalidado simplesmente mudando a chave de assinatura e, novamente, isso oferece flexibilidade - você pode usar uma chave de assinatura privada compartilhada comum entre serviços ou gerar dados aleatórios por sessão de usuário e perceber o tipo de benefícios de repúdio dos cookies de sessão.
Quase todos os frameworks JS modernos suportam JWT e seria difícil encontrar uma plataforma principal que não o fizesse - alguns, entretanto, provavelmente não deveriam (plugin Wordpress JWT .. hmm .. não olhei, mas me deixa nervoso).
O uso de JWT deve incluir experiência em OAUTH e as vantagens e desvantagens de usar sessões de cookies. Para mim, existem vantagens reais de trabalho para desenvolvedores híbridos móveis médios que usam vários serviços, mas existem armadilhas que são fáceis de cair. Podemos precisar de muitos exemplos para ilustrar completamente.

Meu _ raciocínio original_ para usar um JWT como token para autorização é que a verificação de um JWT é vinculado à CPU (_my "antigo" laptop pode verificar 180k JWTs por segundo_) em contraste, se usarmos um token simples e tivermos que procurá-lo na memória (ou em um banco de dados), a operação seria vinculada à E / S (_ou pior,
http://stackoverflow.com/questions/868568/what-do-the-terms-cpu-bound-and-io-bound-mean

Nosso sistema de gerenciamento de sessão _primeiro_ verifica se o JWT é válido, verificando se foi _assinado_ usando nossa chave - e rejeita uma mensagem _ cedo_ se não foi - e _então_ verifica se a sessão ainda não foi invalidada (por exemplo, pelo usuário se desconectar) .

Sei que os JWTs podem não ter sido _desenvolvidos_ para serem usados ​​como tokens nos cabeçalhos de autorização, mas não acho que compreendo _certamente_ por que é uma "má ideia", visto que é _mais rápido_ do que outros sistemas de gerenciamento de sessão ...

Nota: Eu ainda concordo que o ângulo "sem cookies" não é a maneira certa de iniciar este leiame / tutorial. 👍