Half the confusion in identity comes from comparing things that aren’t comparable. SAML and OpenID Connect answer “who is this user?” and hand you single sign-on. OAuth 2.0 answers a different question — “may this app act on the user’s behalf?” — and was never meant to log anyone in. SSH isn’t web identity at all; it’s a secure channel for reaching a machine. Sort them by the question they answer and the whole space clicks into place.
1 · The Distinction Everything Hinges On
Two words that sound alike and mean opposite halves of access. Every protocol here is really just one or the other, done over the network with a trusted third party in the middle.
| Concept | The question | Answered by |
|---|---|---|
| Authentication (AuthN) | “Who are you?” — proving identity | SAML OIDC SSH |
| Authorization (AuthZ) | “What may you (or an app) do?” — granting access | OAuth 2.0 |
▸ This is why “log in with OAuth” is technically wrong. OAuth grants an app a token to access resources; to actually prove identity on top of it you need OpenID Connect, which adds an ID token.
2 · The Four, Side by Side
| Protocol | Does | Format / transport | Typical use |
|---|---|---|---|
| SAML 2.0 | AuthN + SSO | XML assertions, browser redirects/POST | Enterprise web SSO, workforce apps |
| OAuth 2.0 | AuthZ | Access tokens (often JWT), HTTPS | Delegated API access (“let app X read my calendar”) |
| OpenID Connect | AuthN on OAuth | ID token (JWT) + OAuth flow | Modern app, mobile & consumer login |
| SSH | AuthN + secure channel | Binary protocol over TCP :22 | Remote server/CLI access, tunnels, git |
OIDC is the modern default for logging users into apps; SAML still rules the enterprise where legacy SSO is entrenched.
3 · How Each Flow Works
Different artefacts, one shape: the resource never sees your password — a trusted party vouches instead.
SAML — SP-initiated SSO
OAuth 2.0 / OIDC — authorization code flow
SSH — secure remote access
authorized_keys▸ The common thread: a signed assertion (SAML), a token (OAuth/OIDC) or a session key (SSH) replaces sending your credentials to the thing you’re accessing.
4 · When to Use Which
| Your goal | Reach for |
|---|---|
| Enterprise web SSO across workforce apps (incl. legacy) | SAML 2.0 |
| Let a third-party app access an API on the user’s behalf | OAuth 2.0 |
| Log users into a modern web/mobile/consumer app | OpenID Connect |
| Securely reach a server, run commands, tunnel, or push git | SSH |
Bottom line
- “SAML vs OAuth” is a category error — one authenticates, one authorizes.
- Want login? Use OIDC (or SAML) — not raw OAuth, which only delegates access.
- SAML for the enterprise, OIDC for the modern app — same job, different eras and formats (XML vs JWT).
- SSH is a different layer — machine/human remote access and an encrypted channel, not web SSO.
- Same principle underneath — a trusted third party vouches so the resource never handles your password.
Sources & method. Descriptions follow the protocol specifications — SAML 2.0 (OASIS), OAuth 2.0 (RFC 6749), OpenID Connect (OpenID Foundation) and the SSH protocol (RFC 4251–4254). Flows are simplified to the common case (SP-initiated SSO; authorization-code grant; public-key SSH). Original synthesis; no third-party graphics or text reproduced.