Precisas de construir a tua própria autorização para aplicações?

Antecedentes#

Já vi muitos desenvolvedores a fazerem perguntas como "Devo construir a minha própria autorização para a minha aplicação?". Embora a resposta não possa ser um simples "Sim" ou "Não", gostaria de escrever um artigo para descontruir a implementação e demonstrar os prós e os contras para te ajudar a decidir.

TL;DR É necessário encontrar uma solução existente que se ajuste às tuas necessidades, a menos que realmente queiras o controlo total ou ainda estejas a aprender desenvolvimento de software.

Introdução#

Como desenvolvedor, construí muitas aplicações durante a minha carreira. Independentemente da linguagem de programação, existe sempre uma base comum que preciso de construir: a autorização do usuário.

Era uma parte negligenciável, uma vez que tudo era direto há 20 anos atrás:

• Implementar um sistema de registo e de autenticação com nome de usuário e password.
• Criar um mecanismo para manter a sessão de um usuário.
• No que toca à segurança? MD5 é a resposta.

E é isto. A partir daqui, eu podia focar-me "no verdadeiro negócio". Não ouviste falar de MD5? Perdeste os "bons velhos tempos" de desenvolvimento de software. Hoje em dia, os desenvolvedores enfrentam mais desafios ao construir o registo e autenticação de usuários.

Pode parecer alarmante, mas deixem-me dar um exemplo.

Exemplo: Uma livraria online#

Vamos supor que estás a tentar construir uma livraria online com um serviço API e uma aplicação de frontend web.

Em primeiro lugar, o âmbito da "autorização" deve ser definido. A autorização pode ser explicada como autenticação e permissão, e elas têm definições totalmente diferentes e casos de uso:

Escrevi um artigo CIAM 101: Autenticação, Identidade, SSO para discutir estes conceitos em detalhe.

Escolher métodos de autenticação#

Vamos começar com a "autenticação", que é o login do usuário no nosso exemplo. Além do método de nome de usuário e password, aqui estão alguns métodos populares que as pessoas estão a adotar para uma melhor conversão de usuário e segurança:

• Sem password, ou seja, código de verificação dinâmico (via email ou sms)
• Início de sessão através das redes sociais (Google, Facebook, etc.)

A escolha do método depende da decisão do negócio, enquanto podemos dar uma olhada no esforço tecnológico:

• Para a ausência de password, precisas encontrar um fornecedor para enviar códigos de verificação por e-mail ou sms; depois integrá-lo com o teu serviço API (podem ser necessárias novas APIs).
• Para o início de sessão através das redes sociais, tens de aderir às diretrizes de integração do(s) provedor(es) de identidade social que desejas usar. Além disso, deves criar um mapeamento entre as IDs de usuário da tua livraria e o provedor de identidade.
  • Por exemplo, quando um usuário inicia sessão com uma conta Gmail [email protected], podes associar este endereço de e-mail ao usuário foo na livraria. Este processo ajuda-te a construir um sistema de identidade unificado e permite ao usuário modificar ou desvincular a sua identidade social no futuro.

Desenhar e implementar a experiência de início de sessão#

Depois de decidires os métodos de autenticação, uma experiência de início de sessão elegante e suave para os teus usuários finais é o próximo objetivo. A conversão aqui é fundamental, mas crucial para o negócio, pois é uma maneira natural de deixar os dados do cliente persistidos.

Quando eu trabalhava para a Airbnb, havia uma equipa inteira dedicada a otimizar a experiência de início de sessão para várias plataformas. Eles realizaram inúmeros testes A/B para determinar qual combinação tinha a maior taxa de conversão.

Não é prático fazer isso quando um negócio está a começar. Mas ainda precisamos de tentar ao máximo fazer tudo correto. Em quais plataformas gostarias de executar a livraria? Podes começar com o mobile, web, ou ambos. O design exato dependerá dos métodos de autenticação que escolheste:

• Nome de usuário e password: O mais fácil, apenas algumas caixas de entrada e botões.
• Sem password: Insira o telefone / e-mail, em seguida, enviar e verificar um código dinâmico.
• Início de sessão através das redes sociais: Lê a documentação do provedor de identidade social escolhido, segue as diretrizes visuais, lida com a lógica de redirecionamento, e finalmente, associa a identidade social à identidade na livraria.

Mais coisas a considerar para melhorar:

• Precisas de combinar o processo de início de sessão e de registo para um método específico?
• Precisas de um fluxo de "esqueci a password" para permitir aos clientes redefinir as suas passwords de forma independente?

Se optares pelo desenvolvimento nativo, a carga de trabalho irá quase dobrar para uma plataforma adicional.

Segurança e troca de tokens#

A segurança pode ser um iceberg oculto. Será ótimo se estiveres familiarizado com o OpenID Connect ou com o OAuth 2.0, pois são amplamente usados e comprovados. O OpenID Connect é relativamente novo, mas está desenhado para a "autenticação do usuário", que se ajusta perfeitamente a uma livraria online.

Sem aprofundar os detalhes dos padrões, ainda há algumas coisas a considerar:

• Que método de encriptação deve ser utilizado para as passwords?
• Qual é o processo para a autenticação e permissão padrão?
• Como funciona a troca de tokens (Token de Acesso, Token de Atualização, Token ID, etc.)?
• Como podem ser usadas chaves de assinatura nos tokens e como pode a assinatura ser validada para proteger os recursos?
• Como é que podem ser prevenidos os ataques do cliente e do servidor?

Finalmente, podes garantir uma boa experiência de início de sessão e entregá-la aos teus clientes.

Modelo de permissão#

Como livraria, precisas de separar os recursos para os clientes e para os vendedores. Por exemplo, os clientes podem navegar por todos os livros, enquanto os vendedores podem gerir os seus livros à venda. É aceitável começar com verificações simples de if-else; no entanto, à medida que o negócio cresce, podes precisar de tirar proveito de um modelo mais flexível como o Controle de Acesso baseado em Funções (RBAC) ou o Controle de Acesso baseado em Atributos (ABAC).

Eu também escrevi um artigo CIAM 102: Permissão & Controle de Acesso baseado em Funções para demonstrar os conceitos básicos de permissão e o modelo RBAC.

Tomar a decisão#

Podes ver que a autorização não é um problema de "tudo ou nada", uma vez que envolve múltiplos componentes técnicos e tu ou a tua equipa podem ter diferentes competências técnicas nestas áreas. É importante dividi-la em partes menores para ganhar um melhor entendimento da situação atual.

Para tomar a decisão, vou fazer-me as seguintes perguntas:

• Quão urgente é o projeto?
• Quanto esforço espero colocar na autorização versus o negócio?
• Qual é a prioridade da experiência do usuário, segurança e manutenibilidade?
• De que parte(s) preciso de ter o controlo total? Quão familiarizado devo estar com elas?
• Se eu for com alguns frameworks / soluções, eles são bons o suficiente para a personalização ou extensão?
• Se o negócio crescer, vou precisar de introduzir um novo modelo de autenticação?
• Se encontrar um fornecedor adequado, é seguro o suficiente para usar? Preciso de um plano de retirada se algo acontecer ao fornecedor?

Com as perguntas em mente, descobri dois fatos:

• Construir um sistema de autenticação fiável é altamente complexo.
• Os vendedores existentes não conseguem cumprir todos os critérios necessários.

Então decidi começar um projeto dedicado (Logto) para a autorização, e abraçar a comunidade de open-source desde o primeiro dia.

Espero que este artigo te ajude.