Cyberpediapor Brain
PTDEENESFRITNL

O SSO: SAML e OpenID Connect explicados de forma simples

Uma só conta abre várias aplicações graças a um token. O que fazem o SAML e o OpenID Connect e o que o colaborador pode fazer perante as armadilhas.

Em 30 segundos

Onde acontece
Sempre que se abre uma aplicação da empresa que reencaminha para a página de início de sessão comum.
O que o atacante quer
Um token, um cookie de sessão ou uma autorização dada a uma aplicação armadilhada, que lhe abrem o acesso sem conhecer a palavra-passe23.
O reflexo
Verificar o endereço da página de início de sessão, ativar a autenticação de dois fatores na conta principal, terminar a sessão num posto partilhado e comunicar qualquer pedido de início de sessão inesperado.
Se já aconteceu
Avisar o serviço informático sem demora, indicando a página que estava aberta e a autorização concedida.

Do que se trata

O SSO (single sign-on, início de sessão único) permite autenticar-se uma só vez junto de um fornecedor de identidade e obter depois acesso a várias aplicações, sem criar nem memorizar uma palavra-passe para cada uma1. O colaborador introduz as credenciais na página de início de sessão da empresa, e as aplicações recebem uma prova da sua identidade, e não a sua palavra-passe.

Dois protocolos servem sobretudo para esta troca: SAML e OpenID Connect (OIDC). Não se veem no ecrã, mas os seus tokens tornaram-se um alvo: roubar o token ou a sessão equivale a roubar o acesso.

Perguntas diretas

O que é o SSO?

Uma conta única, gerida por um fornecedor de identidade, serve várias aplicações. O documento do NIST sobre a federação de identidades descreve este caso: o utilizador não se autentica diretamente junto da aplicação, é o fornecedor de identidade que produz uma asserção, muitas vezes a pedido da aplicação1. O NIST precisa que este mecanismo dispensa o utilizador de ter credenciais separadas para cada serviço1.

Qual é a diferença entre SAML e OpenID Connect?

O SAML 2.0 é um protocolo que permite às aplicações oferecer SSO aos seus utilizadores; troca asserções entre o fornecedor de identidade e a aplicação4. O OpenID Connect estende o protocolo de autorização OAuth 2.0 para o transformar num protocolo de autenticação, e o SSO passa por um token de segurança chamado token de identidade (ID token)5. O NIST cita ambos como exemplos de protocolos de federação, com uma asserção que assume a forma de um ID token OIDC ou de uma asserção SAML1.

O SSO é menos seguro do que uma palavra-passe por aplicação?

Desloca o risco mais do que o elimina. O colaborador deixa de ter uma palavra-passe para gerir em cada aplicação1, mas uma conta única abre vários serviços: se um atacante assumir o controlo dela, todos os que a aceitam ficam expostos. As armadilhas descritas mais abaixo detalham este ponto.

O que protege a autenticação de dois fatores, e o que não protege?

Protege o início de sessão inicial. Não protege contra um token ou um cookie já roubado: o acesso direto por token anula o efeito de um segundo fator6, e os cookies de sessão podem contornar certos protocolos de autenticação multifator3.

1Como funciona2 min

Dois intervenientes trocam informações: o fornecedor de identidade, que autentica a pessoa, e a aplicação, que confia no que ele afirma4. O NIST chama à aplicação «parte utilizadora» (relying party) e dá o nome de asserção à mensagem do fornecedor de identidade que a informa sobre a pessoa1.

Com o SAML, a Microsoft explica que a aplicação regista junto do fornecedor de identidade um endereço de redirecionamento e um endereço de metadados, que permitem obter a chave de assinatura4. Com o OIDC, a aplicação obtém também um documento de configuração público, que indica os endereços úteis e as chaves públicas usadas para verificar a assinatura dos tokens5. A OWASP descreve, para o SAML, uma resposta que contém a asserção assinada digitalmente com a chave privada do fornecedor de identidade7.

Um token não é uma palavra-passe: atesta uma autenticação já efetuada. Para o SAML, a MITRE indica uma duração de vida predefinida de uma hora, modificável no token8.

Na versão 2017/2020 das suas diretrizes, hoje substituída, o NIST classifica as asserções em três níveis. No primeiro, a asserção é assinada pelo fornecedor de identidade. No segundo, é também cifrada para a aplicação. No terceiro, o utilizador prova ainda que possui uma chave associada à asserção1. A versão SP 800-63C-4, datada de julho de 2025, substitui a de 2 de março de 20209; estes três níveis não são, portanto, a regra atual1.

2O que faz1 min
  • Veja o endereço da página de início de sessão antes de introduzir uma palavra-passe. Há atacantes que captam a sessão pelo caminho, por exemplo com as ferramentas evilginx2 e Muraena, usadas em campanhas de phishing3.
  • Ative a autenticação de dois fatores na sua conta principal, a que abre as outras aplicações. Comprometer o acesso ao correio eletrónico principal pode permitir chegar a outros serviços através do procedimento de palavra-passe esquecida6.
  • Termine a sessão num posto partilhado. Os cookies de sessão permanecem muitas vezes válidos durante bastante tempo, mesmo quando a aplicação já não é utilizada3. Na Microsoft, terminar a sessão põe fim à sessão do utilizador5.
  • Leia a janela de pedido de autorização antes de clicar. Ela pede ao utilizador que conceda permissões a uma aplicação5.
  • Comunique qualquer pedido de início de sessão ou de autorização que não tenha iniciado, sobretudo depois de uma mensagem que o leve a clicar numa ligação: é assim que um atacante faz com que o acesso seja concedido à sua aplicação2.
3As armadilhas2 min

Os falsos portais de início de sessão

As ferramentas de código aberto evilginx2 e Muraena recolhem cookies de sessão através de um proxy malicioso colocado entre a vítima e o site verdadeiro3. O Kali365 obteve tokens de acesso e de atualização OAuth ao levar as vítimas a validar um pedido de autorização de dispositivo iniciado pelo atacante, e ao intercetar sessões graças a uma infraestrutura de proxy inverso2.

O roubo de token ou de sessão

Os tokens de acesso servem para fazer pedidos autorizados em nome de um utilizador6. Uma vez roubados, substituem a palavra-passe: o grupo APT29 usa tokens roubados para aceder a contas sem palavra-passe2. Estes acessos por API são difíceis de detetar, mesmo do lado do fornecedor, porque se parecem com uma utilização normal6. Alterar a palavra-passe pode também não bastar para os cortar6. Os tokens de atualização permitem obter novos tokens sem interrogar o utilizador2.

Os consentimentos OAuth abusivos

Um atacante regista a sua própria aplicação junto do servidor de autorização e envia depois uma ligação de phishing para que o alvo lhe conceda acesso2. Uma vez concedido o token, a aplicação pode obter um acesso duradouro à conta, por exemplo para pesquisar no correio eletrónico e listar os contactos26. O grupo APT28 usou aplicações disfarçadas de «Google Defender», «Google Email Protection» e «Google Scanner» para visar utilizadores do Gmail2.

A conta única como ponto de falha

Quem possuir um certificado de assinatura SAML válido pode forjar tokens com os direitos e a duração que escolher, e autenticar-se assim junto de todos os serviços que usam SAML 2.0 para o SSO8. A MITRE cita o comprometimento da SolarWinds, em que o grupo APT29 criou tokens com certificados de assinatura SAML comprometidos8.

4Casos reais1 min

2012: o envolvimento de assinatura XML

A OWASP recorda que vulnerabilidades de implementações SAML ligadas a ataques por envolvimento de assinatura XML foram descritas em 20127. Entre as suas recomendações figura uma validação segura da assinatura digital7. Este trabalho cabe às equipas informáticas, não ao colaborador.

Ficha

Identificador
CP-193
Ala
3. Protocolos e defesa
Competência Brain
Controlar os acessos (control_access)
Reflexo Brain
cr-025
Esquema
G3 · Corte anatómico
Idiomas
de, en, es, fr, it, nl, pt
Fontes
9 fontes verificadas em 3 de novembro de 2026
Fontes9 fontes
  1. NIST, «NIST Special Publication 800-63C». https://pages.nist.gov/800-63-3/sp800-63c.html (consultado em 3 de novembro de 2026)
  2. MITRE ATT&CK, «Steal Application Access Token, Technique T1528 - Enterprise | MITRE ATT&CK®». https://attack.mitre.org/techniques/T1528/ (consultado em 3 de novembro de 2026)
  3. MITRE ATT&CK, «Steal Web Session Cookie, Technique T1539 - Enterprise | MITRE ATT&CK®». https://attack.mitre.org/techniques/T1539/ (consultado em 3 de novembro de 2026)
  4. Microsoft, «How the Microsoft identity platform uses the SAML protocol - Microsoft identity platform». https://learn.microsoft.com/en-us/entra/identity-platform/saml-protocol-reference (consultado em 3 de novembro de 2026)
  5. Microsoft, «OpenID Connect (OIDC) on the Microsoft identity platform - Microsoft identity platform». https://learn.microsoft.com/en-us/entra/identity-platform/v2-protocols-oidc (consultado em 3 de novembro de 2026)
  6. MITRE ATT&CK, «Use Alternate Authentication Material: Application Access Token, Sub-technique T1550.001 - Enterprise | MITRE ATT&CK®». https://attack.mitre.org/techniques/T1550/001/ (consultado em 3 de novembro de 2026)
  7. OWASP, «SAML Security - OWASP Cheat Sheet Series». https://cheatsheetseries.owasp.org/cheatsheets/SAML_Security_Cheat_Sheet.html (consultado em 3 de novembro de 2026)
  8. MITRE ATT&CK, «Forge Web Credentials: SAML Tokens, Sub-technique T1606.002 - Enterprise | MITRE ATT&CK®». https://attack.mitre.org/techniques/T1606/002/ (consultado em 3 de novembro de 2026)
  9. NIST, «SP 800-63C-4, Digital Identity Guidelines: Federation and Assertions | CSRC». https://csrc.nist.gov/pubs/sp/800/63/c/4/final (consultado em 3 de novembro de 2026)

Citar este artigo

Brain, «O SSO: SAML e OpenID Connect explicados de forma simples», Cyberpedia, 2026. https://startbrain.io/cyberpedia/pt/articles/sso-saml-openid-connect/

BibTeX 
@misc{brain_cp193_pt_2026,
  author = {Brain},
  title = {O SSO: SAML e OpenID Connect explicados de forma simples},
  year = {2026},
  howpublished = {Cyberpedia},
  url = {https://startbrain.io/cyberpedia/pt/articles/sso-saml-openid-connect/},
  note = {CC BY 4.0}
}
Licença CC BY 4.0