Dê o próximo passo e inicie sua carreira
Dê o próximo passo e inicie sua carreira agora mesmo
7 minutos de leitura
Autor(a)
Fique por dentro de conteúdos, insights e oportunidades do universo tech. Receba novidades e lançamentos direto no seu e-mail.
Antes de começar a discutir tipos de autenticação, precisamos nos perguntar: por que essa técnica é tão necessária em aplicações de qualquer tipo?
Vamos imaginar o seguinte cenário: é dia 23 de dezembro e devido à correria de fim de ano, para não enfrentar a bagunça de uma megastore, você opta por fazer compras no e-commerce de sua preferência. Em muitos casos, será necessário confirmar no site da loja que você é você mesmo, muito provavelmente informando seu usuário e senha. O porquê disso é bastante simples: segurança.
Todos querem se sentir seguros na utilização de algum sistema, sobretudo quando temos que fornecer algum dado sensível (CPF, identidade, dados bancários e assim por diante). Por meio dos métodos de autenticação, evitamos fraudes e o uso indevido de informações em ambientes digitais.
Por isso, vamos ver alguns tipos de autenticação que podemos implementar em nossos sistemas.
Lembre-se que, dependendo da complexidade e dos requisitos de segurança da sua aplicação, você pode optar por utilizar mais de um método de autenticação. Os tipos mais empregados durante o desenvolvimento são:
A utilização de PINs, usuário ou senha, é uma das formas mais básicas e simples de implementarmos autenticação em sistemas, partindo do pressuposto que somente o usuário possui essas informações de acesso.
Neste modelo depende do usuário a proteção dos seus dados, já que cada um escolhe qual será a sua senha ou PIN, por exemplo. Um problema é que hackers podem conseguir capturar essas informações, abrindo uma brecha no esquema de segurança proposto.
Este tipo de autenticação baseia-se na leitura de alguma característica física única do indivíduo, como uma digital, verificação de íris, ou até mesmo a voz. Esta é uma maneira bastante efetiva para os sistemas validarem se a pessoa que solicita o acesso é quem realmente diz ser.
Neste método, a ideia principal para a autenticação é a adição de mais uma camada de segurança ao acesso de nossas aplicações. Sendo assim, o usuário precisa de informações adicionais para terminar de acessar.
Por exemplo, em uma primeira etapa, a aplicação solicita um pin. Além disso, encaminha um código que vai complementar a autenticação para algum canal de comunicação do usuário, como celular ou e-mail.
Um ponto de atenção nesta abordagem é que o usuário deve necessariamente ter o canal adicional disponível no processo de login. Se tivermos que inserir usuário e senha nos campos de uma página web na primeira etapa do acesso e na sequência esperar o envio de um código por SMS para o celular, precisamos estar com o aparelho para terminar o acesso.
Este foi um dos primeiros métodos de autenticação, criado no início do desenvolvimento das aplicações web. Muito empregado até hoje, neste modelo o usuário pode se autenticar com usuário e senha ou por algum outro método.
O servidor, por sua vez, cria uma sessão em sua memória ou banco e devolve a informação de usuário através de um cookie com o identificador da sessão criada.
Na próxima requisição, é passado o identificador da sessão e o servidor devolve o acesso ao recurso solicitado ou realiza algum outro tipo de manipulação referente à conta autenticada.
Neste método, após ter um login e senha validados pelo servidor, será criado um token que o usuário receberá em resposta e que permitirá o acesso a algum recurso. O padrão adotado por grande número das aplicações web hoje é o formato JWT (JSON Web Token) e ele fará com que o token seja assinado da forma correta para haver a autenticação da requisição a um recurso no servidor.
É importante salientar que informações do usuário não ficarão salvas no servidor. Elas são gravadas no token, que tem um período geralmente curto para expiração, por volta de 10 minutos. O tempo dependerá dos requisitos de segurança da aplicação.
Se um token chegar a expirar, uma solução seria pedir ao servidor um novo token válido. Isso acarretaria um novo processo de autenticação por login e senha ou por outro método escolhido. Porém, não é prático que a aplicação solicite usuário e senha novamente a cada expiração. Uma estratégia para lidar com essa situação seria usar refresh token.
Como uma solução comum, costuma-se enviar tanto o token de acesso quanto o refresh token, assim que a autenticação na aplicação é realizada. No entanto, o refresh token possui um tempo maior para a expiração, e neste caso não armazenamos nenhuma informação de usuário.
Outra característica do refresh token é que ele é de uso único, então na próxima solicitação é enviado um token e um novo refresh token.
Apresentadas as características destes dois métodos vamos ver agora uma comparação entre eles.
Na autenticação por sessão, o estado da sessão é mantido pelo servidor com as informações do usuário, podendo ser armazenado em um banco de dados ou na memória (Stateful). Com essa estratégia, podemos nos deparar com problemas como limites de hardware. Um consumo excessivo de memória pode causar até o travamento da máquina, dada a quantidade de chamadas para o garbage collector.
Quando utilizamos autenticação por Token JWT, o cenário muda um pouco, já que as informações não são mais mantidas no servidor (Stateless), e sim no token, na máquina do cliente. O token carregará todas as informações necessárias para a autenticação, como a identificação do usuário, assinatura, data de expiração e até o método de autenticação utilizado.
Mas de maneira prática, como diferenciar os dois modelos de autenticação? A princípio são bem similares. O que vai diferenciá-los de maneira mais efetiva será guardar ou não o estado no servidor (stateless/stateful) o que irá impactar na forma de implementar escalabilidade, para que nosso sistema lide com uma carga maior de trabalho.
No tempo de vida de uma aplicação de qualquer tipo é muito comum que ela comece a demandar mais recursos para sua operação. Esse crescimento deve ser ordenado e suportado de maneira a não afetar a utilização do sistema, o que chamamos de escalabilidade.
A implementação de segurança através de um dos métodos de autenticação traz alguns desafios à escalabilidade da aplicação. Se optarmos por usar sessões, o controle tende a ficar complexo, pois o estado pode estar espalhado por diversos servidores e/ou instâncias.
Neste contexto, é comum haver a figura do balanceador de carga (load balance), responsável por distribuir a carga de requisições aos recursos entre os demais servidores que mantém a aplicação.
No caso da autenticação por sessão, como podemos garantir que a sessão correta será devolvida para o cliente? Trabalhar com o conceito de Sticky Session pode ser útil, já que em cenários com load balance, esta técnica vincula uma sessão de usuário a um servidor/instância específico.
Escalar uma aplicação é muito importante e devemos usar métodos de autenticação que atendam a esse requisito, garantindo assim maior segurança na utilização de sistemas por nossos usuários.
Independentemente do método a ser adotado, o importante é que ao projetar uma solução de software o desenvolvedor “fique ligado” na implementação de métodos de autenticação que possibilitem a escalabilidade da aplicação com o menor transtorno, além de uma manutenção sem estresse.
Para aprender mais sobre autenticação e segurança, veja:
Avalie este artigo
