os meandros da autenticação baseada em Token

introdução

a autenticação baseada em Token é proeminente em toda a web hoje em dia. Com a maioria das empresas da web usando uma API, os tokens são a melhor maneira de lidar com a autenticação para vários usuários.

existem alguns fatores muito importantes ao escolher a autenticação baseada em token para seu aplicativo. As principais razões para os tokens são:

  • servidores sem estado e escaláveis
  • aplicativo móvel pronto
  • passar autenticação para outros aplicativos
  • segurança Extra

quem usa autenticação baseada em Token?

qualquer grande API ou aplicativo da web que você encontrou provavelmente usou tokens. Aplicativos como Facebook, Twitter, Google+, GitHub e muito mais usam tokens.

vamos dar uma olhada exatamente como funciona.

por que os Tokens surgiram

Antes de podermos ver como a autenticação baseada em tokens funciona e seus benefícios, temos que observar como a autenticação foi feita no passado.

autenticação baseada em servidor (o método tradicional)

como o protocolo HTTP não tem estado, isso significa que, se autenticarmos um usuário com um nome de usuário e senha, na próxima solicitação, nosso aplicativo não saberá quem somos. Teríamos que nos autenticar novamente.

a maneira tradicional de fazer com que nossos aplicativos se lembrem de quem somos é armazenar as informações de login do usuário no servidor. Isso pode ser feito de algumas maneiras diferentes na sessão, geralmente na memória ou armazenada no disco.

como a web, aplicativos e a ascensão do aplicativo móvel surgiram, esse método de autenticação mostrou problemas, especialmente na escalabilidade.

os problemas com autenticação baseada em servidor

alguns problemas importantes surgiram com este método de autenticação.

  • sessões: Toda vez que um usuário é autenticado, o servidor precisará criar um registro em algum lugar do nosso servidor. Isso geralmente é feito na memória e quando há muitos usuários autenticando, a sobrecarga em seu servidor aumenta.Escalabilidade: como as sessões são armazenadas na memória, isso fornece problemas de escalabilidade. À medida que nossos provedores de nuvem começam a replicar servidores para lidar com a carga do aplicativo, ter informações vitais na memória da sessão limitará nossa capacidade de dimensionar.
  • CORS: Como queremos expandir nosso aplicativo para permitir que nossos dados sejam usados em vários dispositivos móveis, precisamos nos preocupar com o compartilhamento de recursos de origem cruzada (CORS). Ao usar chamadas AJAX para obter recursos de outro domínio (móvel para nosso servidor API), poderíamos ter problemas com solicitações proibidas.
  • CSRF: também teremos proteção contra falsificação de solicitação entre sites (CSRF). Os usuários são suscetíveis a ataques CSRF, pois já podem ser autenticados com um site bancário e isso pode ser aproveitado ao visitar outros sites.

com esses problemas, a escalabilidade sendo a principal, fazia sentido tentar uma abordagem diferente.

como funciona baseado em Token

a autenticação baseada em Token não tem estado. Não estamos armazenando nenhuma informação sobre nosso usuário no servidor ou em uma sessão.

este conceito sozinho cuida de muitos dos problemas com a necessidade de armazenar informações no servidor.

nenhuma informação de sessão significa que seu aplicativo pode escalar e adicionar mais máquinas, conforme necessário, sem se preocupar com onde um usuário está logado.

Embora essa implementação pode variar, a essência do que é da seguinte maneira:

  1. O usuário Solicita Acesso com nome de utilizador / palavra-Passe
  2. Aplicação valida as credenciais
  3. Aplicativo fornece um token assinado para o cliente
  4. Cliente lojas que token e envia-o juntamente com todo o pedido
  5. Servidor verifica token e responde com dados

Cada solicitação requer o token. Este token deve ser enviado no cabeçalho HTTP para que possamos manter a ideia de solicitações HTTP sem estado. Também precisaremos definir nosso servidor para aceitar solicitações de todos os domínios usando Access-Control-Allow-Origin: *. O que é interessante sobre designar * no cabeçalho ACAO é que ele não permite que solicitações forneçam credenciais como autenticação HTTP, certificados SSL do lado do cliente ou cookies.

depois de autenticarmos com nossas informações e tivermos nosso token, podemos fazer muitas coisas com esse token.

poderíamos até criar um token baseado em permissão e passar isso para um aplicativo de terceiros (digamos, um novo aplicativo móvel que queremos usar), e eles poderão ter acesso aos nossos dados-mas apenas as informações que permitimos com esse token específico.

os benefícios dos Tokens

stateless e Scalable

Tokens são armazenados no lado do cliente. Completamente apátrida e pronta para ser dimensionada. Nossos balanceadores de carga podem passar um usuário para qualquer um de nossos servidores, pois não há informações de estado ou sessão em nenhum lugar.

se mantivéssemos as informações da sessão em um usuário conectado, isso exigiria que continuássemos enviando esse usuário para o mesmo servidor em que eles fizeram login (chamado session affinity).

isso traz problemas, pois alguns usuários seriam forçados ao mesmo servidor e isso poderia causar um tráfego intenso.

não se preocupe embora! Esses problemas se foram com tokens, já que o próprio token contém os dados para esse usuário.

segurança

o token, não um cookie, é enviado em todas as solicitações e, como não há cookie sendo enviado, isso ajuda a evitar ataques CSRF. Mesmo que sua implementação específica armazene o token dentro de um cookie no lado do cliente, o cookie é apenas um mecanismo de armazenamento em vez de um autenticação. Não há informações baseadas em sessão para manipular, pois não temos uma sessão!

o token também expira após um determinado período de tempo, portanto, um usuário será obrigado a fazer login novamente. Isso nos ajuda a ficar seguros. Há também o conceito de revogação de token que nos permite invalidar um token específico e até mesmo um grupo de tokens com base na mesma concessão de autorização.

extensibilidade (amigo de um amigo e permissões)

Tokens nos permitirão construir aplicativos que compartilham permissões com outro. Por exemplo, vinculamos contas sociais aleatórias às nossas principais, como Facebook ou Twitter.

quando fazemos login no Twitter por meio de um serviço (digamos Buffer), estamos permitindo que o Buffer publique em nosso fluxo do Twitter.

usando tokens, é assim que fornecemos permissões seletivas para aplicativos de terceiros. Poderíamos até construir nossa própria API e distribuir tokens de permissão especiais se nossos usuários quisessem dar acesso aos seus dados para outro aplicativo.

múltiplas plataformas e domínios

falamos um pouco sobre CORS anteriormente. Quando nosso aplicativo e serviço se expandirem, precisaremos fornecer acesso a todos os tipos de dispositivos e aplicativos (já que nosso aplicativo definitivamente se tornará popular!).

tendo nossa API apenas servir dados, também podemos fazer a escolha de design para servir ativos de um CDN. Isso elimina os problemas que CORS traz à tona depois de definir uma configuração de cabeçalho rápido para o nosso aplicativo.

Access-Control-Allow-Origin: *

nossos dados e recursos estão disponíveis para solicitações de qualquer domínio agora, desde que um usuário tenha um token válido.

baseado em padrões

ao criar o token, você tem algumas opções. Estaremos mergulhando mais neste tópico quando protegermos uma API em um artigo de acompanhamento, mas o padrão a ser usado seria JSON Web Tokens.

este prático depurador e gráfico de biblioteca mostra o suporte para tokens da Web JSON. Você pode ver que ele tem uma grande quantidade de suporte em uma variedade de idiomas. Isso significa que você pode realmente mudar o seu mecanismo de autenticação se você optar por fazê-lo no futuro!

conclusão

esta foi apenas uma olhada no como e por que da autenticação baseada em token. Como é sempre o caso no mundo da segurança, há muito mais em cada tópico e varia de acordo com o caso de uso. Nós até mergulhamos em alguns tópicos sobre escalabilidade que também merecem sua própria conversa.

esta foi uma visão geral rápida de alto nível, então sinta-se à vontade para apontar qualquer coisa que tenha sido perdida ou quaisquer perguntas que você tenha sobre o assunto.

em nosso próximo artigo, veremos a anatomia dos Tokens da Web JSON.

Nota: adicionando informações de cabeçalho ACAO e esclarecimentos CSRF (graças a Emily Stark para as informações do artigo)

Leave a Reply

Deixe uma resposta

O seu endereço de email não será publicado.