Single sign-on means you authenticate once, to one system, and other systems trust that system's word about who you are. The system doing the vouching is the identity provider (Okta, Entra ID, Ping, Google); the systems trusting it are service providers or relying parties.

Everything else is the format of the note being passed. SAML is the older XML-based format, still dominant in enterprise applications. OIDC is the newer JSON-based one built on OAuth 2.0, standard for anything modern or mobile. They solve the same problem and you will meet both for years.

OAuth is not authentication. OAuth 2.0 is a delegated authorisation protocol — it lets an application act on a resource on your behalf. It was widely misused as a login mechanism, which is precisely why OIDC exists: it is a thin identity layer on top of OAuth that adds an ID token making an actual claim about who the user is. If someone tells you they authenticate users “with OAuth”, ask whether they mean OIDC, because the difference has produced real vulnerabilities.

• Signature validation and the trust anchor. An assertion nobody verifies is an assertion anyone can forge. Check certificate expiry too — it is a recurring self-inflicted outage.
• Audience and recipient restriction. An assertion minted for one service must not be replayable at another.
• Clock skew and assertion lifetime. Long-lived assertions are replayable.
• What happens at logout. Single logout is frequently unimplemented, so sessions survive at the service provider after the user is disabled centrally — a common and genuinely dangerous gap.
• The break-glass account that bypasses the IdP. It should exist, because an IdP outage otherwise locks out everyone including administrators; it must be heavily monitored, because it is the obvious target.

Federation moves the act of authenticating from your application to an identity provider, and hands your application an assertion about the result. What you gain is one place to enforce policy. What you take on is a dependency whose compromise is total.

• Your application never sees the password, which removes an entire class of breach from your surface — and means account recovery, lockout policy and multi-factor enforcement are no longer yours to control or to fix at three in the morning.
• A compromised identity provider is a compromise of everything federated to it. That is the trade, stated honestly. It is usually worth making, because a central provider is defended far better than fifty applications each rolling their own login.
• Validate the assertion properly or the whole thing is theatre. Check the signature against a key you actually trust, the issuer, the audience, the expiry, and the replay protection. Assertion-validation bugs are a recurring source of full authentication bypass, and they are quiet — the system keeps working perfectly for legitimate users.
• Session lifetime is where the real risk lives. Federation makes signing in easy and signing out genuinely hard: the application session, the provider session and any refresh token all expire independently. A user who has been disabled centrally can keep working until the longest of those runs out.