1) API Keys e tokens simples: quando usar

Para cenários de acesso a APIs simples, principalmente entre serviços internos ou aplicações de baixa criticidade, APIs keys atuam como um meio leve de autenticação. Elas são fáceis de distribuir, mas exigem controles de rotação, escopo limitado e monitoramento de uso para evitar abusos.

• Quando usar: integrações entre serviços internos, clientes móveis com autenticação indireta, roteamento rápido de tráfego entre fronteiras de rede.
• et: implementação rápida, baixo overhead de infraestrutura, auditoria básica de consumo por chave.
• Desvantagens: não autentica usuário; risco de vazamento em client-side; rotação e revogação complexas sem boa automação; alcance de escopo é limitado.

Conserve API Keys para cenários onde o principal objetivo é autenticar o client, não o usuário final. Combine com quotas, IP allowlists e rotação periódica.

2) Mutual TLS (mTLS): autenticação de serviço a serviço

Para comunicações entre serviços com forte exigência de confiança mútua, o mTLS oferece uma defesa sólida contra impersonation. Em vez de tokens, o cliente apresenta um certificado carregado em TLS, que é validado pelo servidor com base em uma autoridade certificadora confiável.

• Quando usar: ambientes de microserviços, edge gateways, serviços críticos com requisitos de compliance e zero-trust.
• Vantagens: não depende de segredos em código, binding claro entre identidade do cliente e requisicao, boa auditoria de certificados.
• Desvantagens: operação de PKI mais complexa, renovação de certificados, gestão de certificados de clientes e clientes sem suporte adequado.

Modelos de implementação comuns incluem:

• Configuração de CA interna e verificação de certificados no lado do servidor.
• Integração com service mesh (ex.: Istio,Linkerd) para gestão automática de certificados e mTLS entre termos.

curl --cert cliente.pem --key cliente.key --cacert ca.pem https://api.exemplo.local/secure
# ou via service mesh com políticas de mTLS

3) SAML 2.0: SSO corporativo e integração legada

Em ambientes empresariais, SAML 2.0 continua sendo uma opção robusta para SSO entre aplicações e provedores de identidades (IdP). Embora OAuth2 seja mais comum em APIs modernas, SAML ainda brilha em cenários de autenticação de usuário com federação entre diretórios (AD, LDAP) e aplicações legadas.

• Quando usar: SSO entre intranet apps, ERP/CRM legados, ou quando já existe uma infraestrutura IdP baseada em SAML.
• Vantagens: integração com identidade corporativa, suporte multi-provedor, fluxos de login centrados no usuário.
• Desvantagens: menos adequado para APIs modernas sem adaptação, configuração mais trabalhosa em aplicativos recentes, menos foco em OAuth-style access control.

Ao escolher entre SAML e OAuth2/OIDC, avalie o cenário de usuário final, a maturidade da sua infraestrutura de identidade e a facilidade de integração com clientes modernos (navegadores, apps móveis).

4) WebAuthn / FIDO2: autenticação de usuário sem senhas

Para autenticação de usuário com foco em phishing-resistance e experiência sem senha, WebAuthn (FIDO2) oferece credenciais criptográficas robustas armazenadas no dispositivo do usuário. Esse modelo pode coexistir com camadas de autorização baseadas em OAuth2/OIDC, substituindo senhas comuns na etapa de login.

• Quando usar: aplicações com alto rigor de segurança de autenticação, aplicativos móveis e web que desejam reduzir o uso de senhas, fluxos de login mais resistentes a phishing.
• Vantagens: resistência a phishing, recuperação simplificada por dispositivos, suporte a autenticação multifator sem senhas repetidas.
• Desvantagens: necessidade de suporte de navegador/dispositivo, curva de adoção entre usuários e equipes de suporte, integração com fluxo de autorização existente.

Integração típica envolve registro de credenciais no registro do usuário (opa para iniciar login com WebAuthn), geração de desafio no servidor e verificação de assinaturas criptográficas do dispositivo.