RotaDefault

O Single sign-on (SSO) é uma técnica de controle de acesso centralizado que permite que um usuário ou sujeito (subject) seja autenticado uma única vez em um sistema e acesse múltiplos recursos ou objetos (objects) sem precisar se autenticar novamente. O SSO é conveniente para os usuários e traz benefícios de segurança.

Neste artigo citaremos como o XML estabeleceu as bases para a troca de dados estruturados em ambientes distribuídos, passando pela consolidação do SAML como padrão de federação enterprise, até a virada de paradigma representada pelo OAuth 2.0 e a camada de identidade do OpenID Connect.

XML

Antes de falar de protocolos de autenticação, é necessário entender por que o XML (eXtensible Markup Language) foi tão central no surgimento do SSO federado na Internet.

No final dos anos 90 e início dos anos 2000, o XML emergiu como o formato universal para troca de dados entre sistemas heterogêneos. Diferente de formatos proprietários, o XML é autodescritivo, extensível e legível por qualquer plataforma. Mais do que isso, o ecossistema ao redor dele — XML Signature, XML Encryption e XML Schema — criou uma base sólida para construir protocolos seguros de troca de informação.

Dois padrões do ecossistema XML são especialmente relevantes para o SSO:

XML Signature (XMLDSig): Define como assinar digitalmente documentos XML, garantindo integridade e autenticidade. A assinatura pode cobrir o documento inteiro ou apenas partes selecionadas, o que permite que estruturas complexas contenham múltiplos elementos assinados por partes diferentes. Essa flexibilidade é explorada diretamente pelo SAML.

XML Encryption: Define como criptografar elementos XML, protegendo dados sensíveis em trânsito. Enquanto o TLS protege o canal, a XML Encryption protege o conteúdo individualmente — garantindo confidencialidade mesmo que o payload passe por intermediários.

Foi sobre essa fundação que o SAML foi construído — e por isso o entendimento dessas primitivas é importante para compreender as escolhas de design (e as críticas) do protocolo.

SAML 2.0: Federação Enterprise

O Security Assertion Markup Language (SAML) foi desenvolvido pelo comitê técnico SSTC do OASIS, com a versão 2.0 publicada em 2005. Seu objetivo era resolver um problema concreto: permitir que usuários de uma organização (o Identity Provider) acessassem recursos de outra organização (o Service Provider) sem precisar de uma conta duplicada.

A Estrutura da Assertion

O coração do SAML é a assertion — um documento XML assinado que o IdP emite para atestar fatos sobre o usuário. Uma assertion SAML pode conter três tipos de statements:

• Authentication Statement: Afirma que o principal foi autenticado, por qual método e em que momento.
• Attribute Statement: Carrega atributos do usuário — e-mail, grupos, cargo, departamento — que o SP pode usar para autorização.
• Authorization Decision Statement: (raramente usado na prática) Afirma se o principal tem permissão para acessar um recurso específico.

Limitações do SAML

O SAML 2.0 foi projetado para um mundo de aplicações web server-side dos anos 2000. Com a popularização de aplicações mobile, SPAs e APIs REST, suas limitações ficaram evidentes:

• Verbosidade do XML: Assertions completas podem ter vários kilobytes. Parsing de XML é custoso comparado a JSON.
• Centrado no browser: O modelo de redirect/POST binding pressupõe um navegador como intermediário. Aplicações mobile e clientes nativos não se encaixam naturalmente.
• Sem modelo de autorização de API: O SAML autentica usuários para acessar aplicações, mas não define como autorizar chamadas de API em nome do usuário.

Esses problemas abriram espaço para uma nova geração de protocolos.

OAuth 2.0

O OAuth 2.0, publicado na RFC 6749 em 2012, não é um protocolo de autenticação — e este é um ponto frequentemente mal compreendido. OAuth é um framework de autorização delegada: ele permite que uma aplicação (cliente) acesse recursos em nome de um usuário, sem que o usuário precise compartilhar suas credenciais com essa aplicação.

O caso de uso original era simples: permitir que um serviço de terceiros (ex: uma app de fotos) acesse os contatos do Gmail do usuário, sem que o usuário desse sua senha do Google ao serviço.

Papéis no OAuth 2.0

• Resource Owner: O usuário que detém os recursos.
• Client: A aplicação que deseja acesso aos recursos.
• Authorization Server: Responsável por autenticar o usuário e emitir tokens de acesso (Access Token).
• Resource Server: A API que protege os recursos e valida os tokens.

Access Token: Opaco ou JWT

O OAuth 2.0 não especifica o formato do Access Token — ele pode ser opaco (uma string aleatória que o Resource Server valida consultando o Authorization Server via introspection) ou um JWT (JSON Web Token) autocontido e verificável localmente.

JWTs como Access Token trazem eficiência (sem consulta ao AS a cada request), mas também complexidade: a revogação é difícil — um JWT válido é válido até expirar, independente do que aconteça. Por isso, Access Tokens JWT devem ter vida curta (minutos), complementados por Refresh Tokens de vida mais longa.

O que o OAuth 2.0 NÃO resolve

OAuth autoriza o acesso a recursos, mas não define quem é o usuário. Ao final de um fluxo OAuth, o Client sabe que o usuário autorizou o acesso a determinados scopes — mas não tem uma forma padronizada de obter nome, e-mail ou qualquer atributo de identidade. Para preencher essa lacuna, surgiu o OpenID Connect.

OpenID Connect: Identidade sobre OAuth 2.0

O OpenID Connect 1.0 (OIDC), publicado em 2014 pela OpenID Foundation, é uma camada de identidade construída sobre o OAuth 2.0. Ele estende o framework de autorização com um conjunto mínimo e padronizado de capacidades de autenticação.

A adição central do OIDC ao OAuth 2.0 é o ID Token: um JWT emitido pelo Authorization Server que contém claims (afirmações) sobre a identidade do usuário autenticado.

Na prática, muitas organizações mantêm SAML para sistemas legados e adotam OIDC para novas aplicações — o que exige que o IdP suporte ambos simultaneamente, cenário comum em provedores como Okta, Entra ID e Ping Identity.

A Linha do Tempo Técnica

XML forneceu a infraestrutura: um formato universal, com primitivas de assinatura (XMLDSig) e criptografia (XML Encryption) que permitiram a troca segura de dados estruturados entre sistemas heterogêneos. Sem essa base, o SAML não seria possível.

SAML 2.0 usou essa infraestrutura para resolver a federação de identidade enterprise: organizações distintas puderam estabelecer relações de confiança e trocar assertions assinadas sobre seus usuários. Foi a primeira solução robusta para SSO na Internet em escala corporativa, e ainda é onipresente em integrações com sistemas legados.

OAuth 2.0 mudou o foco: de autenticação para autorização delegada, e de XML para JSON e REST. Ele resolveu o problema de consentimento e acesso granular a APIs — mas deliberadamente não resolveu o problema de identidade, para manter seu escopo bem definido.

OpenID Connect fechou o ciclo: adicionando uma camada padronizada de identidade sobre o OAuth 2.0, com o ID Token JWT, o UserInfo Endpoint e o mecanismo de discovery automático. Tornou-se o padrão de fato para SSO em aplicações modernas, mobile e APIs.

Entender onde cada protocolo começa e termina é o que diferencia uma integração segura de uma vulnerável.