System Design/05 - Reliability Patterns/Security2 min
Federated Identity
- Que problema isso resolve?
- Quando usar / quando NÃO usar?
- Qual o principal trade-off?
- Como isso falha em produção?
Conceito
Delegar a autenticação a um provedor de identidade externo, em vez de a aplicação gerenciar credenciais.
usuário → aplicação → redireciona → provedor (Google, Entra ID, Okta)
↓ autentica
← token assinado ←──────────┘
Protocolos
| Protocolo | Para quê |
|---|---|
| OAuth 2.0 | Autorização — delegar acesso a recursos |
| OpenID Connect | Autenticação — camada sobre OAuth 2.0 |
| SAML 2.0 | Federação corporativa, SSO empresarial |
Confundir OAuth com autenticação é o erro conceitual mais comum: OAuth diz o que um aplicativo pode fazer; OIDC é a camada que diz quem é o usuário.
O que se ganha estruturalmente
A aplicação deixa de armazenar senhas — e, portanto, deixa de poder vazá-las. MFA, políticas de senha, detecção de anomalia e revogação passam a ser responsabilidade de quem faz isso em escala.
Trade-offs
O ganho de segurança é substancial: a maior parte dos vazamentos de credencial vem de aplicações guardando senhas. Não guardar nenhuma elimina a classe inteira de problema.
Também resolve SSO corporativo: o funcionário entra com a credencial da empresa, e a desativação da conta no diretório revoga o acesso a todos os sistemas de uma vez.
Os custos:
Dependência externa no caminho de login. Se o provedor cai, ninguém entra. Isso torna a disponibilidade dele parte do seu SLA.
Complexidade dos protocolos. OAuth e OIDC têm muitos fluxos, e escolher o errado cria vulnerabilidade. A orientação atual é Authorization Code com PKCE para praticamente todos os clientes — o fluxo implícito foi descontinuado justamente por expor tokens.
Validação de token é responsabilidade sua. Assinatura, emissor, audiência e expiração precisam ser verificados. Aceitar um token sem validar o aud permite que um token emitido para outra aplicação seja usado na sua.
Revogação é difícil. Um JWT é válido até expirar; não há como invalidá-lo sem uma lista de revogação — o que reintroduz estado. A mitigação usual é expiração curta com refresh token.
Exemplo prático
Um SaaS B2B em que cada empresa cliente usa seu próprio diretório.
empresa A → Entra ID (SAML)
empresa B → Okta (OIDC)
empresa C → Google Workspace
A aplicação não guarda nenhuma senha e não gerencia nenhum ciclo de vida de usuário. Quando a empresa A demite alguém e desativa a conta no diretório, o acesso ao SaaS termina imediatamente — sem que ninguém precise avisar o fornecedor.
Esse comportamento é frequentemente um requisito contratual em vendas corporativas, e implementá-lo sem federação seria reconstruir mal o que o provedor já faz bem.
Relacionado
Parte de Security · roadmap.sh/system-design