Cyberpediaby Brain
ENDEFR

Single Sign-On: SAML and OpenID Connect explained

One account opens several applications through a token. What SAML and OpenID Connect do, and what employees can do about the traps.

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 password23.
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.

What it is

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 one1. 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.

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 request1. NIST states that this mechanism removes the need to hold separate credentials for each service1.

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 application4. 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 token5. NIST cites both as examples of federation protocols, with an assertion that takes the form of an OIDC ID token or a SAML assertion1.

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 application1, 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 factor6, and session cookies can bypass some multi-factor authentication protocols3.

1How it works1 min

Two parties exchange information: the identity provider, which authenticates the person, and the application, which trusts what the provider asserts4. NIST calls the application a "relying party" and calls the identity provider's message that informs it about the person an assertion1.

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 key4. 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 tokens5. OWASP describes, for SAML, a response that contains the assertion digitally signed with the identity provider's private key7.

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 token8.

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 assertion1. Version SP 800-63C-4, dated July 2025, replaces the one of 2 March 20209; these three levels are therefore not the current rule1.

2What you do1 min
  • 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 campaigns3.
  • 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 procedure6.
  • Sign out on a shared computer. Session cookies often stay valid for a long time, even when the application is no longer in use3. At Microsoft, signing out ends the user's session5.
  • Read the authorization request window before clicking. It asks the user to grant permissions to an application5.
  • 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 application2.
3Pitfalls2 min

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 site3. 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 infrastructure2.

Token or session theft

Access tokens are used to make authorized requests on behalf of a user6. Once stolen, they replace the password: the APT29 group uses stolen tokens to access accounts without a password2. These API accesses are hard to spot, even on the provider's side, because they look like normal use6. Changing one's password may also not be enough to cut them off6. Refresh tokens make it possible to obtain new ones without asking the user2.

Abusive OAuth consents

An attacker registers their own application with the authorization server, then sends a phishing link so that the target grants it access2. Once the token is granted, the application can obtain lasting access to the account, for example to search the mailbox and list contacts26. The APT28 group used applications disguised as «Google Defender», «Google Email Protection» and «Google Scanner» to target Gmail users2.

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 SSO8. MITRE cites the SolarWinds compromise, where the APT29 group created tokens with compromised SAML signing certificates8.

4Real cases1 min

2012: XML signature wrapping

OWASP recalls that vulnerabilities in SAML implementations linked to XML signature wrapping attacks were described in 20127. Among its recommendations is safe validation of the digital signature7. This work falls to IT teams, not to the employee.

Fact sheet

Identifier
CP-193
Wing
3. Protocols and defence
Brain skill
Controlling Access (control_access)
Brain reflex
cr-025
Diagram
G3 · System & Protocol Anatomy
Languages
de, en, fr
Sources
9 sources checked on 3 November 2026
Sources9 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)

Cite this article

Brain, “Single Sign-On: SAML and OpenID Connect explained”, Cyberpedia, 2026. https://startbrain.io/cyberpedia/en/articles/sso-saml-openid-connect-explained/

BibTeX 
@misc{brain_cp193_en_2026,
  author = {Brain},
  title = {Single Sign-On: SAML and OpenID Connect explained},
  year = {2026},
  howpublished = {Cyberpedia},
  url = {https://startbrain.io/cyberpedia/en/articles/sso-saml-openid-connect-explained/},
  note = {CC BY 4.0}
}
CC BY 4.0 licence