OpenID, un sistema de identificación descentralizado en internet

Cuando la web empezó a madurar, y pasamos de tener un lugar donde consultar información a una red de servicios conectados, cada uno de estos sitios empezó a requerir un usuario (y contraseña) con el que identificarnos. Sin embargo, para el usuario medio tener un usuario en cada sistema y cada uno con una contraseña es un engorro.

Autenticación e identificación descentralizada

La solución es sencilla: en lugar de almacenar contraseñas en cada sitio, el usuario se autentica en su proveedor de identidad (IdP), y luego accede al servicio que confía en esa autenticación. Para que esta autenticación sea realmetne descentralizada, el servicio debe confiar sin configurar nada previamente ni realizar ningún desarrollo, todo debe realizarse por estar usando un protocolo común. Por ejemplo, en la frontera presento mi pasaporte. Cualquier frontera reconoce mi pasaporte, tiene un formato común y mi país está reconocido.

OpenID nació a mediados de la década de 2000 como una iniciativa de código abierto para descentralizar la autenticación en línea. Sin embargo, la implementación práctica presentó desafíos significativos.

Los principales obstáculos de OpenID que dificultaron su adopción masiva:

• Complejidad en la implementación: La integración en sitios web y aplicaciones no era sencilla, lo que desalentaba a muchos desarrolladores. Había que implementar firma digital en XML, lo que rea complejo y sobre lo que había poco desarrollo de librerías. Además, no se estandarizaron los endpoints de los proveedores.
• Experiencia de usuario: Acostumbrados a identificarnos con un nombre de usuario o un email en un simple formulario, OpenID requería un exceso de conocimiento tecnológico, haciendo que el registro/login fuese poco intuitivo. Por ejemplo, el identificador era una URL (que es más dificil de recordar y escribir), el usuario no se le guiaba por el proceso, había que realizar redirecciones manuales en entorno web (no servía para aplicaciones móviles o APIs) y los mensajes eran demasiado técnicos.
• Falta de penetración: Aunque algunas empresas grandes adoptaron OpenID: Yahoo!, AOL, Google (aunque luego salió con su solución) y la operadora móvil japonesa NTT DoComo.

Además de estos probleams, otras empresas optaron por soluciones propietarias que ofrecían una integración más sencilla y una mejor experiencia de usuario. Principalmente servicios consolidados que tenían una gran base de usuarios:

• Facebook Connect: Permitía a los usuarios iniciar sesión en sitios de terceros utilizando sus credenciales de Facebook. Aunque no era un estándar abierto, su adopción fue masiva debido a la popularidad de la red social en aquel momento.
• Twitter Login: Permitía a los usuarios iniciar sesión en aplicaciones de terceros utilizando su cuenta de Twitter, facilitando la integración de funcionalidades sociales.
• Google Friend Connect: Ofrecía funcionalidades similares, permitiendo la integración de herramientas sociales de Google en sitios web externos. Sin embargo, Google abandonó esta iniciativa en 2011 debido a la falta de adopción y a la competencia de otras plataformas sociales (Technologizer by Harry McCracken), para pasarse a OAuth.

Estas soluciones, aunque populares, no seguían un estándar abierto y estaban vinculadas a plataformas específicas, lo que limitaba su interoperabilidad.

[Más info: Error500 «OpenID, ¿es el momento de aceptar el fracaso?» (2011]

La Evolución hacia OpenID Connect

Reconociendo las limitaciones de OpenID, la comunidad de estándares desarrolló OpenID Connect como una evolución natural. Se aprendió de los errores, se buscó estándares robustos y bien definidos, implementaciones sobre tecnologías con amplio apoyo y sistemas que facilitasen la implementación tanto para los desarrolladores como para tener una experiencia de usuario sencilla.

Se construye sobre el protocolo OAuth 2.0, un estándar bien definido que añade una capa de autenticación permitiendo a las aplicaciones verificar la identidad de los usuarios de manera segura y estandarizada.

A diferencia de OpenID, OpenID Connect utiliza JSON Web Tokens (JWT) para transmitir información de identidad con ID Tokens firmados, lo que facilita su integración en aplicaciones modernas basadas en APIs. Además, es compatible con aplicaciones móviles y de una sola página (SPA), lo que lo hace más adecuado para las necesidades actuales de desarrollo web y móvil.

[Más info: openid.net]

Este nuevo enfoque ha generado la vuelta de las alianzas. Hoy en día, OpenID Connect es ampliamente utilizado y respaldado por grandes proveedores de identidad como Google, Microsoft (Azure, Office 365), Facebook (que aunque tiene su propio login, soporta OpenID Connect), Amazon Web Services…

Sustitutos y alternativas actuales

Sin embargo, existen otras soluciones que también ofrecen autenticación y autorización:

• OAuth 2.0: Aunque no es un protocolo de autenticación per se, hay otras tecnologías que, al igual que OpenID Connect, también se apoyan en OAuth 2.0 para la
• SAML (Security Assertion Markup Language): Utilizado principalmente en entornos empresariales para la federación de identidades y el inicio de sesión único (SSO).
• FIDO2/WebAuthn: Protocólos emergentes que permiten la autenticación sin contraseñas, utilizando métodos como huellas dactilares o autenticación biométrica (Stack Overflow).

Una cuestión de sencillez y aliados

OpenID, en su forma original, no logró alcanzar una adopción masiva debido a sus limitaciones técnicas y a la competencia de soluciones más centradas en el usuario. Sin embargo, su evolución hacia OpenID Connect ha permitido superar muchos de estos desafíos, ofreciendo una solución moderna y segura para la autenticación en línea. Sin duda un ejemplo de como no solo hay que tener una buena idea, hay que saber implementarla, tener compañeros de viaje y tener una experiencia de usuario brillante.