Skip to content

CONCEPT Cited by 3 sources

SSO authentication (OpenID Connect)

Single sign-on (SSO) is the pattern where a user authenticates once against an identity provider (IdP) and then uses the resulting token to prove their identity to many downstream services — without re-entering credentials per service.

OpenID Connect (OIDC) is the dominant SSO protocol on the modern web. An OIDC IdP — called an OpenID Provider (OP) in the spec — issues ID Tokens after authenticating a user. An ID Token is a signed JWT carrying identity claims (iss, sub, email, name, aud, exp).

Why SSO is the "rare security-and-convenience win"

SSO is unusual among security technologies: it makes things both more secure and more convenient at the same time. Users sign in once and get access to many systems; operators get a single place to enforce MFA, password policy, off-boarding, session revocation, and audit.

This shape shows up across the wiki in different substrates:

What OIDC ID Tokens can and cannot do

Can: - Prove who the user is (to anyone who trusts the OP). - Carry arbitrary claims the OP chooses to include (groups, org, roles).

Cannot, on their own: - Serve as a key-based credential in protocols like SSH or E2E messaging, because they don't include the user's public key. The PK Token primitive (OpenPubkey) fills this gap.

Terminology

  • IdP (identity provider): generic term for any system that authenticates users.
  • OP (OpenID Provider): specifically an IdP that implements OIDC. This wiki uses "OP" when talking about OIDC and "IdP" when talking about identity providers more generally.
  • Common OPs: Google, Azure AD / Entra, Okta, Auth0, AWS Cognito, GitHub.

Seen in

  • sources/2025-03-25-cloudflare-opkssh-open-sourcing — OPKSSH extends OIDC SSO to SSH. "SSO is the rare security technology that both increases convenience — users only need to sign in once to get access to many different systems — and increases security."
  • sources/2026-02-05-aws-convera-verified-permissions-fine-grained-authorization — Okta as OP, Cognito federating identity, pre-token-gen hook enriching claims.
  • sources/2025-04-15-yelp-journey-to-zero-trust-access — Yelp's auth-protocol ladder LDAP → SAML → OIDC. Named critique of prior rungs: LDAP "lacked advanced user and device trust verification"; SAML-via-Ivanti-Pulse had "cumbersome browser-to-VPN client handoff for session authentication." OIDC chosen specifically because it supports device-posture policies in the IdP (Okta) layer. Canonical corporate-network-access instance of OIDC SSO.
  • sources/2025-10-08-flyio-kurt-got-got — Fly.io's security postmortem names Google Workspace as the single IdP for all internal infrastructure, explicitly articulating the "everything behind an IdP that requires phishing-proof MFA" discipline as the reason a successful phish of the CEO did not compromise any infra. Canonical wiki instance of the phishing- resistant-MFA-behind-IdP pattern — internal logs portal, Stripe admin, and infra metrics are all downstream federated apps; "you're unlikely to phish your way to viewing logs here, or to refunding a customer bill at Stripe, or to viewing infra metrics, because all these things require an SSO login through Google." The account that was lost (Twitter/X) was precisely the one legacy shared account outside the IdP regime — the pattern's named coverage gap.
Last updated · 542 distilled / 1,571 read