--- id: CP-193 slug: sso-saml-openid-connect lang: pt title: "O SSO: SAML e OpenID Connect explicados de forma simples" description: 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. canonical_url: https://startbrain.io/cyberpedia/pt/articles/sso-saml-openid-connect/ markdown_url: https://startbrain.io/cyberpedia/pt/articles/sso-saml-openid-connect.md publisher: Brain (https://startbrain.io) license: CC BY 4.0 (https://creativecommons.org/licenses/by/4.0/) cite_as: "Brain, «O SSO: SAML e OpenID Connect explicados de forma simples», Cyberpedia, 2026. https://startbrain.io/cyberpedia/pt/articles/sso-saml-openid-connect/ (CC BY 4.0)" wing: 3 theme: control_access reflex: cr-025 schema: G3 updated: "2026-11-03" translations: pt: https://startbrain.io/cyberpedia/pt/articles/sso-saml-openid-connect/ fr: https://startbrain.io/cyberpedia/fr/articles/sso-saml-openid-connect/ en: https://startbrain.io/cyberpedia/en/articles/sso-saml-openid-connect-explained/ de: https://startbrain.io/cyberpedia/de/articles/sso-saml-openid-connect/ es: https://startbrain.io/cyberpedia/es/articles/sso-saml-openid-connect/ it: https://startbrain.io/cyberpedia/it/articles/sso-saml-openid-connect/ nl: https://startbrain.io/cyberpedia/nl/articles/sso-saml-openid-connect/ sources: - "n": 1 title: NIST Special Publication 800-63C publisher: NIST url: https://pages.nist.gov/800-63-3/sp800-63c.html accessed: "2026-11-03" - "n": 2 title: Steal Application Access Token, Technique T1528 - Enterprise | MITRE ATT&CK® publisher: MITRE ATT&CK url: https://attack.mitre.org/techniques/T1528/ accessed: "2026-11-03" - "n": 3 title: Steal Web Session Cookie, Technique T1539 - Enterprise | MITRE ATT&CK® publisher: MITRE ATT&CK url: https://attack.mitre.org/techniques/T1539/ accessed: "2026-11-03" - "n": 4 title: How the Microsoft identity platform uses the SAML protocol - Microsoft identity platform publisher: Microsoft url: https://learn.microsoft.com/en-us/entra/identity-platform/saml-protocol-reference accessed: "2026-11-03" - "n": 5 title: OpenID Connect (OIDC) on the Microsoft identity platform - Microsoft identity platform publisher: Microsoft url: https://learn.microsoft.com/en-us/entra/identity-platform/v2-protocols-oidc accessed: "2026-11-03" - "n": 6 title: "Use Alternate Authentication Material: Application Access Token, Sub-technique T1550.001 - Enterprise | MITRE ATT&CK®" publisher: MITRE ATT&CK url: https://attack.mitre.org/techniques/T1550/001/ accessed: "2026-11-03" - "n": 7 title: SAML Security - OWASP Cheat Sheet Series publisher: OWASP url: https://cheatsheetseries.owasp.org/cheatsheets/SAML_Security_Cheat_Sheet.html accessed: "2026-11-03" - "n": 8 title: "Forge Web Credentials: SAML Tokens, Sub-technique T1606.002 - Enterprise | MITRE ATT&CK®" publisher: MITRE ATT&CK url: https://attack.mitre.org/techniques/T1606/002/ accessed: "2026-11-03" - "n": 9 title: "SP 800-63C-4, Digital Identity Guidelines: Federation and Assertions | CSRC" publisher: NIST url: https://csrc.nist.gov/pubs/sp/800/63/c/4/final accessed: "2026-11-03" --- # O SSO: SAML e OpenID Connect explicados de forma simples 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 uma [1]. 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. ## 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-passe [2][3]. - 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. ## 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ção [1]. O NIST precisa que este mecanismo dispensa o utilizador de ter credenciais separadas para cada serviço [1]. ### 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ção [4]. 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 SAML [1]. ### 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ção [1], 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 fator [6], e os cookies de sessão podem contornar certos protocolos de autenticação multifator [3]. ## Como funciona Dois intervenientes trocam informações: o fornecedor de identidade, que autentica a pessoa, e a aplicação, que confia no que ele afirma [4]. 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 pessoa [1]. 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 assinatura [4]. 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 tokens [5]. A OWASP descreve, para o SAML, uma resposta que contém a asserção assinada digitalmente com a chave privada do fornecedor de identidade [7]. 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 token [8]. 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ção [1]. A versão SP 800-63C-4, datada de julho de 2025, substitui a de 2 de março de 2020 [9]; estes três níveis não são, portanto, a regra atual [1]. ## O que faz - 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 phishing [3]. - 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 esquecida [6]. - 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 é utilizada [3]. Na Microsoft, terminar a sessão põe fim à sessão do utilizador [5]. - Leia a janela de pedido de autorização antes de clicar. Ela pede ao utilizador que conceda permissões a uma aplicação [5]. - 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ção [2]. ## As armadilhas ### 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 verdadeiro [3]. 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 inverso [2]. ### O roubo de token ou de sessão Os tokens de acesso servem para fazer pedidos autorizados em nome de um utilizador [6]. Uma vez roubados, substituem a palavra-passe: o grupo APT29 usa tokens roubados para aceder a contas sem palavra-passe [2]. Estes acessos por API são difíceis de detetar, mesmo do lado do fornecedor, porque se parecem com uma utilização normal [6]. Alterar a palavra-passe pode também não bastar para os cortar [6]. Os tokens de atualização permitem obter novos tokens sem interrogar o utilizador [2]. ### 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 acesso [2]. 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 contactos [2][6]. O grupo APT28 usou aplicações disfarçadas de «Google Defender», «Google Email Protection» e «Google Scanner» para visar utilizadores do Gmail [2]. ### 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 SSO [8]. A MITRE cita o comprometimento da SolarWinds, em que o grupo APT29 criou tokens com certificados de assinatura SAML comprometidos [8]. ## Casos reais ### 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 2012 [7]. Entre as suas recomendações figura uma validação segura da assinatura digital [7]. Este trabalho cabe às equipas informáticas, não ao colaborador. ## 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) --- Fonte original: Cyberpedia, a enciclopédia pública de cibersegurança e IA publicada pela Brain. Versão canónica: https://startbrain.io/cyberpedia/pt/articles/sso-saml-openid-connect/ Pode reutilizar livremente este texto sob a licença CC BY 4.0 (https://creativecommons.org/licenses/by/4.0/), desde que cite «Brain, Cyberpedia» com uma ligação para o endereço acima.