Identificación abierta

OpenID es un protocolo de autenticación descentralizado y de estándar abierto promovido por la fundación sin fines de lucro OpenID Foundation. Permite que los usuarios sean autenticados por sitios cooperadores (conocidos como partes confiables o RP) utilizando un servicio de proveedor de identidad (IDP) de terceros, eliminando la necesidad de que los webmasters proporcionen sus propios sistemas de inicio de sesión ad hoc y permitiendo a los usuarios iniciar sesión en múltiples sitios web no relacionados sin tener que tener una identidad y contraseña separadas para cada uno. ^[1] Los usuarios crean cuentas seleccionando un proveedor de identidad OpenID , ^[1] y luego usan esas cuentas para iniciar sesión en cualquier sitio web que acepte la autenticación OpenID. Varias organizaciones grandes emiten o aceptan OpenID en sus sitios web. ^[2]

El estándar OpenID proporciona un marco para la comunicación que debe tener lugar entre el proveedor de identidad y el aceptante de OpenID (la " parte confiante "). ^[3] Una extensión del estándar (el Intercambio de atributos OpenID) facilita la transferencia de atributos de usuario, como el nombre y el género, del proveedor de identidad OpenID a la parte confiante (cada parte confiante puede solicitar un conjunto diferente de atributos, según sus requisitos). ^[4] El protocolo OpenID no depende de una autoridad central para autenticar la identidad de un usuario. Además, ni los servicios ni el estándar OpenID pueden exigir un medio específico para autenticar a los usuarios, lo que permite enfoques que van desde los comunes (como las contraseñas) hasta los novedosos (como las tarjetas inteligentes o la biometría).

La versión final de OpenID es OpenID 2.0, finalizada y publicada en diciembre de 2007. ^[5] El término OpenID también puede referirse a un identificador como se especifica en el estándar OpenID; estos identificadores toman la forma de un Identificador Uniforme de Recurso (URI) único, y son administrados por algún "proveedor de OpenID" que maneja la autenticación. ^[1]

En marzo de 2016 ^[actualizar], hay más de mil millones de cuentas habilitadas para OpenID en Internet (ver a continuación) y aproximadamente 1.100.934 sitios han integrado el soporte para consumidores de OpenID: ^[6] AOL , Flickr , Google , Amazon.com , Canonical (nombre del proveedor Ubuntu One ), LiveJournal , Microsoft (nombre del proveedor cuenta Microsoft ), Mixi , Myspace , Novell , OpenStreetMap , Orange , Sears , Sun , Telecom Italia , Universal Music Group , VeriSign , WordPress , Yahoo!, la BBC , ^[7] IBM , ^[8] PayPal , ^[9] y Steam , ^[10] aunque algunas de esas organizaciones también tienen su propia gestión de autenticación.

Muchas de las organizaciones más grandes, si no todas, exigen que los usuarios proporcionen una autenticación en forma de una cuenta de correo electrónico existente o un número de teléfono móvil para poder registrarse en una cuenta (que luego se puede utilizar como identidad OpenID). Hay varias entidades más pequeñas que aceptan registros sin necesidad de proporcionar detalles de identidad adicionales.

Facebook utilizó OpenID en el pasado, pero lo trasladó a Facebook Connect . ^[11] Blogger también utilizó OpenID, pero desde mayo de 2018 ya no lo admite. ^[12]

OpenID es un protocolo de autenticación descentralizado que permite a los usuarios autenticarse en varios sitios web utilizando un único conjunto de credenciales, lo que elimina la necesidad de nombres de usuario y contraseñas independientes para cada sitio web. OpenID autentica al usuario con un proveedor de identidad (IDP), que luego le proporciona al usuario un identificador único (llamado OpenID). Este identificador se puede utilizar para autenticar al usuario en cualquier sitio web que admita OpenID.

Cuando un usuario visita un sitio web que admite la autenticación OpenID, el sitio web redirigirá al usuario al proveedor de identidades elegido. El proveedor de identidades solicitará al usuario que se autentique (por ejemplo, ingresando un nombre de usuario y una contraseña). Una vez que el usuario se autentique, el proveedor de identidades generará un OpenID y lo enviará al sitio web. El sitio web puede usar este OpenID para autenticar al usuario sin necesidad de conocer sus credenciales reales.

OpenID se basa en varios estándares existentes, entre ellos HTTP, HTML y XML. OpenID se basa en una serie de tecnologías, entre ellas un mecanismo de descubrimiento que permite a los sitios web encontrar el IDP asociado a un OpenID en particular, así como mecanismos de seguridad para protegerse contra el phishing y otros ataques. ^[13]

Una de las principales ventajas de OpenID es que permite a los usuarios controlar su propia información de identidad, en lugar de depender de sitios web individuales para almacenar y administrar sus credenciales de inicio de sesión. Esto puede ser especialmente importante en los casos en que los sitios web son vulnerables a violaciones de seguridad o en los que los usuarios están preocupados por la privacidad de su información personal.

OpenID ha sido ampliamente adoptado por varios sitios web y proveedores de servicios importantes, entre ellos Google, Yahoo! y PayPal. El protocolo también lo utilizan varios proyectos y marcos de código abierto, entre ellos Ruby on Rails y Django.

El usuario final interactúa con una parte confiable (como un sitio web) que ofrece una opción para especificar un OpenID con fines de autenticación; un usuario final normalmente ha registrado previamente un OpenID (por ejemplo, alice.openid.example.org) con un proveedor de OpenID (por ejemplo, openid.example.org). ^[1]

La parte confiada normalmente transforma el OpenID en un formato de URL canónico (por ejemplo, http://alice.openid.example.org/).

• Con OpenID 1.0, la parte que confía solicita el recurso HTML identificado por la URL y lee una etiqueta de enlace HTML para descubrir la URL del proveedor de OpenID (por ejemplo, http://openid.example.org/openid-auth.php). La parte que confía también descubre si debe utilizar una identidad delegada (consulte a continuación).
• Con OpenID 2.0, la parte confiada descubre la URL del proveedor de OpenID solicitando el documento XRDS (también llamado documento Yadis ) con el tipo de contenido application/xrds+xml; este documento puede estar disponible en la URL de destino y siempre está disponible para un XRI de destino .

Hay dos modos en los que la parte confiante puede comunicarse con el proveedor de OpenID:

• checkid_immediate, en el que la parte que confía solicita que el proveedor de OpenID no interactúe con el usuario final. Toda la comunicación se transmite a través del agente de usuario del usuario final sin notificarlo explícitamente.
• checkid_setup, en el que el usuario final se comunica con el proveedor de OpenID a través del mismo agente de usuario utilizado para acceder a la parte confiada.

El checkid_immediatemodo puede volver al checkid_setupmodo anterior si la operación no se puede automatizar.

En primer lugar, la parte que confía y el proveedor de OpenID (opcionalmente) establecen un secreto compartido , al que se hace referencia mediante un identificador asociado , que luego la parte que confía almacena. Si se utiliza este checkid_setupmodo, la parte que confía redirige el agente de usuario del usuario final al proveedor de OpenID para que el usuario final pueda autenticarse directamente con el proveedor de OpenID.

El método de autenticación puede variar, pero normalmente un proveedor de OpenID solicita al usuario final una contraseña o algún token criptográfico y luego pregunta si el usuario final confía en que la parte confiada recibirá los detalles de identidad necesarios.

Si el usuario final rechaza la solicitud del proveedor de OpenID de confiar en la parte confiada, entonces el agente de usuario es redirigido nuevamente a la parte confiada con un mensaje que indica que se rechazó la autenticación; la parte confiada, a su vez, se niega a autenticar al usuario final.

Si el usuario final acepta la solicitud del proveedor de OpenID para confiar en la parte que confía, entonces el agente de usuario es redirigido de nuevo a la parte que confía junto con las credenciales del usuario final. Esa parte que confía debe confirmar que las credenciales realmente provienen del proveedor de OpenID. Si la parte que confía y el proveedor de OpenID habían establecido previamente un secreto compartido, entonces la parte que confía puede validar la identidad del proveedor de OpenID comparando su copia del secreto compartido con la que recibió junto con las credenciales del usuario final; una parte que confía de ese tipo se llama con estado porque almacena el secreto compartido entre sesiones. Por el contrario, una parte que confía sin estado o tonta debe realizar una solicitud en segundo plano más ( check_authentication) para asegurarse de que los datos realmente provienen del proveedor de OpenID.

Una vez verificado el OpenID, la autenticación se considera exitosa y el usuario final se considera conectado a la parte que confía con la identidad especificada por el OpenID dado (por ejemplo, alice.openid.example.org). La parte que confía generalmente almacena el OpenID del usuario final junto con el resto de la información de la sesión del usuario final.

Para obtener una URL habilitada para OpenID que se pueda usar para iniciar sesión en sitios web habilitados para OpenID, un usuario registra un identificador OpenID con un proveedor de identidad. Los proveedores de identidad ofrecen la posibilidad de registrar una URL (normalmente un dominio de tercer nivel, por ejemplo, nombredeusuario.ejemplo.com) que se configurará automáticamente con el servicio de autenticación OpenID.

Una vez que un usuario ha registrado un OpenID, también puede utilizar una URL existente bajo su propio control (como un blog o una página de inicio) como un alias o una "identidad delegada". Simplemente inserta las etiquetas OpenID adecuadas en el HTML ^[14] o sirve un documento Yadis . ^[15]

A partir de OpenID Authentication 2.0 (y algunas implementaciones 1.1), hay dos tipos de identificadores que se pueden usar con OpenID: URL y XRI.

Los XRI son una nueva forma de identificador de Internet diseñado específicamente para la identidad digital entre dominios. Por ejemplo, los XRI vienen en dos formas: i-names y i-numbers , que generalmente se registran simultáneamente como sinónimos . Los i-names son reasignables (como los nombres de dominio), mientras que los i-numbers nunca se reasignan. Cuando se utiliza un i-name XRI como un identificador OpenID, se resuelve inmediatamente al i-number sinónimo (el elemento CanonicalID del documento XRDS). Este i-number es el identificador OpenID almacenado por la parte que confía. De esta manera, tanto el usuario como la parte que confía están protegidos de que la identidad OpenID del usuario final sea asumida por otra parte, como puede suceder con una URL basada en un nombre DNS reasignable.

La Fundación OpenID (OIDF) promueve y mejora la comunidad y las tecnologías de OpenID. La OIDF es una organización internacional sin fines de lucro que desarrolla estándares y está formada por desarrolladores individuales, agencias gubernamentales y empresas que desean promover y proteger OpenID. La Fundación OpenID se formó en junio de 2007 y actúa como una organización de confianza pública que representa a una comunidad abierta de desarrolladores, proveedores y usuarios. La OIDF ayuda a la comunidad proporcionando la infraestructura necesaria y ayudando a promover y respaldar la adopción de OpenID. Esto incluye la gestión de la propiedad intelectual y las marcas comerciales, así como el fomento del crecimiento viral y la participación global en OpenID.

La junta directiva de la Fundación OpenID tiene seis miembros de la junta comunitaria y ocho miembros de la junta corporativa: ^[16]

La OIDF es una organización global que promueve la identidad digital y fomenta la adopción de OpenID. La OIDF ha promovido la creación de capítulos miembros. Los capítulos miembros son oficialmente parte de la Fundación y trabajan dentro de su propio grupo para apoyar el desarrollo y la adopción de OpenID como marco para la identidad centrada en el usuario en Internet.

La OIDF garantiza que las especificaciones OpenID se puedan implementar libremente, por lo que exige que todos los colaboradores firmen un acuerdo de contribución. Este acuerdo otorga una licencia de derechos de autor a la Fundación para publicar las especificaciones colectivas e incluye un acuerdo de no aserción de patentes. El acuerdo de no aserción establece que el colaborador no demandará a nadie por implementar especificaciones OpenID.

La marca registrada OpenID en los Estados Unidos fue asignada a la OpenID Foundation en marzo de 2008. ^[17] Había sido registrada por NetMesh Inc. antes de que la OpenID Foundation estuviera operativa. ^{[18] [19]} En Europa, a partir del 31 de agosto de 2007, la marca registrada OpenID está registrada a nombre de la OpenID Europe Foundation. ^[20]

El logotipo de OpenID fue diseñado por Randy "ydnar" Reddig, quien en 2005 había expresado planes de transferir los derechos a una organización OpenID. ^[21]

Desde el anuncio original de OpenID, el sitio oficial ha declarado: ^[22]

Nadie debería ser dueño de esto. Nadie tiene intención de ganar dinero con esto. El objetivo es publicar cada parte de esto bajo las licencias más liberales posibles, de modo que no se requiera dinero, licencias ni registros para jugar. La comunidad en su conjunto se beneficia si existe algo así, y todos somos parte de la comunidad.

Sun Microsystems , VeriSign y varias empresas más pequeñas involucradas en OpenID han emitido acuerdos de no reivindicación de patentes que cubren las especificaciones de OpenID 1.1. Los acuerdos establecen que las empresas no harán valer ninguna de sus patentes contra las implementaciones de OpenID y revocarán sus promesas a cualquiera que amenace o haga valer patentes contra los implementadores de OpenID. ^{[23] [24]}

En marzo de 2012, un artículo de investigación ^[25] informó sobre dos problemas de seguridad genéricos en OpenID. Ambos problemas permiten a un atacante iniciar sesión en las cuentas de terceros de confianza de una víctima. Para el primer problema, OpenID y Google (un proveedor de identidad de OpenID) publicaron avisos de seguridad para abordarlo. ^{[26] [27]} El aviso de Google dice "Un atacante podría falsificar una solicitud OpenID que no pida la dirección de correo electrónico del usuario y luego insertar una dirección de correo electrónico no firmada en la respuesta del IDP. Si el atacante retransmite esta respuesta a un sitio web que no se da cuenta de que este atributo no está firmado, el sitio web puede ser engañado para que inicie sesión al atacante en cualquier cuenta local". El artículo de investigación afirma que se ha confirmado que muchos sitios web populares son vulnerables, incluidos Yahoo! Mail , smartsheet.com , Zoho , manymoon.com, diigo.com . Los investigadores han notificado a las partes afectadas, que luego han corregido su código vulnerable.

En el segundo problema, el artículo lo denominó "falla lógica de confusión de tipos de datos", que también permite a los atacantes iniciar sesión en las cuentas RP de las víctimas. Inicialmente se confirmó que Google y PayPal eran vulnerables. OpenID publicó un informe de vulnerabilidad ^[28] sobre la falla. El informe dice que Google y PayPal han aplicado correcciones y sugieren que otros proveedores de OpenID revisen sus implementaciones.

Algunos observadores han sugerido que OpenID tiene debilidades de seguridad y puede resultar vulnerable a ataques de phishing . ^{[29] [30] [31]} Por ejemplo, una parte de retransmisión maliciosa puede reenviar al usuario final a una página de autenticación de un proveedor de identidad falsa que le pide que ingrese sus credenciales. Una vez completado esto, la parte maliciosa (que en este caso también controla la página de autenticación falsa) podría tener acceso a la cuenta del usuario final con el proveedor de identidad y luego usar el OpenID de ese usuario final para iniciar sesión en otros servicios.

En un intento por combatir posibles ataques de phishing, algunos proveedores de OpenID exigen que el usuario final se autentique con ellos antes de intentar autenticarse con la parte que confía. ^[32] Esto depende de que el usuario final conozca la política del proveedor de identidad. En diciembre de 2008, la OpenID Foundation aprobó la versión 1.0 de la extensión de política de autenticación de proveedores (PAPE), que "permite a las partes que confían solicitar que los proveedores de OpenID empleen políticas de autenticación específicas al autenticar usuarios y que los proveedores de OpenID informen a las partes que confían qué políticas se utilizaron realmente". ^[33]

Otros problemas de seguridad identificados con OpenID involucran la falta de privacidad y la imposibilidad de abordar el problema de la confianza . ^[34] Sin embargo, este problema no es exclusivo de OpenID y es simplemente el estado de Internet tal como se usa comúnmente. ^{[ cita requerida ]}

Sin embargo, el proveedor de identidad obtiene un registro de sus inicios de sesión con OpenID; sabe cuándo inició sesión en qué sitio web, lo que facilita mucho el seguimiento entre sitios . Una cuenta OpenID comprometida también es probable que constituya una violación de la privacidad más grave que una cuenta comprometida en un solo sitio.

Otra vulnerabilidad importante está presente en el último paso del esquema de autenticación cuando no se utiliza TLS/SSL: la URL de redireccionamiento del proveedor de identidad a la parte que confía. El problema con esta redirección es el hecho de que cualquiera que pueda obtener esta URL (por ejemplo, rastreando el cable) puede reproducirla y conectarse al sitio como el usuario víctima. Algunos de los proveedores de identidad utilizan nonces (un número que se utiliza solo una vez) para permitir que un usuario inicie sesión en el sitio una vez y falle todos los intentos consecutivos. La solución nonce funciona si el usuario es el primero en usar la URL. Sin embargo, un atacante rápido que rastrea el cable puede obtener la URL y restablecer inmediatamente la conexión TCP de un usuario (ya que un atacante rastrea el cable y conoce los números de secuencia TCP necesarios) y luego ejecutar el ataque de repetición como se describió anteriormente. Por lo tanto, los nonces solo protegen contra atacantes pasivos, pero no pueden evitar que los atacantes activos ejecuten el ataque de repetición. ^[35] El uso de TLS/SSL en el proceso de autenticación puede reducir significativamente este riesgo.

Esto se puede reformular así:

 SI (Tanto RP1 como RP2 tienen a Bob como cliente) Y // un caso común (Bob usa el mismo IDP con RP1 y RP2) Y // un caso común (RP1 no usa VPN/SSL/TLS para asegurar su conexión con el cliente) // ¡prevenible! ENTONCES RP2 podría obtener credenciales suficientes para hacerse pasar por Bob con RP1 FIN-SI

El 1 de mayo de 2014, se reveló un error denominado " Redireccionamiento encubierto relacionado con OAuth 2.0 y OpenID". ^{[36] [37]} Fue descubierto por el estudiante de doctorado en matemáticas Wang Jing en la Facultad de Ciencias Físicas y Matemáticas de la Universidad Tecnológica de Nanyang , Singapur. ^{[38] [39] [40]}

El anuncio de OpenID es: "'Covert Redirect', publicado en mayo de 2014, es un ejemplo de atacantes que utilizan redirectores abiertos, una amenaza bien conocida, con medios bien conocidos de prevención. El protocolo OpenID Connect exige medidas estrictas que impiden los redirectores abiertos para prevenir esta vulnerabilidad". ^[41]

"Hasta ahora, el consenso general es que Covert Redirect no es tan malo, pero sigue siendo una amenaza. Para entender qué lo hace peligroso es necesario tener una comprensión básica de Open Redirect y cómo se puede explotar". ^[42]

No se ha puesto a disposición un parche de inmediato. Ori Eisen, fundador, presidente y director de innovación de 41st Parameter, le dijo a Sue Marquette Poremba: "En cualquier sistema distribuido, contamos con la buena voluntad de los participantes para hacer lo correcto. En casos como OAuth y OpenID, la distribución es tan amplia que no es razonable esperar que todos y cada uno de los sitios web se actualicen en un futuro próximo". ^[43]

El protocolo de autenticación OpenID original fue desarrollado en mayo de 2005 ^[44] por Brad Fitzpatrick , creador del popular sitio web comunitario LiveJournal , mientras trabajaba en Six Apart . ^[45] Inicialmente conocido como Yadis (un acrónimo de "Yet another distributed identity system"), ^[46] se denominó OpenID después de que el nombre de dominio openid.net se le diera a Six Apart para que lo usara en el proyecto. ^[47] El soporte de OpenID pronto se implementó en LiveJournal y en la comunidad de motores LiveJournal DeadJournal para comentarios de publicaciones de blog y rápidamente ganó atención en la comunidad de identidad digital. ^{[48] [49]} El desarrollador web JanRain fue uno de los primeros en apoyar OpenID, proporcionando bibliotecas de software OpenID y expandiendo su negocio en torno a servicios basados ​​en OpenID.

A finales de junio, comenzaron las discusiones entre los usuarios de OpenID y los desarrolladores de la empresa de software empresarial NetMesh, lo que condujo a una colaboración en materia de interoperabilidad entre OpenID y el protocolo similar Light-weight Identity (LID) de NetMesh. El resultado directo de la colaboración fue el protocolo de descubrimiento Yadis , que adoptó el nombre utilizado originalmente para OpenID. El nuevo Yadis se anunció el 24 de octubre de 2005. ^[50] Después de una discusión en el Taller de Identidad de Internet de 2005 unos días después, los desarrolladores de XRI / i-names se unieron al proyecto Yadis, ^[51] contribuyendo con su formato Extensible Resource Descriptor Sequence ( XRDS ) para su utilización en el protocolo. ^[52]

En diciembre, los desarrolladores de Sxip Identity comenzaron a discutir con la comunidad OpenID/Yadis ^[53] después de anunciar un cambio en el desarrollo de la versión 2.0 de su Protocolo de Identidad Extensible Simple (SXIP) hacia identidades basadas en URL como LID y OpenID. ^[54] En marzo de 2006, JanRain desarrolló una extensión de Registro Simple (SREG) para OpenID que permitía el intercambio de perfiles primitivos ^[55] y en abril presentó una propuesta para formalizar extensiones para OpenID. El mismo mes, también se había comenzado a trabajar en la incorporación de soporte completo de XRI en OpenID. ^[56] A principios de mayo, el desarrollador clave de OpenID, David Recordon , dejó Six Apart y se unió a VeriSign para centrarse más en la identidad digital y la orientación para la especificación OpenID. ^{[49] [57]} A principios de junio, las principales diferencias entre los proyectos SXIP 2.0 y OpenID se resolvieron con el acuerdo de admitir múltiples personas en OpenID mediante el envío de una URL de proveedor de identidad en lugar de una URL de identidad completa. Con esto, así como con la incorporación de extensiones y el soporte XRI, OpenID estaba evolucionando hacia un marco de identidad digital completo, y Recordon proclamó: "Vemos a OpenID como un paraguas para el marco que abarca las capas de identificadores, descubrimiento, autenticación y una capa de servicios de mensajería que se encuentra por encima y todo esto se ha denominado 'OpenID 2.0'. ^[58] " A fines de julio, Sxip comenzó a fusionar su protocolo de Intercambio de Identidad Digital (DIX) en OpenID, y presentó borradores iniciales de la extensión de Intercambio de Atributos OpenID (AX) en agosto. A fines de 2006, un artículo de opinión de ZDNet defendió OpenID ante usuarios, operadores de sitios web y empresarios. ^[59]

El 31 de enero de 2007, Symantec anunció el soporte para OpenID en sus productos y servicios Identity Initiative. ^[60] Una semana después, el 6 de febrero, Microsoft hizo un anuncio conjunto con JanRain, Sxip y VeriSign para colaborar en la interoperabilidad entre OpenID y la plataforma de identidad digital Windows CardSpace de Microsoft , con especial atención al desarrollo de una solución de autenticación resistente a la suplantación de identidad para OpenID. Como parte de la colaboración, Microsoft se comprometió a dar soporte a OpenID en sus futuros productos de servidor de identidad y JanRain, Sxip y VeriSign se comprometieron a añadir soporte para el perfil Information Card de Microsoft a sus futuras soluciones de identidad. ^[61] A mediados de febrero, AOL anunció que un servicio de proveedor OpenID experimental estaba funcionando para todas las cuentas de AOL y AOL Instant Messenger (AIM). ^[62]

En mayo, Sun Microsystems comenzó a trabajar con la comunidad OpenID, anunciando un programa OpenID, ^[63] así como entrando en un pacto de no aserción con la comunidad OpenID, comprometiéndose a no hacer valer ninguna de sus patentes contra las implementaciones de OpenID. ^{[23] En junio, la dirección de OpenID formó la OpenID Foundation, una} corporación de beneficio público con sede en Oregón para gestionar la marca y la propiedad de OpenID. ^[64] El mismo mes, Snorri Giorgetti formó una OpenID Europe Foundation independiente en Bélgica ^[65] . A principios de diciembre, los principales contribuyentes al protocolo habían recogido acuerdos de no aserción y las especificaciones finales de OpenID Authentication 2.0 y OpenID Attribute Exchange 1.0 se ratificaron el 5 de diciembre. ^[66]

A mediados de enero de 2008, Yahoo! anunció el soporte inicial de OpenID 2.0, tanto como proveedor como parte confiante, lanzando el servicio de proveedor a finales de mes. ^[67] A principios de febrero, Google, IBM, Microsoft, VeriSign y Yahoo! se unieron a la OpenID Foundation como miembros de la junta corporativa. ^[68] A principios de mayo, SourceForge, Inc. presentó el soporte de proveedor y parte confiante de OpenID al sitio web líder de desarrollo de software de código abierto SourceForge.net . ^[69] A finales de julio, el popular servicio de red social MySpace anunció el soporte para OpenID como proveedor. ^[70] A finales de octubre, Google lanzó el soporte como proveedor de OpenID y Microsoft anunció que Windows Live ID soportaría OpenID. ^[71] En noviembre, JanRain anunció un servicio alojado gratuito, RPX Basic, que permite a los sitios web comenzar a aceptar OpenID para registro e inicio de sesión sin tener que instalar, integrar y configurar las bibliotecas de código abierto OpenID. ^[72]

En enero de 2009, PayPal se unió a la OpenID Foundation como miembro corporativo, seguida poco después por Facebook en febrero. La OpenID Foundation formó un comité ejecutivo y nombró a Don Thibeau como director ejecutivo. En marzo, MySpace lanzó su servicio de proveedor OpenID previamente anunciado, que permite a todos los usuarios de MySpace utilizar su URL de MySpace como un OpenID. En mayo, Facebook lanzó su funcionalidad de usuario de confianza, ^{[73] [74]} que permite a los usuarios utilizar una cuenta OpenID habilitada para inicio de sesión automático (por ejemplo, Google) para iniciar sesión en Facebook. ^[75]

En septiembre de 2013, Janrain anunció que MyOpenID.com se cerraría el 1 de febrero de 2014; un gráfico circular mostró que Facebook y Google dominaban el espacio de inicio de sesión social a partir del segundo trimestre de 2013. ^[76] Desde entonces, Facebook ha abandonado OpenID; ya no es patrocinador, no está representado en la junta ni permite inicios de sesión con OpenID. ^{[16] [77]}

En mayo de 2016, Symantec anunció que discontinuaría su servicio de portal de identidad personal OpenID pip.verisignlabs.com. ^{[78] [79]}

En marzo de 2018, Stack Overflow anunció el fin del soporte de OpenID, alegando que el uso era insuficiente para justificar el costo. En el anuncio, se afirmó que, en función de la actividad, los usuarios preferían la autenticación de cuentas basada en Facebook, Google y correo electrónico/contraseña. ^[80]

OpenID es una forma de utilizar un único conjunto de credenciales de usuario para acceder a varios sitios, mientras que OAuth facilita la autorización de un sitio para acceder y utilizar información relacionada con la cuenta del usuario en otro sitio. Aunque OAuth no es un protocolo de autenticación , se puede utilizar como parte de uno.

La autenticación en el contexto del acceso de un usuario a una aplicación le dice a la aplicación quién es el usuario actual y si está presente o no. [...] La autenticación tiene que ver con el usuario y su presencia en la aplicación, y un protocolo de autenticación a escala de Internet debe poder hacer esto a través de los límites de red y seguridad.

Sin embargo, OAuth no le dice nada a la aplicación. OAuth no dice absolutamente nada sobre el usuario, ni tampoco dice cómo el usuario demostró su presencia o incluso si todavía está allí. En lo que respecta a un cliente OAuth, pidió un token, lo obtuvo y finalmente utilizó ese token para acceder a alguna API. No sabe nada sobre quién autorizó la aplicación o si había un usuario allí. De hecho, gran parte del objetivo de OAuth es dar este acceso delegado para su uso en situaciones en las que el usuario no está presente en la conexión entre el cliente y el recurso al que se accede. Esto es excelente para la autorización del cliente, pero es realmente malo para la autenticación, donde el objetivo es averiguar si el usuario está allí o no (y quién es). ^[81]

El siguiente dibujo destaca las diferencias entre el uso de OpenID y OAuth para la autenticación. Tenga en cuenta que con OpenID, el proceso comienza cuando la aplicación solicita al usuario su identidad (normalmente, una URI de OpenID), mientras que en el caso de OAuth, la aplicación solicita directamente un token OAuth de acceso limitado (clave de valet) para acceder a las API (entrar en la casa) en nombre del usuario. Si el usuario puede conceder ese acceso, la aplicación puede recuperar el identificador único para establecer el perfil (identidad) mediante las API.

OpenID proporciona un mecanismo de verificación criptográfica que evita los ataques a continuación contra usuarios que hacen un mal uso de OAuth para la autenticación.

Tenga en cuenta que la clave de valet no describe al usuario de ninguna manera, solo proporciona derechos de acceso limitados a una casa (que ni siquiera es necesariamente la del usuario, solo tenía una llave). Por lo tanto, si la clave se ve comprometida (el usuario es malicioso y logró robar la llave de la casa de otra persona), entonces el usuario puede hacerse pasar por el dueño de la casa ante la aplicación que solicitó su autenticidad. Si la clave se ve comprometida en cualquier punto de la cadena de confianza, un usuario malicioso puede interceptarla y usarla para hacerse pasar por el usuario X para cualquier aplicación que dependa de OAuth2 para la pseudoautenticación contra el mismo servidor de autorización OAuth. Por el contrario, la carta notariada contiene la firma del usuario, que puede ser verificada por la aplicación solicitante contra el usuario, por lo que este ataque no es viable. ^[82]

La carta puede utilizar criptografía de clave pública para ser autenticada.

• La aplicación solicitante proporciona su clave pública de cifrado al usuario, que la proporciona al servidor de autenticación.
• El servidor de autenticación cifra un documento que contiene una clave de cifrado que corresponde a un hash unidireccional de un secreto que el usuario conoce (por ejemplo, una frase de contraseña) para el desafío-respuesta utilizando la clave pública de la aplicación.
• El usuario devuelve el documento cifrado a la aplicación, que lo descifra.
• La aplicación cifra una frase aleatoria utilizando la clave de cifrado recibida y pide al usuario que haga lo mismo, luego compara los resultados; si coinciden, el usuario es auténtico.

Publicado en febrero de 2014 ^[83] por la OpenID Foundation, OpenID Connect es la tercera generación de la tecnología OpenID. Es una capa de autenticación sobre el marco de autorización OAuth 2.0 . ^[84] Permite a los clientes informáticos verificar la identidad de un usuario final basándose en la autenticación realizada por un servidor de autorización, así como obtener la información básica del perfil sobre el usuario final de una manera interoperable y similar a REST. En términos técnicos, OpenID Connect especifica una API HTTP RESTful, utilizando JSON como formato de datos.

OpenID Connect permite que una variedad de partes, incluidos clientes web, móviles y JavaScript, soliciten y reciban información sobre sesiones autenticadas y usuarios finales. La especificación OpenID Connect es extensible y admite funciones opcionales como el cifrado de datos de identidad, el descubrimiento de proveedores de OpenID y la gestión de sesiones.

• Sitio web oficial
• OpenID en Curlie