A autenticação verifica a identidade de um usuário (ou de um cliente ou serviço, em um contexto de comunicação de máquina para máquina) antes do acesso a um recurso protegido. A autenticação responde à pergunta fundamental: "Quem é você?".

Antes de conceder acesso, qualquer aplicação deve confirmar se a entidade solicitante é quem alega ser. A autenticação é o primeiro passo no controle de acesso e sempre precede a autorização. É necessário verificar uma identidade antes de determinar a que tipo de acesso ela tem permissão.

Usuários e serviços comprovam sua identidade apresentando credenciais ou fatores de verificação que o sistema valida comparando-os com registros armazenados ou com um provedor de identidade (IdP) externo confiável. Imagine um desenvolvedor apresentando uma chave Secure Shell (SSH) a um servidor remoto: o servidor verifica a assinatura da chave para confirmar a identidade do cliente.

Por que é importante: a autenticação estabelece a identidade antes de conceder acesso. Sem uma identidade verificada, sua aplicação não pode aplicar políticas de autorização, proteger dados sensíveis ou manter trilhas de auditoria.

Os fatores de autenticação são classificados em três categorias distintas. A segurança inerente da autenticação multifatorial (MFA) vem da combinação de fatores de duas ou mais categorias diferentes.

Categoria do fator	Mecanismo de prova	Exemplo comum
Conhecimento (algo que você sabe)	Um segredo memorizado pelo usuário	Senha, número de identificação pessoal (PIN), frase secreta
Posse (algo que você tem)	Um dispositivo físico ou token sob o controle do usuário	Smartphone (para TOTP/Push), chave de segurança de hardware, chave FIDO2/WebAuthn, Smart Card
Inerência (algo que você é)	Uma característica biológica única e verificável	Impressão digital, reconhecimento facial, leitura da íris

Além das senhas básicas, existem diversos métodos de autenticação, cada um com vantagens e desvantagens diferentes em termos de segurança e usabilidade.

Autenticação baseada em senha

A autenticação baseada em senha é o método mais comum. Os usuários fornecem credenciais, que são verificadas em relação a registros armazenados com segurança.

O armazenamento seguro de senhas exige algoritmos de hash adaptativos e computacionalmente caros, como Argon2, bcrypt ou PBKDF2, sempre com salts exclusivos para cada senha (NIST SP 800-63B). Nunca use algoritmos legados como MD5 ou SHA-1.

Vulnerabilidades de senha:

• Phishing e malware roubam senhas diretamente.
• A reutilização de senhas em diferentes sites permite que uma única violação comprometa várias contas.
• Senhas fracas que os usuários escolhem por serem fáceis de lembrar..
• O preenchimento de credenciais usa listas de senhas vazadas em violações de segurança anteriores.

A autenticação apenas por senha não é suficiente para sistemas de produção.

Autenticação multifatorial

A autenticação multifatorial (MFA) exige que os usuários verifiquem sua identidade usando dois ou mais fatores distintos de categorias diferentes antes que o acesso seja concedido.

Após inserir uma senha, os usuários devem fornecer um segundo fator, como um código de um app de autenticação, uma confirmação por notificação push ou uma leitura biométrica. Isso bloqueia a maioria dos ataques de roubo de credenciais, pois os invasores precisam de ambos os fatores. Códigos enviados por SMS e e-mail são menos eficazes do que notificações push ou autenticadores de hardware FIDO2.

Chaves de acesso (FIDO2/WebAuthn)

As chaves de acesso substituem as senhas por credenciais FIDO2 que são resistentes a phishing por natureza. Elas são baseadas no protocolo FIDO2 (WebAuthn e CTAP).

As chaves de acesso usam criptografia de chave pública. Durante o processo de inscrição, o dispositivo gera um par de chaves pública/privada. A chave privada é vinculada ao dispositivo usando criptografia, sendo projetada para não poder ser exportada do ambiente seguro do dispositivo. A chave pública é registrada no serviço, comprovando a autenticidade do dispositivo.

No momento do login, o dispositivo assina um desafio criptográfico. Essa assinatura funciona apenas para o domínio específico que a solicitou. Um site de phishing não consegue interceptar e reutilizar a assinatura, mesmo com proxies de phishing em tempo real. As chaves de acesso oferecem segurança de nível MFA resistente a phishing, pois a chave privada nunca sai do dispositivo e é desbloqueada por biometria ou um PIN do dispositivo. Elas podem ser sincronizadas entre dispositivos por meio de gerenciadores de credenciais da plataforma (como iCloud Keychain), a menos que as políticas exijam que permaneçam vinculadas ao dispositivo.

Identidade federada e login social

A identidade federada delega a autenticação a um IdP externo confiável.

OpenID Connect (OIDC): os usuários se autenticam com o IdP. A aplicação recebe um token de ID assinado criptograficamente que contém declarações de identidade verificadas (e-mail, nome), sem precisar lidar com as credenciais do usuário.

Isso elimina a necessidade de armazenamento de credenciais, reduz o atrito na integração e permite que a aplicação utilize a infraestrutura de segurança do IdP. Em ambientes corporativos, o SAML 2.0 também é comum para Single Sign-On (SSO).

Single Sign-On

O SSO permite que os usuários se autentiquem uma única vez com um IdP central e, em seguida, acessem várias aplicações sem precisar inserir as credenciais novamente.

O SSO utiliza protocolos como SAML 2.0 ou OpenID Connect. O IdP emite um token de segurança após o usuário fazer login e mantém a sessão. Os apps confiam nessa sessão para acesso sem exigir novos logins. Muitas organizações alinham a duração das sessões de SSO com os padrões típicos de um dia de trabalho. A duração real depende das políticas de segurança, dos sinais de risco e dos requisitos de garantia.

A autenticação moderna usa um servidor de autorização dedicado ou IdP que emite tokens baseados em padrões para acesso.

OpenID Connect (OIDC) e OAuth 2.0

Para entender a diferença:

O OAuth 2.0 é uma estrutura de autorização criada exclusivamente para delegação de acesso. Ele não possui um token ou protocolo padronizado para verificar a identidade do usuário final.

O OpenID Connect (OIDC) é uma camada de identidade construída sobre o OAuth 2.0. Ele fornece uma maneira padronizada para os clientes verificarem a identidade do usuário usando um token de ID, que contém declarações de autenticação assinadas pelo IdP.

Eles trabalham juntos: o OIDC cuida da autenticação (comprovação de identidade) e o OAuth 2.0 cuida da autorização (concessão de acesso à API).

Fluxo de código de autorização com PKCE

O fluxo de código de autorização com Proof Key for Code Exchange (PKCE) é o fluxo recomendado para aplicações web e móveis. O PKCE impede ataques de interceptação de código de autorização.

Como funciona: o app gera um verificador de código de alta entropia e um desafio de código com hash. O usuário se autentica com o servidor de autorização. O servidor emite um código de autorização de curta duração (expira em minutos). O servidor confere se o verificador corresponde ao desafio antes de emitir os tokens.

O servidor emite um token de ID contendo as informações de autenticação para o cliente e um token de acesso para chamadas de APIs. Quando a aplicação solicita acesso offline (por meio do escopo offline_access), o servidor emite um token de atualização que pode ser usado para renovar os tokens de acesso sem a necessidade de nova autenticação.

Autenticação baseada em token e JWTs

As APIs não autenticam usuários diretamente. Elas validam os tokens. Essa abordagem torna a autenticação sem estado e escalável, pois a API não precisa manter informações de sessão em um banco de dados.

Os JSON Web Tokens (JWTs) são o formato de token mais comum. Eles permitem a validação de API sem estado já que todas as declarações necessárias estão contidas no token. Algumas arquiteturas permanecem totalmente sem estado, enquanto outras realizam verificações adicionais opcionais (por exemplo, status do usuário ou revogação de token), dependendo dos requisitos de segurança.

Quando um cliente chama a API, ele inclui o token de acesso no cabeçalho Authorization: Bearer <token>. A API deve validar o JWT em cada requisição para garantir que ele seja autêntico, não esteja expirado e seja destinado à aplicação:

• Verifique se a estrutura do token está em conformidade com o formato JWT `header.payload.signature`.
• Verifique a integridade da assinatura usando a chave apropriada para garantir que o token não tenha sido adulterado.
• Verifique a expiração (exp) e, opcionalmente, as declarações nbf (not before) e iat (issued at) para rejeitar tokens inválidos ou prematuros.
• Confirme se o emissor (iss) corresponde ao seu IdP confiável.
• Verifique se o público (aud) corresponde à sua aplicação.
• Dê preferência a algoritmos de assinatura assimétrica (RS256 ou ES256) para que a API valide os tokens usando uma chave pública sem armazenar segredos compartilhados. Use HS256 somente em ambientes totalmente confiáveis.
• Nunca aceite o algoritmo none, pois ele contorna a verificação da assinatura.

APIs, serviços e comunicação de máquina para máquina exigem verificação de identidade criptográfica que não dependa da interação humana.

Fluxo de credenciais do cliente: o fluxo OAuth 2.0 para comunicação entre servidores. O serviço autentica-se usando client_id e client_secret (que devem ser protegidos como credenciais sensíveis e nunca incluídos no controle de versão). Após validar as credenciais, o servidor de autorização emite um token de acesso.

Pares de chaves assimétricas: os serviços podem usar pares de chaves assimétricas para autenticar clientes usando uma asserção JWT assinada (RFC 7523). O servidor de autorização valida a assinatura com a chave pública registrada, sem depender de segredos compartilhados.

Identidade da carga de trabalho: as plataformas em nuvem atestam criptograficamente a execução dos serviços, emitindo credenciais de curtíssima duração de forma dinâmica. Isso elimina segredos estáticos de longa duração.

A criação de aplicações seguras exige a adoção das boas práticas modernas de identidade.

Consideração de segurança	Recomendação do desenvolvedor
Proteção contra phishing	Para ter a defesa mais robusta contra roubo de credenciais, priorize as chaves de acesso FIDO2/WebAuthn em relação a todos os outros fatores (incluindo SMS e TOTP).
Segurança do fluxo	Implemente o fluxo de código de autorização com PKCE para todos os clientes.
Vida útil do token	Use tokens de acesso de curta duração (por exemplo, de 15 a 60 minutos) para minimizar a janela de ataque caso sejam roubados. Use a rotação do token de atualização para uma renovação sem problemas.
Armazenamento de token	Evite armazenar tokens sensíveis (de acesso ou atualização) em localStorage ou sessionStorage, devido aos riscos de Cross-Site Scripting (XSS). Para apps de navegador, prefira cookies HttpOnly seguros para SPAs, armazenando os tokens apenas na memória, e não em localStorage ou sessionStorage. Apps da web tradicionais devem usar sessões do lado do servidor com cookies HttpOnly seguros.
Validação de token de API	Valide a assinatura JWT em cada solicitação de API protegida. Se essa verificação for ignorada, haverá uma vulnerabilidade de segurança crítica.
Proteção de credenciais	Reforce a higiene de senhas com hashing adaptativo (Argon2 ou bcrypt) e implemente limitação de taxa para se defender contra ataques de força bruta e de preenchimento de credenciais. Utilize a detecção de senhas violadas para sinalizar automaticamente as credenciais comprometidas conhecidas.

Qual é a diferença entre autenticação e autorização?

A autenticação (AuthN) verifica a identidade: “Quem é você?”. A autorização (AuthZ) determina o acesso: “O que você pode fazer?”. A autenticação precede a autorização. Você precisa comprovar sua identidade antes que o sistema verifique as permissões.

Por que a autenticação somente por senha deixou de ser segura?

As senhas são a vulnerabilidade de segurança mais significativa. Elas são altamente vulneráveis a ataques de phishing e de preenchimento de credenciais. A segurança moderna exige a adição de MFA ou a mudança para métodos sem senha resistentes a phishing, como chaves de acesso.

Qual é o método de autenticação mais seguro disponível hoje em dia?

As chaves de acesso FIDO2/WebAuthn são as mais seguras atualmente. Elas usam criptografia de chave pública e estão vinculadas à origem. Como a credencial só funciona para o domínio específico, os invasores não podem interceptá-la e reutilizá-la.

Qual é o papel do OpenID Connect (OIDC) na autenticação?

O OIDC amplia o OAuth 2.0 com verificação de identidade. Ele adiciona o token de ID, um JSON Web Token (JWT), que fornece uma prova padronizada e verificável da identidade do usuário. O OAuth 2.0 sozinho não consegue fazer isso.

Qual é o principal risco de segurança associado ao roubo de um token de acesso JWT?

Com um token de acesso roubado, um invasor pode passar pelo usuário até que ele expire. Como os JWTs são sem estado e difíceis de revogar imediatamente, use tokens de acesso de curta duração (15 a 60 minutos) e rotação de tokens de atualização para limitar os danos. A rotação detecta o roubo de forma instantânea porque o servidor invalida o token anterior após cada uso.

Como funciona a autenticação sem senha?

A autenticação sem senha elimina a necessidade de memorizar segredos. Em vez disso, ela se baseia na posse (por exemplo, uma chave de acesso vinculada ao dispositivo ou uma chave de hardware) ou em fatores inerentes (como a biometria) para verificar com segurança a identidade do usuário.

A autenticação é fundamental para a segurança das aplicações, mas é apenas o primeiro passo. Para construir um modelo de segurança completo, você precisa entender como o acesso é controlado após a confirmação da identidade. Confira nossa série "Introdução ao IAM" para mais informações sobre tópicos relacionados ao gerenciamento de identidade e acesso.

Saiba mais

Este material destina-se apenas a fins informativos gerais. Você é responsável por obter aconselhamento sobre segurança, privacidade, conformidade ou negócios de seus próprios consultores profissionais e não deve confiar exclusivamente nas informações aqui fornecidas.