La especificación OpenID Connect se publica como estándar ISO

• Nueve especificaciones de OpenID Connect se publicaron como estándares ISO/IEC, con lo que Core 1.0, Discovery, Dynamic Client Registration, especificaciones de cierre de sesión y modos de respuesta de OAuth 2.0 pasan a formar parte del marco de estándares internacionales
• OpenID Foundation las presentó ante ISO en diciembre de 2023 mediante el mecanismo PAS (Publicly Available Specifications) y, tras una votación de aprobación de ISO, se completó su publicación
• La estandarización ISO podría facilitar el despliegue de OpenID Connect también en jurisdicciones que exigen especificaciones de organismos de estandarización reconocidos por tratados internacionales
• Antes de la presentación, el OpenID Connect working group llevó a cabo el proceso de aplicar errata corrections para que las correcciones conocidas quedaran incluidas en la versión ISO
• Con base en la experiencia de este proceso PAS, OpenID Foundation planea presentar FAPI 1.0 y, después de su finalización, los conjuntos de especificaciones eKYC-IDA y FAPI 2.0 para su publicación por ISO

---

Especificaciones publicadas como estándares ISO/IEC

• Las especificaciones relacionadas con OpenID Connect publicadas esta vez como estándares ISO/IEC son nueve
  • ISO/IEC 26131:2024 — Information technology — OpenID connect — OpenID connect core 1.0 incorporating errata set 2
  • ISO/IEC 26132:2024 — Information technology — OpenID connect — OpenID connect discovery 1.0 incorporating errata set 2
  • ISO/IEC 26133:2024 — Information technology — OpenID connect — OpenID connect dynamic client registration 1.0 incorporating errata set 2
  • ISO/IEC 26134:2024 — Information technology — OpenID connect — OpenID connect RP-initiated logout 1.0
  • ISO/IEC 26135:2024 — Information technology — OpenID connect — OpenID connect session management 1.0
  • ISO/IEC 26136:2024 — Information technology — OpenID connect — OpenID connect front-channel logout 1.0
  • ISO/IEC 26137:2024 — Information technology — OpenID connect — OpenID connect back-channel logout 1.0 incorporating errata set 1
  • ISO/IEC 26138:2024 — Information technology — OpenID connect — OAuth 2.0 multiple response type encoding practices
  • ISO/IEC 26139:2024 — Information technology — OpenID connect — OAuth 2.0 form post response mode

Presentación PAS y aprobación de ISO

• La presentación de las especificaciones OpenID Connect por parte de OpenID Foundation se realizó en diciembre de 2023 en formato PAS (Publicly Available Specifications)
• Tras la votación de aprobación de ISO, esas especificaciones fueron publicadas como estándares ISO/IEC
• Como ISO es uno de los organismos de estandarización reconocidos por tratados internacionales, puede ampliarse el margen para adoptar OpenID Connect en jurisdicciones que exigen legalmente el uso de estándares de este tipo de organismos

Correcciones incluidas en la versión ISO

• Antes de la presentación, el OpenID Connect working group llevó a cabo el proceso de aplicar errata corrections a las especificaciones
• Como resultado, la versión ISO refleja las correcciones conocidas

Próximos planes de presentación ante ISO

• Tras completar una vez el proceso de presentación ISO PAS, OpenID Foundation planea presentar otros conjuntos de especificaciones finales para su publicación por ISO
• Entre los próximos objetivos se incluye la especificación FAPI 1.0
• Las especificaciones eKYC-IDA y FAPI 2.0 están previstas como candidatas a presentación después de su finalización

[GN⁺]

Opiniones de Hacker News

• Aunque estuve bastante metido en OpenID hace unos 17 años (https://simonwillison.net/search/?tag=openid&year=2007), me tomó una cantidad vergonzosa de tiempo entender que OpenID Connect tiene muy poco que ver con la idea original de OpenID de que “el identificador es una URL y se demuestra la propiedad de esa URL”
  OpenID Connect en realidad se parece más a una evolución de OAuth

  • Como nota para mi yo del futuro: OpenID Connect (OIDC) trata principalmente de autenticación, mientras que OAuth, o más precisamente OAuth v2.0, trata de autorización
    Yo diría que OpenID Connect no es tanto una evolución de OAuth, sino más bien una evolución de OpenID en visión y espíritu. OIDC se enfoca en la identificación y autenticación de usuarios, como OpenID, pero a diferencia de OpenID no volvió a crear un flujo de autenticación completamente nuevo; logró su objetivo principal montando un flujo de autenticación sobre la especificación OAuth, que ya se estaba usando indebidamente para autenticación
  • OAuth2 es demasiado flexible en cuanto a cómo se pueden combinar sus piezas, y OIDC aporta muchas buenas prácticas sobre “cómo combinarlas”
    Por eso, incluso sistemas cuyo objetivo no es cumplir con OIDC suelen seguirlo parcialmente. Si una parte del estándar OIDC ya ofrece lo que necesitas, no hay razón para reinventar la rueda
  • La nomenclatura es una pesadilla total
    OpenID Connect es una extensión que agrega una capa de autenticación a OAuth2 (RFC 6749), y OAuth2 es un framework de autorización para conceder permisos
    En cambio, OAuth 1.0/1.0a y OpenID 1/2 son protocolos que solo tienen nombres parecidos, pero no están relacionados ni son compatibles entre sí, así que en 2024 en su mayoría son irrelevantes. Hay que tener cuidado al buscar
  • Entiendo OpenID Connect más bien como una especialización construida sobre OAuth2
  • Me interesé por primera vez en OpenID gracias a una presentación en Webstock en 2008

• Esto no es bueno en ningún sentido. Para empezar, los estándares de pago que hay que pagar para leer son realmente malos
  En segundo lugar, ojalá se dedicara más esfuerzo a diseñar estándares e implementaciones que, cuando uno los necesita, no se conviertan en un sumidero interminable de tiempo

  • Estoy de acuerdo respecto de ISO, pero en este caso no parece que haya una barrera de peaje significativa. El estándar en sí ya está publicado gratis, y esto parece más bien asignarle un identificador dentro del espacio de nombres de estandarización de ISO
    Dicho eso, no tengo claro qué ventaja tiene obtener un número de estándar ISO frente a publicar un documento HTML en Internet
  • En el mundo de Internet, me pregunto por qué no convierten esto en un RFC. El correo electrónico y TCP también son RFC, otros componentes centrales también lo son, y las empresas globales los usan todo el tiempo

• Los estándares son buenos, pero molesta que grandes organizaciones de estandarización como ISO cobren por verlos
  Supongo que es porque algunas empresas o industrias exigen estándares “reales” de ese tipo de organizaciones, en lugar de algo creado por la IETF o por sucios hippies del open source

  • Según ellos, es para ofrecer accesibilidad y financiamiento a regiones menos desarrolladas
  • “Estándar” y “cuesta dinero” se sienten como conceptos en conflicto. Si quieres que una forma sea estándar, es decir, la más común, debería ser lo suficientemente accesible como para que se implemente ampliamente
  • La mayoría de los estándares tienen precios bajos, hasta el punto de venderse con pérdida. En cambio, si quieres donar a ISO o IEEE, eso ayudaría a reducir el costo de redactar estándares
  • Entiendo que, en contextos gubernamentales o nacionales, como ISO está reconocida en varios tratados internacionales, muchas veces es más fácil obtener aprobación para usar un estándar ISO que un estándar de OpenID Foundation
    Por eso, si OpenID Connect se publica con un número ISO, en algunos proyectos será más fácil adoptarlo. Por supuesto, OpenID Connect en sí seguirá pudiéndose leer y usar gratis, pero para quienes están en situaciones como la anterior aparece una opción más fácil

• ISO es basura no libre y no ayuda al ecosistema de software
  Si miras ISO 8601, es excesivamente compleja, muchas veces no se implementa correctamente porque los mantenedores usan borradores gratuitos, y en la práctica tampoco resuelve nada bien. Por ejemplo, no puede expresar la hora de reloj de pared, lo que genera problemas con fechas futuras en las que la zona horaria podría cambiar
  Hace tiempo también trabajé con mp4, y descubrí que había cambios en el stack de Apple, así que ISO por sí sola no era suficiente

  • Entiendo la queja concreta, pero diría que no expresar la hora de reloj de pared es más bien una característica
    La crítica suele derivar en supuestos como cambios de horario de verano. Es común decir algo como: “Quiero especificar las 14:00 hora local de Absurdistán dentro de 4 años, sea cual sea su relación con UTC, pero no puedo”. Pero si llevas el supuesto un poco más allá, Absurdistán podría añadir un territorio de ultramar, unirse a una alianza, o cambiar su zona horaria y su horario de verano
    Si piensas el problema, la propia definición de hora local puede cambiar, así que es imposible especificar una hora local futura sin definir exhaustivamente todos los cambios posibles. Al final, tienes que fijar una cantidad futura de ticks de reloj atómico (TAI) e interpretarla como hora local en el momento de uso, o fijar una hora determinada e interpretarla como hora local en el momento de uso
  • Me pregunto si existe una alternativa a ISO 8601. Mi única queja era que parece haber más de una forma de expresar algunas cosas, y no conocía el problema de la hora de reloj de pared
    También me pregunto si la nueva API Temporal de JS maneja esto. Parece que se metieron bastante a fondo

• Los estándares de pago por lectura como los de ISO obstaculizan activamente el progreso de la humanidad. Ojalá no se fomentara este comportamiento

  • En el caso de C++, los borradores más recientes del estándar se publican gratis https://en.cppreference.com/w/cpp/links#C.2B.2B_standard_doc...
    Entiendo que el borrador final y el estándar oficial son casi iguales en contenido práctico. Supongo que el borrador del estándar OIDC también debe estar publicado en algún lado
  • No todo tiene que ser blanco o negro. Se puede reconocer que hay zonas grises
    Es raro decir que esos ingenieros están creando progreso para la humanidad y al mismo tiempo perjudicando activamente el progreso de la humanidad

• El aprovisionamiento de identidad es un monstruo que nunca debería haberse inventado.
  A mediados de los 2000 era tan fan que hasta operaba mi propio servidor OpenID, pero no me daba cuenta de lo fundamentalmente defectuoso que era todo este concepto.
  La identidad es un atributo intransferible inherente a una persona; no es algo que otra persona, una empresa/sitio web, un gobierno, etc. pueda “proveer”. Solo pueden proporcionar credenciales para demostrarla, como cuando emiten un pasaporte.
  Al menos WebAuthn entendió bien esta parte.

  • ¿No se parte de la suposición de que la identidad provista eres exactamente tú y solo tú? Yo siempre he visto y usado estas identidades como seudónimos encima de algún proveedor de identidad.
    Algunas identidades las uso en suficientes lugares como para que a ciertas partes les resulte difícil negar que son mías, pero aun en ese caso, solo un pequeño subconjunto de quienes han visto esa identidad puede probar que soy yo.
  • Me pregunto si la distinción entre prueba y aprovisionamiento tiene consecuencias prácticas, o si es una distinción puramente filosófica.

• ¿Todavía quedan emisores OIDC independientes donde se pueda crear una cuenta fuera de Google, MS y Apple?
  Hace poco quería crear una cuenta de Tailscale sin usar una cuenta de GitHub, y no pude.
  Me parece que antes openid.net y Ubuntu One ofrecían este tipo de servicio, pero tengo entendido que lo discontinuaron.

  • Todavía quedan algunos, y https://gitlab.com es uno que uso con frecuencia.
    Dicho eso, la seguridad y el costo de soporte necesarios para este tipo de servicio son altos, y ofrecerlo gratis en particular no es realista para organizaciones pequeñas. Las economías de escala que lo hacen posible son grandes, y funciona especialmente bien cuando las empresas grandes pagan por productos empresariales.

• OpenID Connect es un protocolo bastante simple. Leí la especificación (https://openid.net/specs/openid-connect-core-1_0.html) y pude entender la mayor parte en más o menos un día.
  Para quienes no quieran leer la especificación, también escribí un tutorial completo para implementar un cliente OpenID con solicitudes HTTP simples (https://spapas.github.io/2023/11/29/openid-connect-tutorial/).
  Los ejemplos usan Python, pero no debería ser difícil implementarlo en el lenguaje que prefieras. La mayor parte de la complejidad está en decodificar y verificar tokens JWT.
  He usado este cliente escrito a mano en un proyecto real de producción durante alrededor de un año para autenticación con Keycloak, y todo funciona perfectamente.
  P. D.: Sé que mi sitio tiene demasiados anuncios. Lamentablemente no tuve tiempo de configurar bien Google Ads ni encontré una alternativa mejor. Puedes usar un bloqueador de anuncios al leerlo.

  • El artículo es muy interesante y está bien escrito.
    Pero conviene tener cuidado con expresiones subjetivas como simple. Si el lector lo siente difícil y el autor dice que es simple, puede resultar bastante intimidante.
  • Es un tutorial excelente.
    Aun así, todavía no estoy convencido de que OIDC sea fácil. Keycloak oculta una complejidad enorme, y los desarrolladores no lo hicieron así por aburrimiento. Por ejemplo, hay muchísimas configuraciones de timeout: timeout de SSO, timeout de cliente, timeouts de varios tokens, etc.

• La monetización y la operación organizativa alrededor de los estándares ISO en general se sienten muy sospechosas.
  Un truco menos conocido: en el amable sitio estonio https://evs.ee puedes buscar versiones más baratas de los estándares. A menudo crean sus propias versiones con contenido casi idéntico al original. Lamentablemente, en este caso parece que solo ofrecen el estándar real a un precio similar https://www.evs.ee/en/search?OnlySuggestedProducts=false&que...
  Vale la pena vigilar el sitio para ver si más adelante aparece una versión propia con mejor precio. Por lo general cuesta alrededor del 10% del original. Otro dato más de que Estonia hace cosas geniales.
  Al trabajar en cumplimiento normativo para dispositivos médicos, trato con bastante frecuencia con organizaciones de estandarización bastante sospechosas https://openregulatory.com/accessing-standards/
  Ya escuché todos los argumentos habituales como “la estandarización cuesta dinero” y “estas organizaciones hacen un buen trabajo”, pero no estoy de acuerdo en absoluto. Si algo es un estándar, creo que se vuelve parecido a una ley. La gente debe poder cumplirlo y, para eso, debe poder acceder a él libremente. Parece que el abogado general de la UE también está de acuerdo https://openregulatory.com/maybe-eu-standards-are-becoming-f...
  Hay muchos procesos de estandarización que no necesitan vender PDFs de forma sospechosa. Se me ocurren ECMAScript y ANSI C, y la lista sigue.

• Convertirlo en una publicación ISO lo vuelve, para los departamentos de compras, un escudo para eludir responsabilidades.
  Al fin y al cabo, a nadie lo despidieron por exigir cumplir con un paquete de estándares ISO.