A federação de identidade concentra em um único ponto o risco de todo o parque de aplicações: o provedor de identidade (IdP). O guia SP 800-63C do NIST organiza esse risco em níveis de garantia de federação (FAL) e distribui responsabilidades claras entre quem emite as asserções e quem as consome. Equipes que operam SSO corporativo têm aqui uma pauta concreta de hardening: mapear cada integração federada, classificar o nível de garantia efetivo e fechar as lacunas de assinatura, atributos liberados e ciclo de vida dos acessos — antes que a próxima conta desligada vire porta de entrada.
O que a norma define
A revisão vigente substitui a edição anterior e mantém o propósito central: o documento estabelece requisitos que provedores de identidade (IdPs) e partes confiáveis (RPs) precisam cumprir em sistemas de identidade federada — os dois polos de qualquer integração de SSO. O eixo da publicação são os níveis FAL, desenhados para representar opções de implantação progressivamente mais seguras: a arquitetura escolhida determina o quanto uma asserção roubada vale para o invasor.
No topo da escala, o FAL3 exige que a parte confiável verifique um autenticador vinculado ao assinante em adição à asserção recebida. Em termos práticos, a sessão federada herda a força do autenticador do usuário, e não apenas a confiança depositada no emissor. Um token interceptado sem o segundo fator perde valor de ataque.
A norma também endurece o contrato entre as partes: todo acordo de confiança precisa definir a população específica de contas de assinante à qual se aplica. Isso elimina a prática comum de liberar asserções para qualquer aplicação que peça, sem delimitar quais contas podem fluir por aquela relação de confiança.
Para quem implanta, a publicação aponta perfis como o OIDC Basic como referência de interoperabilidade, o que permite traduzir cada nível FAL em escolhas concretas de fluxo, tipo de token e assinatura, em vez de tratar a garantia de federação como abstração de auditoria.
A ameaça central: o IdP
O documento é direto sobre o risco sistêmico: em sistemas federados, um ataque bem-sucedido contra o IdP pode se propagar para todas as partes confiáveis que dependem dele, com potencial de movimento lateral entre domínios administrativos distintos. O hardening do provedor de identidade deixa de ser um projeto de IAM isolado e passa a ser o controle de perímetro de todas as aplicações conectadas a ele.
A consequência operacional é uma inversão de prioridade: antes de exigir mais controles das aplicações, a equipe precisa endurecer o emissor. Autenticação resistente a phishing no IdP, sessões curtas, revisão de contas administrativas e monitoramento da emissão de asserções rendem mais do que ajustes dispersos em cada RP. A linha complementar, como o guia do NIST IR 8587 para tokens de acesso na nuvem já demonstrava, é tratar cada artefato emitido pelo provedor como objeto de risco, com validade e escopo mínimos.
Hardening das partes confiáveis
O lado que consome asserções tem obrigações próprias, e a maioria das lacunas encontradas em auditoria está nele. A parte confiável precisa validar assinatura, emissário e audiência de toda asserção recebida, e rejeitar qualquer asserção fora do acordo de confiança vigente — inclusive assinada por um emissor desconhecido. Falha aqui transforma o RP no elo mais fraco, mesmo com um IdP bem configurado.
Privacidade entra como controle de segurança: a norma recomenda que a parte confiável solicite valores derivados de atributos em vez de valores completos, quando viável, e que o IdP suporte essa derivação. Uma afiliação de grupo em vez do cargo completo, uma afirmação booleana em vez da data de nascimento: menos atributo liberado significa menos dano quando o RP for comprometido e menos exposição de dados pessoais sob LGPD e GDPR.
Ciclo de vida dos acessos
Federação resolve o login; não resolve a revogação. As integrações modernas de SSO suportam provisionamento e a remoção de contas de usuário com o protocolo SCIM, e a ausência dessa automação é a lacuna mais frequente em ambientes reais: a pessoa sai do diretório corporativo, mas a conta no SaaS sobrevive por inércia, com sessão ativa e permissões intactas.
O procedimento mínimo para fechar essa lacuna tem três passos: cruzar os usuários ativos de cada aplicação federada com o diretório corporativo; abrir tratamento para toda conta sem vínculo; e conectar as aplicações críticas ao desprovisionamento automático, com prazo medido em minutos ou horas, não em ciclos de auditoria trimestrais.
A defesa em camadas das contas começa no provedor: a CISA reforça que MFA protege a conta além da senha e que usuários que a habilitam têm probabilidade bem menor de sofrer invasão. Para o IdP, o padrão a perseguir é o método resistente a phishing — a discussão sobre passkeys com NIST e WebAuthn mostra o caminho — combinado com desprovisionamento imediato. Os dois controles juntos atacam as vias mais usadas contra identidade federada: o sequestro de sessão e a conta órfã.
Checklist de implantação
A tabela abaixo ordena o trabalho por prioridade e define o critério objetivo de conclusão de cada item, para que a iniciativa não se dissolva em recomendações genéricas de zero trust.
| Ação | Prioridade | Verificação de conclusão |
|---|---|---|
| Mapear todas as integrações federadas e classificar o nível FAL efetivo | P1 | Inventário com emissor, protocolo e atributos liberados por aplicação |
| Restringir a população de contas por acordo de confiança | P1 | Nenhuma integração liberando asserções para todas as contas sem justificativa registrada |
| Validar assinatura, emissário e audiência em toda asserção | P1 | Teste com asserção forjada rejeitado e documentado |
| Ativar desprovisionamento SCIM nos SaaS críticos | P1 | Conta desativada no diretório desaparece da aplicação no mesmo dia |
| Levar o IdP a métodos resistentes a phishing | P2 | Nenhum login administrativo dependente de código OTP |
| Reduzir atributos liberados a valores derivados | P2 | Revisão de claims concluída aplicação por aplicação |
| Monitorar a emissão de asserções anômalas | P2 | Alerta configurado para picos de emissão fora do padrão |
Sinais de que algo já falhou: picos de emissão de asserções fora do padrão, audiências novas recebendo liberação sem mudança registrada, logins de contas fora da população definida no acordo de confiança e falhas repetidas de validação de assinatura em um mesmo RP. Cada um desses eventos merece alerta e investigação, não apenas um ticket de suporte.