Cookies: na versão inicial, um arquivo de texto com um ID de cliente exclusivo e todas as outras informações necessárias sobre o cliente (por exemplo, funções)
Cookies são tuplas key-valueoriginalmente endereçadas para reter dados relacionados à atividade do cliente. Essa retenção é o que conhecemos como estado da sessão ou aplicativo . Fundamentalmente, eles foram feitos para manter o estado dos aplicativos da web; mais especificamente, o estado no lado do cliente. (1)
Os cookies geralmente são definidos pelo servidor por meio de cabeçalhos de resposta ( Set-Cookie key=value). No entanto, eles também podem ser definidos pelo cliente. Por exemplo, por DOM ( document.cookie).
Uma coisa importante a saber sobre cookies é que eles não identificam usuários. Eles preferem associar os dados terna - cliente - servidor / caminho . (3)
Geralmente, associamos cookies a arquivos, porque durante os primeiros dias dos navegadores da Web eles precisavam persistir de alguma forma, sendo os arquivos o suporte mais viável. Os navegadores de hoje armazenam cookies (entre outras coisas) em armazenamentos locais (bancos de dados incorporados).
Sessão: apenas o ID do cliente exclusivo é enviado em um arquivo (também chamado de cookie); todo o resto é armazenado no servidor.
Por sessão, acho que você quer dizer sessões de servidor . Como comentei, as sessões também podem ser implementadas no lado do cliente. A diferença com as sessões do lado do cliente é que os dados são armazenados em algum lugar do lado do servidor. (2) Em tais cenários, o que obtemos é um ID de sessão; e nós o obtemos em forma de cookie. Sem o ID da sessão, o servidor não conseguiria correlacionar as solicitações recebidas com a atividade anterior do cliente. (3) Por exemplo, o usuário autenticado, o carrinho de compras etc.
De qualquer forma, um ID de sessão não identifica necessariamente um usuário. Ele associa um estado de aplicativo específico a um cliente da web. As sessões podem ou não conter dados do usuário.
Nos aplicativos distribuídos, a sessão deve ser serializada por razões óbvias. Se eles estiverem armazenados na memória, o armazenamento na memória (componente) deve ser serializável. Uma solução comum é armazenar sessões em arquivos. Ou no NoSQL DB como Redis.
Em relação à segurança. As sessões do lado do servidor são mais seguras que do lado do cliente. Os clientes são mais vulneráveis a ameaças porque os usuários geralmente desconhecem as tantas ameaças às quais estão expostos. Pelo menos não o usuário comum.
Por outro lado, atacar uma infra-estrutura do lado do servidor não é rival.
JWT: tudo é armazenado no token (que também pode ser armazenado em um arquivo de texto, também chamado de cookie)
Na verdade não. A JWT armazena dados principalmente relacionados à autorização e ao emissor do token.
Embora eles usem para conter o ID do usuário (sub), encontramos JWTs que não identificam usuários autenticados. Por exemplo, tokens para sessões de convidados. O conteúdo principal das JWTs são reivindicações ; itens a serem verificados pelo processo de autorização.
É importante ter em mente que as JWTs não são armazenamentos globais . A sessão ou o estado do aplicativo ainda precisa ser armazenado em algum lugar e gerenciado de forma independente.
Em relação às JWTs, elas geralmente são armazenadas como cookies, embora também possam ser armazenadas em armazenamentos locais. Além disso, a comunidade OWASP considera o sessionStorage o mais seguro para navegadores da web. No entanto, isso depende da versão do navegador .
1: A World Wide Web deve ser apátrida. Se quisermos criar aplicativos do lado do servidor sem estado, as sessões deverão ser armazenadas em algum lugar do lado do cliente.
2: Transformando o aplicativo do servidor em um aplicativo com estado .
3: Cliente como aplicativo, não como usuário.
user_idcom um usuário logado.