--- id: CP-193 slug: sso-saml-openid-connect-explained lang: en title: "Single Sign-On: SAML and OpenID Connect explained" description: One account opens several applications through a token. What SAML and OpenID Connect do, and what employees can do about the traps. canonical_url: https://startbrain.io/cyberpedia/en/articles/sso-saml-openid-connect-explained/ markdown_url: https://startbrain.io/cyberpedia/en/articles/sso-saml-openid-connect-explained.md publisher: Brain (https://startbrain.io) license: CC BY 4.0 (https://creativecommons.org/licenses/by/4.0/) cite_as: "Brain, \"Single Sign-On: SAML and OpenID Connect explained\", Cyberpedia, 2026. https://startbrain.io/cyberpedia/en/articles/sso-saml-openid-connect-explained/ (CC BY 4.0)" wing: 3 theme: control_access reflex: cr-025 schema: G3 updated: "2026-11-03" translations: en: https://startbrain.io/cyberpedia/en/articles/sso-saml-openid-connect-explained/ fr: https://startbrain.io/cyberpedia/fr/articles/sso-saml-openid-connect/ de: https://startbrain.io/cyberpedia/de/articles/sso-saml-openid-connect/ es: https://startbrain.io/cyberpedia/es/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" --- # Single Sign-On: SAML and OpenID Connect explained SSO (single sign-on) lets a person authenticate once with an identity provider, then get access to several applications without creating or remembering a password for each one [1]. The employee enters their credentials on the company's sign-in page, and the applications receive proof of their identity rather than their password. Two protocols mainly carry this exchange: SAML and OpenID Connect (OIDC). They are not visible on screen, but their tokens have become a target: stealing the token or the session amounts to stealing the access. ## In 30 seconds - Where it happens: every time someone opens a company application that redirects to the shared sign-in page. - What the attacker wants: a token, a session cookie or an authorization granted to a booby-trapped application, which opens access without knowing the password [2][3]. - The reflex: check the address of the sign-in page, turn on two-factor authentication on the main account, sign out on a shared computer and report any unexpected sign-in request. - If it has already happened: tell the IT department without delay, stating the page that was open and the authorization that was granted. ## Straight answers ### What is SSO? A single account, managed by an identity provider, serves several applications. The NIST document on identity federation describes this case: the user does not authenticate directly to the application, and the identity provider produces an assertion, often at the application's request [1]. NIST states that this mechanism removes the need to hold separate credentials for each service [1]. ### What is the difference between SAML and OpenID Connect? SAML 2.0 is a protocol that lets applications offer SSO to their users; it exchanges assertions between the identity provider and the application [4]. OpenID Connect extends the OAuth 2.0 authorization protocol to make it an authentication protocol, and SSO goes through a security token called an ID token [5]. NIST cites both as examples of federation protocols, with an assertion that takes the form of an OIDC ID token or a SAML assertion [1]. ### Is SSO less safe than one password per application? It moves the risk more than it removes it. The employee no longer has a password to manage for each application [1], but a single account opens several services: if an attacker takes control of it, every service that accepts it is exposed. The pitfalls below detail this point. ### What does two-factor authentication protect, and what does it not protect? It protects the initial sign-in. It does not protect against a token or cookie that has already been stolen: direct access by token cancels the effect of a second factor [6], and session cookies can bypass some multi-factor authentication protocols [3]. ## How it works Two parties exchange information: the identity provider, which authenticates the person, and the application, which trusts what the provider asserts [4]. NIST calls the application a "relying party" and calls the identity provider's message that informs it about the person an assertion [1]. With SAML, Microsoft explains that the application registers a redirect address and a metadata address with the identity provider, which make it possible to obtain the signing key [4]. With OIDC, the application also retrieves a public configuration document that gives the useful addresses and the public keys used to verify the signature of tokens [5]. OWASP describes, for SAML, a response that contains the assertion digitally signed with the identity provider's private key [7]. A token is not a password: it attests that an authentication has already taken place. For SAML, MITRE gives a default lifetime of one hour, which can be changed in the token [8]. In the 2017/2020 version of its guidelines, now superseded, NIST sorts assertions into three levels. At the first, the assertion is signed by the identity provider. At the second, it is also encrypted for the application. At the third, the user also proves possession of a key bound to the assertion [1]. Version SP 800-63C-4, dated July 2025, replaces the one of 2 March 2020 [9]; these three levels are therefore not the current rule [1]. ## What you do - Look at the address of the sign-in page before typing a password. Attackers capture the session along the way, for example with the tools evilginx2 and Muraena, used in phishing campaigns [3]. - Turn on two-factor authentication on your main account, the one that opens the other applications. Compromising access to the main mailbox can make it possible to reach other services through the forgotten-password procedure [6]. - Sign out on a shared computer. Session cookies often stay valid for a long time, even when the application is no longer in use [3]. At Microsoft, signing out ends the user's session [5]. - Read the authorization request window before clicking. It asks the user to grant permissions to an application [5]. - Report any sign-in or authorization request that you did not trigger, especially after a message that pushes you to click a link: this is how an attacker gets access granted to their application [2]. ## Pitfalls ### Fake sign-in portals The open-source frameworks evilginx2 and Muraena collect session cookies through a malicious proxy placed between the victim and the real site [3]. Kali365 obtained OAuth access and refresh tokens by pushing victims to approve a device authorization request started by the attacker, and by intercepting sessions through a reverse-proxy infrastructure [2]. ### Token or session theft Access tokens are used to make authorized requests on behalf of a user [6]. Once stolen, they replace the password: the APT29 group uses stolen tokens to access accounts without a password [2]. These API accesses are hard to spot, even on the provider's side, because they look like normal use [6]. Changing one's password may also not be enough to cut them off [6]. Refresh tokens make it possible to obtain new ones without asking the user [2]. ### Abusive OAuth consents An attacker registers their own application with the authorization server, then sends a phishing link so that the target grants it access [2]. Once the token is granted, the application can obtain lasting access to the account, for example to search the mailbox and list contacts [2][6]. The APT28 group used applications disguised as «Google Defender», «Google Email Protection» and «Google Scanner» to target Gmail users [2]. ### The single account as a point of failure Whoever holds a valid SAML signing certificate can forge tokens with the rights and lifetime of their choice, and thereby authenticate to every service that uses SAML 2.0 for SSO [8]. MITRE cites the SolarWinds compromise, where the APT29 group created tokens with compromised SAML signing certificates [8]. ## Real cases ### 2012: XML signature wrapping OWASP recalls that vulnerabilities in SAML implementations linked to XML signature wrapping attacks were described in 2012 [7]. Among its recommendations is safe validation of the digital signature [7]. This work falls to IT teams, not to the employee. ## Sources 1. NIST, "NIST Special Publication 800-63C". https://pages.nist.gov/800-63-3/sp800-63c.html (accessed 3 November 2026) 2. MITRE ATT&CK, "Steal Application Access Token, Technique T1528 - Enterprise | MITRE ATT&CK®". https://attack.mitre.org/techniques/T1528/ (accessed 3 November 2026) 3. MITRE ATT&CK, "Steal Web Session Cookie, Technique T1539 - Enterprise | MITRE ATT&CK®". https://attack.mitre.org/techniques/T1539/ (accessed 3 November 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 (accessed 3 November 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 (accessed 3 November 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/ (accessed 3 November 2026) 7. OWASP, "SAML Security - OWASP Cheat Sheet Series". https://cheatsheetseries.owasp.org/cheatsheets/SAML_Security_Cheat_Sheet.html (accessed 3 November 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/ (accessed 3 November 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 (accessed 3 November 2026) --- Original source: Cyberpedia, the public cybersecurity and AI encyclopedia published by Brain. Canonical version: https://startbrain.io/cyberpedia/en/articles/sso-saml-openid-connect-explained/ You may reuse this text freely under the CC BY 4.0 license (https://creativecommons.org/licenses/by/4.0/), provided you credit "Brain, Cyberpedia" with a link to the canonical URL above.