Considere o primeiro caso. Cada cliente recebe um ID aleatório que dura a duração da sessão - o que pode levar vários dias, se desejar. Então você armazena as informações relevantes para aquela sessão em algum lado do servidor. Pode estar em um arquivo ou banco de dados. Vamos supor que você passe o ID por meio de um cookie, mas você pode usar o URL ou um cabeçalho HTTP.
IDs de sessão / cookies
Prós:
- Fácil de codificar o cliente e o servidor.
- Fácil de destruir uma sessão quando alguém faz logout.
Contras:
- O servidor periodicamente precisa excluir as sessões expiradas em que o cliente não efetuou o logout.
- Toda solicitação HTTP exige uma pesquisa no armazenamento de dados.
- Os requisitos de armazenamento aumentam à medida que mais usuários têm sessões ativas.
- Se houver vários servidores HTTP front-end, os dados da sessão armazenada precisam estar acessíveis a todos eles. Isso poderia ser um pouco mais de trabalho do que armazená-lo em um servidor. Os problemas maiores são o armazenamento de dados se torna um ponto único de falha e pode se tornar um gargalo.
JSON Web Tokens (JWT)
No segundo caso, os dados são armazenados em um JWT transmitido em vez de no servidor.
Prós:
- Os problemas de armazenamento do lado do servidor desapareceram.
- O código do lado do cliente é fácil.
Contras:
- O tamanho do JWT pode ser maior que um ID de sessão. Isso pode afetar o desempenho da rede, já que está incluído em cada solicitação HTTP.
- Os dados armazenados no JWT podem ser lidos pelo cliente. Isso pode ser um problema.
-
O lado do servidor precisa de código para gerar, validar e ler JWTs. Não é difícil, mas há uma curva de aprendizado e a segurança depende disso.
Qualquer pessoa que receber uma cópia da chave de assinatura poderá criar JWTs. Você pode não saber quando isso acontece.
Houve (é?) um erro em algumas bibliotecas que aceitaram qualquer JWT assinado com o algoritmo "nenhum", para que qualquer pessoa pudesse criar JWTs em que o servidor confiaria.
-
Para revogar um JWT antes que ele expire, você precisa usar uma lista de revogação. Isso faz com que você volte aos problemas de armazenamento do servidor que estava tentando evitar.
OAuth
Geralmente, o OAuth é usado para autenticação (ou seja, identidade), mas pode ser usado para compartilhar outros dados, como uma lista de conteúdo que o usuário comprou e está autorizado a fazer o download. Também pode ser usado para conceder acesso para gravar dados armazenados pelo terceiro. Você pode usar o OAuth para autenticar usuários e usar o armazenamento no servidor ou o JWT para os dados da sessão.
Prós:
- Nenhum código para os usuários registrarem ou redefinirem suas senhas.
- Nenhum código para enviar um email com um link de validação e validar o endereço.
- Os usuários não precisam aprender / escrever outro nome de usuário e senha.
Contras:
- Você depende do terceiro para que seus usuários usem seu serviço. Se o seu serviço cair ou eles pararem, então você precisa descobrir outra coisa. Por exemplo: como você migra os dados da conta do usuário se a identidade deles mudar de "[email protected]" para "[email protected]"?
- Normalmente você tem que escrever código para cada provedor. por exemplo, Google, Facebook, Twitter.
- Você ou seus usuários podem ter preocupações com a privacidade. Os provedores sabem quais usuários usam seu serviço.
- Você está confiando no provedor. É possível que um provedor emita tokens válidos para um usuário para outra pessoa. Isso pode ser para fins legais ou não.
Diversos
- Tanto os IDs de sessão quanto os JWTs podem ser copiados e usados por vários usuários. Você pode armazenar o endereço IP do cliente em um JWT e validá-lo, mas isso impede que os clientes façam roaming, digamos, de Wi-Fi para celular.