OpenID Connect specifications published as ISO standards

Original Article ↗ Hacker News Discussion ↗

OpenID Connect, the identity layer built on OAuth 2.0 and widely used for single sign-on, has been published as an ISO standard, prompting debate over both its technical merits and the role of paywalled standards. Commenters weigh OIDC’s advantages over older protocols like OpenID 2.0 and SAML, its real-world complexity (especially around implementations such as Keycloak), and how ISO branding can ease adoption in regulated or government contexts even as many criticize ISO’s closed-access model.

OIDC servers and real‑world implementations

  • Several implementations are discussed: Keycloak, Apereo CAS, ORY Hydra, Zitadel, Authentik, Gluu, Dex; commercial/self-hosted options like FusionAuth, ADFS; hosted providers such as Okta/Auth0, Google, Microsoft, GitHub, Amazon.
  • Keycloak is widely used but described as a “mixed bag”: powerful and extensible, good for complex policy/certification-heavy environments, but with rough edges.
    • Pain points: inconsistent REST API, weak docs, tricky multi-tenancy, complicated flow customization UI, fragile email templates, non‑trivial branding, storage model making zero‑downtime upgrades hard.
    • Some see it as risky for very small teams without in‑house expertise; others say smaller teams can operate it fine if use cases are simple and someone understands OAuth/OIDC reasonably well.
  • CAS is used as an OIDC provider but supports only a single issuer per deployment; defaults to a rarely supported “nested” claims format.

OAuth, OpenID, and OpenID Connect

  • Multiple comments clarify: OAuth 2.0 is a framework for delegated access; OIDC is a profile on top of it that adds identity and authentication; older OpenID 1/2 (URL-based identity) are largely unrelated and mostly obsolete.
  • Debate over the common slogan “OAuth = authorization, OIDC = authentication”:
    • Some argue it’s useful shorthand.
    • Others say it’s misleading: OAuth 2.0 doesn’t standardize actual authorization models; OIDC is more like a standardized way to attach identity to OAuth flows.

Security, complexity, and evolving standards

  • OAuth 2.0 is criticized as too flexible and historically under-secure (implicit flow, password grant).
  • Newer guidance: OAuth 2.1 drafts, security best current practices, and FAPI 2.0 aim to narrow options and encode safer profiles (authorization code + PKCE, sender‑constrained tokens, PAR, etc.).
  • GNAP (now an RFC) is presented as a modernized successor for certain use cases, but adoption is unclear.

ISO standardization and paywall worries

  • Many object to ISO’s paywalled model, calling it harmful to progress and “law-like” documents that should be free.
  • Others note: in this case OIDC specs remain freely available; the ISO stamp mainly helps in jurisdictions or procurement processes that require ISO-recognized standards.
  • Some fear a PDF‑like scenario where a free vendor spec later becomes paywalled as an ISO-only version.

Identity philosophy and usability

  • Discussion contrasts original OpenID’s decentralized URL identity with OIDC’s more provider-centric model.
  • Some argue “identity provisioning” by large providers is conceptually flawed and fragile (account bans, domain lapses); prefer models closer to attestations or WebAuthn.
  • Others value having a widely adopted, interoperable standard even if it trades off some decentralization.