"Entrar com o Google." "Login único da empresa." A web moderna delegou a autenticação a sistemas federados — em vez de cada aplicação gerenciar suas próprias senhas, elas confiam num provedor de identidade central. Isso melhora a segurança e a experiência, mas cria uma nova e rica superfície de ataque: a autenticação federada, governada por protocolos como OAuth, SAML e o conceito de SSO (Single Sign-On). Esta aula fecha o Bloco XII com essa camada, que concentra falhas de alto impacto porque, comprometê-la, frequentemente compromete o acesso a múltiplas aplicações de uma vez. Pratique nos labs de OAuth do PortSwigger.

SSO, IdP e Service Provider

Comece pelos conceitos. O SSO (Single Sign-On) é a ideia de logar uma vez e acessar múltiplas aplicações sem redigitar credenciais — dentro de uma empresa (um login para e-mail, drive, sistemas internos) ou na web (entrar em vários sites com sua conta Google). Ele se apoia num provedor de identidade (IdP) central, em quem as aplicações (os service providers) confiam para autenticar os usuários. Os dois protocolos dominantes que implementam isso: o SAML (baseado em XML, comum em ambientes corporativos) e o OAuth 2.0 / OpenID Connect (baseado em tokens, dominante na web e em APIs). Entender a dança entre usuário, aplicação e provedor de identidade é o que permite reconhecer onde ela pode ser subvertida.

OAuth é autorização, não autenticação

Um esclarecimento conceitual importante que muitos confundem: OAuth é sobre autorização, não autenticação (embora seja frequentemente usado para login via OpenID Connect, que é construído sobre ele). O OAuth foi projetado para delegação de acesso — permitir que uma aplicação acesse seus recursos em outro serviço sem você entregar sua senha. Quando um app pede "permissão para acessar suas fotos do Google", é OAuth: você autoriza o app a acessar um recurso específico, e ele recebe um token que representa essa autorização limitada. Essa distinção importa porque muitas falhas de OAuth surgem justamente de usar um protocolo de autorização para fazer autenticação sem os cuidados necessários — tratar um token de acesso como prova de identidade quando ele não foi projetado para isso.

A manipulação do redirect_uri

As falhas de OAuth são numerosas e sutis, e vale conhecer os padrões. Um exemplo clássico é a manipulação do redirect_uri: no fluxo OAuth, após você autorizar, o provedor redireciona de volta para a aplicação com o token/código — para um endereço (redirect_uri) que a aplicação especifica. Se a validação desse endereço é frouxa, um atacante pode fazer o provedor redirecionar o código de autorização para um servidor que ele controla, capturando o acesso da vítima. Outras falhas incluem o mau uso do parâmetro state (cuja ausência abre CSRF no fluxo OAuth), o vazamento de tokens, e a aceitação inadequada de tokens de acesso como prova de identidade. Cada uma explora um ponto onde a implementação da aplicação não seguiu rigorosamente o protocolo — e como o fluxo envolve múltiplas partes e redirecionamentos, há muitas oportunidades de erro.

SAML e a verificação de assinatura

O SAML, baseado em XML, tem sua própria família de falhas — e aqui a conexão é com a web avançada. A autenticação SAML funciona por "assertions" (afirmações) assinadas digitalmente: o provedor de identidade afirma "este é o usuário João" e assina essa afirmação, que a aplicação verifica. As falhas clássicas atacam essa verificação de assinatura: se a aplicação valida mal a assinatura, um atacante pode forjar ou adulterar a afirmação — mudando "João" para "admin" — e a aplicação aceita. Há também ataques que exploram a manipulação da estrutura XML da afirmação (XML Signature Wrapping, aparentado à XXE da aula Web avançada I: XXE, SSTI e desserialização insegura) para fazer a aplicação verificar uma parte do documento mas usar outra. O tema, ecoando o JWT da aula Falhas de autenticação, sessões e JWT: quebrando o controle de identidade: a segurança da autenticação federada repousa sobre a verificação criptográfica correta das afirmações de identidade, e falhas nessa verificação permitem forjar quem você é.

A autenticação federada concentra risco

O ponto conceitual que fecha o bloco: a autenticação federada concentra risco. Por um lado, é mais segura em princípio — centraliza a autenticação num provedor especializado, habilita MFA de forma consistente, e elimina senhas espalhadas por dezenas de aplicações. Por outro, cria um ponto de alto valor: comprometer o provedor de identidade ou o fluxo de federação pode dar acesso a todas as aplicações que confiam nele. É a mesma tensão do Active Directory (Bloco XI) — a centralização que traz eficiência e segurança também concentra o poder num alvo único. E as falhas são especialmente perigosas porque a autenticação federada é a base de confiança sobre a qual tudo se apoia: se o atacante subverte "quem você é" no nível do provedor de identidade, as aplicações individuais não têm como saber.

redirect_uri exato e assinatura bem validada

Do lado defensivo, as contramedidas reúnem rigor de implementação e criptografia correta: para OAuth, validar rigorosamente o redirect_uri (allowlist exata, não parcial), usar sempre o parâmetro state (contra CSRF), validar tokens corretamente e não tratar tokens de acesso como prova de identidade (usar OpenID Connect adequadamente para autenticação); para SAML, validar rigorosamente as assinaturas das afirmações e proteger contra manipulação de XML; transversalmente, seguir as especificações dos protocolos à risca (a maioria das falhas vem de desvios da implementação correta), MFA no provedor de identidade (que protege o ponto central), e monitoramento de autenticação anômala. A lição: a autenticação federada é poderosa e, feita corretamente, mais segura — mas exige implementação rigorosa, porque um erro no fluxo ou na verificação criptográfica compromete a confiança de todo o ecossistema.

Fecha o Bloco XII por completo

Com esta aula, encerramos o Bloco XII — Web e Aplicações por completo. Você domina o maior campo da segurança: do HTTP às injeções, das ferramentas às classes avançadas, e agora à autenticação federada. O território adjacente que vem a seguir é a espinha dorsal das aplicações modernas: a segurança de APIs.

Fontes e leituras recomendadas

Exercícios

  1. O que é SSO, e qual o papel do provedor de identidade (IdP) na autenticação federada?

    ✓ Resposta:

    SSO (Single Sign-On) é logar uma vez e acessar múltiplas aplicações sem redigitar credenciais. O provedor de identidade (IdP) é o sistema central que autentica o usuário e no qual as aplicações (service providers) confiam para receber a identidade autenticada.

  2. Por que se diz que "OAuth é sobre autorização, não autenticação", e como essa confusão gera falhas?

    ✓ Resposta:

    Porque o OAuth foi projetado para delegação de acesso a recursos (dar a um app um token para acessar algo específico sem entregar a senha), não para provar identidade. A confusão gera falhas quando aplicações tratam um token de acesso como prova de identidade, sem os cuidados que a autenticação exige (usar OpenID Connect corretamente).

  3. Explique a falha de manipulação do redirect_uri no OAuth e seu impacto.

    ✓ Resposta:

    Após a autorização, o provedor redireciona de volta à aplicação com o código/token para o redirect_uri especificado. Se a validação desse endereço é frouxa, o atacante faz o provedor redirecionar o código para um servidor que ele controla, capturando o acesso da vítima e comprometendo sua conta.

  4. Como as falhas de SAML atacam a verificação de assinatura das afirmações, e a que vulnerabilidade já vista isso se aparenta?

    ✓ Resposta:

    As afirmações SAML são assinadas digitalmente; se a aplicação valida mal a assinatura, o atacante forja ou adultera a afirmação (mudando o usuário para admin) e ela é aceita. Também há manipulação da estrutura XML (XML Signature Wrapping). Aparenta-se à XXE e, em espírito, às falhas de JWT — todas dependem de verificação criptográfica correta que, se falha, permite forjar identidade.

  5. Por que a autenticação federada "concentra risco", e qual a lição defensiva central?

    ✓ Resposta:

    Porque comprometer o provedor de identidade ou o fluxo de federação pode dar acesso a todas as aplicações que confiam nele — a centralização concentra o poder num alvo único (como o AD). A lição defensiva central é seguir as especificações dos protocolos à risca e validar rigorosamente as verificações criptográficas, pois um erro no fluxo ou na assinatura compromete a confiança de todo o ecossistema.