Single sign-on: Protocolo de segurança

Especifica limites de confiança, tokens ou credenciais, controles de abuso, expiração, revogação e mitigações de ameaças para single sign-on. Define limites de adoção e evidências observáveis de falha enquanto mantém limites específicos do ambiente configuráveis.

Status do pacote: contexto de referência pronto para revisão humana. O contrato e os cenários de teste estão completos, mas não se afirma que uma implementação adotante os tenha aprovado.

Decisão

Para Single sign-on, adote um ciclo de vida de credencial e sessão do lado do servidor com garantia explícita. Aplique o controle no lado do servidor confiável, padrão para negação, e defina suposições de ameaça, limites de abuso, evidências e recuperação. Este pacote é um contrato de referência: a equipe adotante deve escolher limites numéricos, provedores, jurisdições e responsáveis operacionais a partir das evidências em seu próprio ambiente.

Escopo

• Os atores, entradas, saídas, estados, versões de política ou esquema e resultados visíveis externamente do Single sign-on descritos por este bloco de segurança.
• Interfaces primárias e alternativas, trabalhos em segundo plano, caches, integrações, caminhos de suporte e evidências que podem exercer o mesmo limite.
• Configuração específica de adoção, implantação, recuperação e responsabilidades de verificação necessárias para aplicar a referência com segurança.

Fora deste bloco

• Escolher um fornecedor universal, framework, jurisdição, limite numérico, período de retenção ou objetivo de nível de serviço para todos os adotantes.
• Alegar que os cenários empacotados foram executados contra uma implementação a jusante ou que esta referência concede certificação legal, de segurança ou acessibilidade.

Contrato

• Armazenar apenas material de credencial protegido, rotacionar segredos de assinatura e recuperação, e manter credenciais fora de URLs, logs, análises e visualizações de suporte.
• Vincular emissão, uso, expiração, revogação, recuperação e tratamento de replay a um sujeito nomeado e ação pretendida.
• Retornar respostas públicas resistentes à enumeração enquanto retém dados internos suficientes de motivo e correlação para suporte e resposta a abusos.
• Reavaliar ações sensíveis após mudanças no sujeito, dispositivo, autenticador, risco ou estado da sessão em vez de confiar em um login antigo para sempre.
• Tratar todos os campos de cliente, callback, arquivo, modelo e telemetria como não confiáveis até serem autenticados e validados para a ação pretendida.
• Exigir uma segunda salvaguarda independente para caminhos de alto impacto onde a violação de um analisador, credencial ou provedor seria decisiva.
• Vincular domínio ou configuração da organização a um administrador verificado e mapear emissor mais sujeito para uma identidade externa.
• Provisionamento, login, sessão, mapeamento de função, desprovisionamento e acesso break-glass têm estados e evidências separados.

Orientação para implementação

• Modele ameaças normais, replay, enumeração, cross-tenant, automação e caminhos de dependência degradada antes da revisão da implementação.
• Modele entradas, saídas, atores, estados, invariantes, efeitos colaterais e evidências do Single sign-on antes de selecionar detalhes de framework ou fornecedor.
• Armazene a versão aplicável do contrato ou política do Single sign-on com estado material para que migrações, replay e decisões de suporte permaneçam atribuíveis.
• Introduza o caminho por trás de implantação controlada, compare resultados esperados e observados, e mantenha uma rota de recuperação testada até que a evidência de adoção esteja completa.

Tratamento de falhas e salvaguardas

• Evidências de autenticação ausentes, expiradas, reproduzidas ou contraditórias negam a ação e seguem um caminho de recuperação com limite de taxa.
• Estado inválido ou contraditório do Single sign-on é rejeitado ou colocado em quarentena; a implementação nunca supõe um valor que amplie autoridade ou duplique efeito.
• Retentativas são limitadas e usam identidade durável; após esgotamento, o trabalho alcança um estado terminal inspecionável com um responsável contabilizável.

Verificação e operações

• Use casos pareados de permissão e negação em cada limite de confiança e confirme que a perda da dependência de controle falha fechada.
• Monitore sucesso, negação, falha de validação, falha de dependência, esgotamento de retentativas e recuperação do Single sign-on por versão de contrato sem dimensões sensíveis de payload.
• Reexecute fixtures positivos e negativos pareados após mudanças de política, esquema, dependência, migração ou limite e preserve a evidência resultante.

Suposições de adoção

• Nomes e valores no exemplo são um fixture concreto, não padrões universais; adotantes os substituem por meio de evidência documentada e propriedade.
• O sistema adotante pode fornecer identidade autenticada, versões duráveis de operação ou registro, telemetria limitada e um caminho controlado para mudança.

Os exemplos com aparência executável neste pacote são fixtures e contratos de aceitação. Execute o validador da coleção para verificar estrutura e metadados, depois traduza e execute os cenários no repositório de destino antes de registrar evidências de implementação.

Referências

• NIST SP 800-63B-4, Authentication and Authenticator Management (aplica-se a partir de 2026-09-08)
• OpenID Connect Core 1.0