Padrões de Implementação de Autenticação e Autorização

Crie sistemas de autenticação e autorização seguros e escaláveis usando padrões da indústria e as melhores práticas modernas.

Use esta habilidade quando

• Implementar sistemas de autenticação de usuários
• Proteger APIs REST ou GraphQL
• Adicionar login social/OAuth2 ou SSO
• Projetar gerenciamento de sessão ou RBAC
• Depurar problemas de autenticação ou autorização

Não use esta habilidade quando

• Você precisa apenas de texto de interface do usuário ou estilo de página de login
• A tarefa é apenas de infraestrutura sem preocupações de identidade
• Você não pode alterar políticas de autenticação ou armazenamento de credenciais

Instruções

• Defina usuários, tenants, fluxos e restrições do modelo de ameaças.
• Escolha a estratégia de autenticação (sessão, JWT, OIDC) e o ciclo de vida do token.
• Projete o modelo de autorização e os pontos de aplicação de políticas.
• Planeje o armazenamento de segredos, rotação, logs e requisitos de auditoria.
• Se exemplos detalhados forem necessários, abra resources/implementation-playbook.md.

Segurança

• Nunca registre segredos, tokens ou credenciais.
• Aplique o princípio do menor privilégio e armazenamento seguro para chaves.

Recursos

• resources/implementation-playbook.md para padrões e exemplos detalhados.

Exemplo prático

Entrada: uma aplicação Express aceita o login de um usuário e mantém o ID da sessão pré-login. Leia o playbook empacotado, regenere a sessão após a verificação das credenciais, salve apenas os campos de identidade necessários e verifique se o cookie antigo não pode acessar /api/profile. Teste também login falho, logout e armazenamento de falhas. Esperado: login bem-sucedido altera o ID da sessão; login falho não concede acesso.

Entradas e pré-requisitos

Registre as versões do framework/SDK instaladas, o provedor de identidade, o modelo de tenant, o armazenamento de credenciais e o ambiente de teste. Forneça adaptadores de banco de dados e esquemas de solicitação específicos do projeto; exemplos são esboços de integração, não um serviço de identidade executável.

Limitações

• A validação de JWT não estabelece a propriedade do recurso; aplique políticas de tenant e objeto em leituras e gravações.
• A rotação de refresh requer persistência atômica e testes de concorrência; o exemplo de emissão por si só não os fornece.
• Flags de cookie não substituem a proteção CSRF, e o comportamento de cookie seguro precisa que a configuração real de HTTPS/proxy seja testada.
• Integrações de provedores e políticas de senha devem ser verificadas contra a documentação primária atual e o modelo de ameaças da aplicação.