Identidade federada: SAML, OAuth e OpenID Connect

Nas empresas modernas, os funcionários precisam acessar dezenas de aplicações — aplicações em nuvem, ferramentas SaaS, portais de parceiros e sistemas internos — cada uma potencialmente mantida por organizações diferentes. Criar e gerenciar contas separadas para cada uma delas é inseguro (proliferação de credenciais) e ineficiente. A identidade federada resolve esse problema ao permitir que um Identity Provider (IdP) — uma fonte de identidade confiável e autoritativa — autentique usuários e compartilhe essa identidade autenticada com Service Providers (SPs) além das fronteiras organizacionais. Os usuários se autenticam uma vez e obtêm acesso a vários sistemas sem precisar inserir novamente suas credenciais.

O Single Sign-On (SSO) permite que os usuários se autentiquem uma vez e acessem várias aplicações durante uma sessão sem precisar se autenticar novamente. O usuário entra no Identity Provider (Active Directory corporativo, Okta, Azure AD), recebe um token de sessão ou uma asserção e apresenta esse token a cada Service Provider que acessa. O SSO melhora a segurança ao reduzir o número de senhas que os usuários precisam gerenciar (reduzindo a reutilização), permitir a aplicação centralizada de políticas de autenticação e possibilitar a revogação imediata do acesso em todas as aplicações integradas quando uma conta é desabilitada no nível do IdP.

SAML (Security Assertion Markup Language) 2.0 é o padrão aberto baseado em XML para a troca de dados de autenticação e autorização entre Identity Providers e Service Providers. O fluxo do SAML é o seguinte: (1) o usuário acessa um Service Provider (por exemplo, Salesforce); (2) o SP redireciona o usuário para o Identity Provider (por exemplo, Okta); (3) o usuário se autentica no IdP; (4) o IdP emite uma SAML Assertion XML assinada, contendo a identidade e os atributos do usuário; (5) a asserção é devolvida ao SP; (6) o SP valida a assinatura da asserção usando a chave pública do IdP e concede o acesso. O SAML é amplamente usado para SSO empresarial em aplicações Web.

Três partes participam de uma federação SAML. O Principal é o usuário (ou sistema) que busca acesso — ele inicia o processo de autenticação. O Identity Provider (IdP) é a fonte autoritativa da identidade que autentica o principal e emite asserções — exemplos incluem Microsoft Azure AD, Okta, Ping Identity e ADFS. O Service Provider (SP) consome a asserção e concede acesso com base nela — exemplos incluem Salesforce, Google Workspace, AWS e qualquer aplicação compatível com SAML. O SP e o IdP estabelecem confiança antecipadamente trocando metadados que contêm as URLs dos endpoints de cada um e os certificados de assinatura.

O OAuth 2.0 é uma estrutura de authorization (não um protocolo de autenticação) que permite que uma aplicação de terceiros acesse recursos em nome de um usuário sem expor as credenciais desse usuário. Um caso de uso clássico é: “Permitir que esta aplicação de edição de fotos acesse o Google Photos”. O OAuth 2.0 introduz quatro funções: o Resource Owner (usuário), o Client (aplicação de terceiros), o Authorization Server (emite tokens) e o Resource Server (hospeda o recurso protegido). O usuário autoriza o Client, que recebe um access token e o apresenta ao Resource Server — sem nunca precisar da senha real do usuário.

O Authorization Code Flow é o fluxo mais seguro do OAuth 2.0 para aplicações Web. O fluxo funciona assim: (1) o Client redireciona o usuário para o Authorization Server com os escopos solicitados; (2) o User se autentica e concede consentimento no Authorization Server; (3) o Authorization Server redireciona o usuário de volta com um authorization code de curta duração; (4) o Client troca o código por um access token (e, opcionalmente, um refresh token) por meio de uma chamada de servidor para servidor com as credenciais do Client; (5) o Client usa o access token para chamar o Resource Server. A troca do código ocorre no lado do servidor, impedindo que o access token seja exposto no histórico ou nos registros do navegador.

O OpenID Connect (OIDC) é uma camada de autenticação criada sobre o OAuth 2.0. O OAuth fornece apenas autorização (os tokens de acesso comprovam o que o Client pode fazer); o OIDC adiciona autenticação (um ID token que comprova quem é o usuário). O OIDC adiciona o escopo openid ao fluxo do OAuth e retorna um JWT (JSON Web Token) ID Token assinado junto com o access token. O ID token contém claims (nome, e-mail, sub [identificador do subject]) que identificam o usuário. Atualmente, o OIDC é o protocolo dominante para SSO voltado ao consumidor — os botões “Entrar com Google/Apple/Microsoft” usam OIDC.

Os JSON Web Tokens (JWT) são um formato compacto e seguro para URLs, usado para representar claims entre partes. Um JWT tem três partes codificadas em base64url e separadas por pontos: Header (algoritmo e tipo de token), Payload (claims: iss, sub, aud, exp, iat e claims personalizados) e Signature (assinatura criptográfica que verifica a integridade do token). Os JWTs são autocontidos — o Resource Server pode verificá-los sem chamar novamente o Authorization Server, melhorando o desempenho e permitindo arquiteturas sem estado. O requisito crítico de segurança é: sempre verifique a assinatura do JWT e confira as claims exp (expiração) e aud (público-alvo).

Entender quando cada padrão se aplica é fundamental para o exame Security+. SAML 2.0: SSO empresarial para aplicações Web, fluxos baseados em navegador e asserções XML. É antigo, mas amplamente implantado em empresas. OAuth 2.0: autorização de APIs — concede a aplicações de terceiros acesso limitado a recursos. Não autentica usuários diretamente. OIDC: autenticação de consumidores e de empresas modernas (SSO), criada sobre o OAuth 2.0. Retorna tokens de identificação JWT que identificam o usuário. Na prática, ambientes empresariais costumam usar SAML para SSO de aplicações e OIDC para autenticação de APIs e dispositivos móveis. Ambientes modernos nativos da nuvem preferem OIDC ao SAML por seu formato JSON/JWT e melhor suporte a dispositivos móveis.

Os sistemas de identidade federada introduzem vetores de ataque específicos. Replay de asserções: um invasor intercepta uma asserção SAML e a reproduz para obter acesso. Isso é mitigado por durações curtas das asserções e IDs de asserção de uso único. XML signature wrapping (XSW): no SAML, os invasores às vezes conseguem manipular XML assinado para alterar claims, mantendo válida a assinatura do conteúdo original. Confusão de algoritmo JWT: se um servidor aceitar os algoritmos RS256 (assimétrico) e HS256 (simétrico), um invasor poderá forjar JWTs usando a chave pública do servidor como segredo HMAC para HS256. Valide sempre se o algoritmo do cabeçalho corresponde ao algoritmo esperado. Redirecionadores abertos: as URIs de redirecionamento do OAuth devem corresponder exatamente para impedir o roubo de tokens por meio de redirecionamentos para sites controlados pelo invasor.

A federação de identidades empresariais geralmente exige a sincronização de dados de identidade dos usuários entre sistemas. O SCIM (System for Cross-domain Identity Management) é um padrão de API REST para automatizar o provisionamento e o desprovisionamento de usuários entre um Identity Provider e Service Providers conectados. Quando um novo funcionário é adicionado ao Azure AD (IdP), o SCIM cria automaticamente a conta dessa pessoa no Salesforce, Slack, GitHub e em outras aplicações compatíveis com SCIM. Quando o funcionário é desligado, o SCIM desativa todas as contas simultaneamente, encerrando o período em que contas órfãs poderiam ser exploradas. O SCIM complementa os protocolos de SSO (SAML/OIDC) ao gerenciar o ciclo de vida, algo que os protocolos de SSO não fazem.

Nesta lição, você aprendeu: o SAML 2.0 usa asserções XML para SSO empresarial baseado em navegador; o OAuth 2.0 é uma estrutura de autorização para delegar acesso a APIs; o OpenID Connect adiciona autenticação (tokens de identificação JWT) sobre o OAuth; e o SCIM automatiza o gerenciamento do ciclo de vida das identidades em sistemas federados. Com isso, concluímos o curso de Autenticação e Autorização — a seguir, exploraremos os Fundamentos de Network Security.