OpenID Connect specifications published as ISO standards

Original Article ↗ Hacker News Discussion ↗

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.