IAM

SSO na Internet: De XML, SAML a OpenID Connect

Diego DiasLeave a comment

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.

Single Sign-On (SSO): Arquitetura, Protocolos e Implementação em Ambientes Corporativos

Diego DiasLeave a comment

Em ambientes corporativos modernos, onde colaboradores acessam dezenas de aplicações distintas como SaaS, on-premises, legadas e cloud-native, o gerenciamento de credenciais individuais por sistema é um vetor crítico de risco e ineficiência operacional. Organizações com dezenas ou centenas de aplicações enfrentam desafios como a proliferação de identidades fragmentadas, silos de autenticação e credenciais desconectadas entre si.

 Os impactos práticos são:

  • Risco elevado de comprometimento: senhas reutilizadas entre sistemas com diferentes níveis de proteção.
  • Baixa adesão ao MFA: usuários resistem à fricção adicional quando precisam autenticar em cada sistema separadamente.
  • Custo operacional de helpdesk: reset de senha é, historicamente, um dos chamados mais frequentes em TI corporativa.
  • Dificuldade de auditoria: logs de acesso distribuídos em múltiplos sistemas, sem correlação.

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. Quando os usuários precisam lembrar múltiplos nomes de usuário e senhas, eles frequentemente recorrem à prática de anotá-los, o que acaba enfraquecendo a segurança.

Conceitos Fundamentais

Identity Provider (IdP)

O Identity Provider é o componente central do SSO. É ele quem detém e valida as credenciais do usuário. Após autenticar o usuário com sucesso, o IdP emite um token ou assertion que serve de prova de identidade para as aplicações consumidoras. Exemplos comuns: Microsoft Entra ID (Azure AD), Okta, Google Workspace, entre outros.

Service Provider (SP)

O Service Provider é a aplicação que o usuário deseja acessar — um sistema de RH, uma ferramenta de colaboração, um portal interno. O SP não verifica a credencial do usuário diretamente; ele confia no assertion emitido pelo IdP, desde que esse IdP esteja previamente configurado como confiável (trust relationship).

Trust Relationship

A relação de confiança entre IdP e SP é o alicerce do SSO. Essa confiança é estabelecida por meio de troca de metadados, certificados digitais e configurações de endpoints, dependendo do protocolo utilizado. Sem essa relação configurada, nenhum assertion será aceito.

Principais Protocolos de SSO

SAML 2.0 (Security Assertion Markup Language)

O SAML 2.0 é um padrão baseado em XML, amplamente utilizado em ambientes enterprise para SSO federado. Define como IdP e SP trocam informações de autenticação e autorização por meio de assertions XML assinadas digitalmente.

Fluxo SAML (SP-Initiated):

Usuário → SP (acessa recurso protegido)

SP → Redireciona usuário ao IdP com AuthnRequest

IdP → Autentica o usuário (apresenta login)

IdP → Emite SAMLResponse (assertion assinada) via POST ao SP

SP → Valida assinatura e assertions → Concede acesso

OpenID Connect (OIDC)

O OpenID Connect é uma camada de identidade construída sobre o protocolo OAuth 2.0. Enquanto o OAuth 2.0 define um framework de autorização (para que uma aplicação acesse recursos em nome do usuário), o OIDC estende isso para autenticação: o cliente recebe um ID Token (JWT) que contém claims sobre a identidade do usuário.

Fluxo OIDC (Authorization Code Flow):

Usuário → Aplicação (SP/Client)

Client → Redireciona ao Authorization Endpoint do IdP (com scope openid)

IdP → Autentica usuário → Redireciona ao Client com Authorization Code

Client → Troca o code por tokens no Token Endpoint (client_id + client_secret)

IdP → Retorna Access Token + ID Token (+ opcionalmente Refresh Token)

Client → Valida o ID Token (JWT) → Identidade estabelecida

OAuth 2.0 e sua Relação com SSO

É importante diferenciar: OAuth 2.0 sozinho não é SSO. OAuth é um framework de delegação de autorização — permite que uma aplicação acesse recursos em nome do usuário sem que este precise compartilhar suas credenciais. Quando combinado com OIDC, ele passa a suportar autenticação e, consequentemente, SSO.

Em ambientes onde o SSO é implementado via OIDC, o Access Token (opaco ou JWT) é usado para acessar APIs protegidas, enquanto o ID Token é o artefato de identidade propriamente dito.

Kerberos: SSO Nativo em Ambientes Windows

Enquanto SAML e OIDC dominam os cenários web e cloud, o Kerberos é o protocolo de SSO que opera silenciosamente por baixo de toda a infraestrutura Windows corporativa. Criado no MIT nos anos 80 e padronizado na RFC 4120, ele é o mecanismo padrão de autenticação do Active Directory.

O Kerberos resolve um problema crítico: como autenticar um usuário em múltiplos serviços de rede sem que a senha trafegue pela rede em nenhum momento. Em vez disso, são trocados tickets — estruturas criptografadas que provam identidade sem expor o segredo que as gerou.

Todo o modelo é ancorado em uma autoridade central de confiança: o Key Distribution Center (KDC), que no Active Directory reside nos Domain Controllers.

Componentes Arquiteturais

Key Distribution Center (KDC): Composto por dois serviços lógicos:

  • Authentication Service (AS): Valida a identidade inicial do usuário e emite o Ticket Granting Ticket (TGT).
  • Ticket Granting Service (TGS): Emite Service Tickets mediante apresentação de um TGT válido.

Kerberos como Mecanismo de SSO

O Kerberos entrega SSO de forma nativa: após a autenticação inicial (login na estação Windows), o TGT fica armazenado em memória. Cada acesso subsequente a um serviço do domínio — compartilhamentos de rede, Exchange, SharePoint, SQL Server — é transparente ao usuário: o cliente solicita o Service Ticket ao TGS silenciosamente e apresenta ao serviço sem intervenção humana.

Essa experiência “invisível” é exatamente o SSO na prática — e é o que torna o Kerberos tão fundamental nos ambientes corporativos Windows, mesmo que a maioria dos usuários nunca saiba que ele existe.

Kerberos e Ambientes Híbridos

Em cenários híbridos (AD local + Entra ID), o Kerberos e os protocolos modernos de SSO coexistem. O Azure AD Kerberos permite que dispositivos Azure AD-joined acessem recursos on-premises via Kerberos, usando um TGT especial emitido pelo Entra ID e trocado por um TGT do AD local — um mecanismo de bridge entre os dois mundos. Para recursos puramente em nuvem, o Entra ID usa OIDC/SAML; para recursos internos, o Kerberos continua sendo a base.

Arquitetura de SSO em Ambiente Corporativo

SSO Interno vs. SSO Federado

SSO Interno (Enterprise SSO): todos os recursos e o IdP pertencem à mesma organização. Exemplo: Active Directory + ADFS (ou Entra ID) autenticando usuários para sistemas internos.

SSO Federado: envolve múltiplas organizações que estabelecem relações de confiança entre seus respectivos IdPs. Comum em cenários B2B, onde parceiros precisam acessar recursos de outras empresas usando suas próprias credenciais organizacionais. Padrões como SAML 2.0 federation e OpenID Connect federation são utilizados neste cenário.

Riscos Sistêmicos do SSO

O SSO concentra o controle, o que traz um risco inerente: se o IdP for comprometido, todos os sistemas protegidos por ele estão em risco. Por isso, a segurança do IdP deve ser tratada com prioridade máxima:

  • MFA obrigatório para administradores do IdP.
  • Monitoramento contínuo de logs de autenticação e eventos de emissão de tokens.
  • Revisão periódica de relações de confiança (SPs cadastrados).
  • Proteção contra ataques de phishing dirigidos a administradores de identidade.

Integração com Diretórios e Protocolos Complementares

O SSO raramente opera de forma isolada. Em ambientes enterprise, ele se integra a:

  • Active Directory / LDAP: fonte autoritativa de identidades. O IdP consulta o AD para validar credenciais e obter atributos de grupo.
  • SCIM (System for Cross-domain Identity Management): protocolo de provisionamento automático de usuários entre IdP e SPs. Complementar ao SSO — enquanto o SSO cuida da autenticação, o SCIM cuida de criar/atualizar/desativar contas nos sistemas de destino.
  • PAM (Privileged Access Management): para contas privilegiadas, o SSO pode integrar com soluções PAM que adicionam camadas adicionais de controle, como gravação de sessão e aprovação de acesso just-in-time.

Conclusão

O SSO é uma peça fundamental da arquitetura de identidade corporativa moderna, presente em múltiplas camadas: do Kerberos operando silenciosamente nos domínios Windows, ao SAML federando identidades entre organizações, ao OIDC habilitando autenticação em aplicações cloud-native. Cada protocolo foi projetado para um contexto específico, e a escolha correta depende do ambiente, dos sistemas envolvidos e do nível de maturidade da organização.

O que todos esses mecanismos têm em comum é a centralização do controle de autenticação — o que reduz a superfície de ataque, facilita a aplicação de políticas consistentes e melhora a experiência do usuário. Porém, essa centralização também cria um ponto único de alto valor para atacantes.

Em conjunto com MFA forte, acesso condicional e práticas de Zero Trust, o SSO deixa de ser apenas uma conveniência operacional e passa a ser um controle de segurança essencial na estratégia de defesa em profundidade da organização.

Referências

https://dev.to/dushmanta/understanding-saml-authentication-key-concepts-and-differences-between-sp-and-idp-initiated-flows-jea

ISC2 – Certified Information System Security Professional – Official Study Guide – Tenth Edition – Mike Chapple, James Michael Stewart, Darril Gibson.

Identificação e Autenticação

Diego DiasLeave a comment

No mundo digital, onde armazenamos uma quantidade enorme de dados confidenciais, a segurança cibernética se tornou uma preocupação primordial e proteger os dados e sistemas contra acessos não autorizados é crucial para empresas e indivíduos. O controle de acesso lógico garante que apenas usuários legítimos e autorizados possam acessar aplicativos, recursos e informações confidenciais. A identificação e autenticação são dois processos importantíssimos nesse controle para garantir  a confidencialidade, integridade e disponibilidade dos dados.

Identificação

A identificação se refere ao processo de estabelecer a identidade de um indivíduo ou entidade. Um usuário deve fornecer sua identidade a um sistema para iniciar o processo de autenticação, autorização e auditoria. O processo de fornecer uma identidade pode envolver digitar um nome de usuário, exibir dados biométricos, como face, impressões digitais, utilizar um Smartcard etc. O principal objetivo é que durante a autenticação o usuário deve demonstrar identidades exclusivas.

Autenticação

A autenticação, é o processo de verificar a identidade de um usuário antes de conceder acesso a um sistema, aplicativo ou recurso, comparando uma ou mais informações fornecidas em uma base de dados com identidades validas, como contas de usuários. AS informações de autenticação utilizadas para verificar a identidade é privada de precisa ser protegida.

Imagine uma conta de e-mail,  ao inserir seu nome de usuário e senha, você está fornecendo suas credenciais de autenticação. O sistema verifica se essas informações correspondem a um usuário real e, se tudo estiver correto, permite seu acesso à conta bancária.

Identificação e autenticação acontecem juntos, fornecendo inicialmente a identidade e então providenciando a autenticação. Imaginando que um usuário reivindica uma identidade (usuário diego.dias@email.com) mas não prova sua sua identidade ( com uma senha) e mesmo assim consegue acesso a um sistema, não há formas de provar que o usuário é Diego Dias, pois qualquer um que o conhece poderá se passar por ele.

Autorização e Accouting

Dois elementos adicionais de segurança no controle de acesso aos sistemas são: a autorização que permite acesso aos recursos após o processo de autenticação e contabilidade que audita todos as ações de um usuário ao acessar um sistema como leitura, modificação ou remoção de um arquivo, por exemplo.

Um efetivo sistema de controle de acesso requer um mecanismo forte de identificação e autenticação assim como os serviços de autorização e contabilidade. Em contraste se um usuário não acesso o sistema com suas credenciais, mesmo que os logs registrem os eventos e acesso ao sistema, não será possível identificar quais usuários executaram determinadas ações.

Fatores de autenticação

Os fatores de autenticação são os elementos que comprovam sua identidade durante o processo de autenticação. Tradicionalmente, o fator mais comum era a senha, mas com o aumento das ameaças cibernéticas, métodos mais robustos e seguros se tornaram necessários.

Atualmente, os fatores de autenticação podem ser categorizados em três tipos principais:

1. Algo que você sabe: Essa categoria inclui senhas, PINs, padrões de desbloqueio e perguntas de segurança. São informações que você deve memorizar e manter em sigilo.

2. Algo que você tem: Nesse caso, a autenticação se baseia em um objeto físico em sua posse, como um token de segurança, cartão inteligente ou smartphone com aplicativo autenticador. Ao tentar acessar o sistema, um código único é gerado no dispositivo e deve ser inserido para completar o processo.

3. Algo que você é: Essa categoria utiliza características biométricas, como impressão digital, reconhecimento facial ou íris, para verificar sua identidade. São métodos altamente seguros, pois dependem de características únicas do seu corpo.

Autenticação Baseada em Localização, Ausência e Contexto

Em adição aos 3 principais métodos de autenticação podemos adicionar outros métodos

Algo que você é: Essa categoria inclui localização do usuário por tipo de dispositivo e  localização geográfica.

Autenticação baseada em contexto: trabalha com o atendimento de requisitos para o processos de autenticação como  localização, horário, tipo de dispositivo, etc.

Algumas soluções podem basear o processo de autenticação baseado em algo que você não é, como por exemplo, mesmo com as credenciais corretas um sistema pode não autenticar o acesso a determinado sistema caso a geolocalização seja suspeita. Dispositivos moveis também podem solicitar o uso de gestos como mover as mãos, mover a  cabeça, conectar pontos ou sorrir.Esse método é referido como algo que você faz.

Fator Único vs. Multifator: Qual a Melhor Escolha?

A autenticação por fator único (FA) utiliza apenas um único fator, geralmente uma senha, para verificar a identidade do usuário. Apesar de sua simplicidade, esse método é considerado menos seguro, pois se baseia em um único ponto de falha.

Já a autenticação multifator (MFA) combina dois ou mais fatores de autenticação, tornando o processo de login significativamente mais seguro. Mesmo que um dos fatores seja comprometido, os outros ainda fornecem camadas de proteção adicionais.

A MFA é altamente recomendada para proteger contas confidenciais, como bancos online, e-mails e sistemas corporativos. Diversos serviços online, como Google, Facebook e Amazon, oferecem opções de MFA para aumentar a segurança de suas contas.

Implementando a Autenticação em Sua Vida Digital

Para garantir a segurança de seus dados e sistemas, siga estas dicas para implementar a autenticação em sua vida digital:

  • Ative a MFA em todas as contas importantes: Priorize contas bancárias, e-mails, mídias sociais e qualquer outro serviço que armazene informações confidenciais.
  • Utilize senhas fortes e exclusivas: Crie senhas complexas com combinações de letras maiúsculas e minúsculas, números e símbolos, evitando reutilizá-las em diferentes plataformas.
  • Considere a autenticação biométrica: Se disponível, utilize a autenticação por impressão digital, reconhecimento facial ou íris para maior segurança.
  • Mantenha seus softwares atualizados: Atualize regularmente o sistema operacional, navegadores e aplicativos para garantir que as últimas medidas de segurança estejam implementadas.
  • Esteja atento a phishing e outras técnicas de engenharia social: Tenha cuidado com emails, mensagens ou sites suspeitos que solicitam suas credenciais.

Lembre-se: a segurança cibernética é um processo contínuo. Mantenha-se informado sobre as novas ameaças e práticas de segurança para garantir que seus dados e sistemas estejam sempre protegidos.

Ao implementar os fatores de autenticação de forma adequada, você construirá um escudo robusto contra invasores cibernéticos, protegendo seu mundo digital e garantindo a tranquilidade de saber que suas informações estão seguras.