¿Cómo funciona la delegación de OpenID en la fiesta de confianza? ¿Han cambiado las especificaciones recientemente?

Question

Considere este escenario. Tengo mi propio sitio web, que utilizo como mi identificador, pero utilizo un proveedor de OpenID de terceros (en mi caso, yahoo), como se describe aquí , para iniciar sesión en sitios web de Relying Party (RP) como stackoverflow y sourceforge.

Parecía ser un movimiento inteligente:

• No estoy bloqueado con un proveedor de OpenID, ya que si / cuando yahoo ya no ofrezca el servicio, o comience a cobrar por él, o no confíe más en ellos, puedo cambiar de proveedor sin problemas.
• No tengo la carga económica, administrativa y de seguridad de instalar y mantener un proveedor OpenID en mi servidor

Preguntas

¿Cómo se supone que funciona el RP? Según tengo entendido, debe usar el identificador I y usar el proveedor (yahoo) solo para la autenticación (y no para la identificación). ¿Es eso correcto? ¿Cambió algo recientemente? Solo para ser claros, quiero decir que mi identificación debería ser

http://www.mysite.com/myPreferredUrl

y no

https://me.yahoo.com/myYahooId (que es donde está mi sitio web " redirigir " la autenticación como se describe en el sitio web anterior)

Nota al margen

También estoy haciendo esta pregunta porque las cosas parecen estar mal ahora (estuvieron bien hace unos meses). Si intento iniciar sesión en stackoverflow, escribo la URL de mysite.com, estoy correctamente " redirigido " al sitio web de yahoo, en el que inicio sesión, me pregunta si me gustaría "continuar en stackoverflow", le digo que sí, que "redirige" y en el sitio stackoverflow veo '' Este es un OpenID que no hemos visto antes '', ¡muestra mi ID de yahoo y en realidad estoy bloqueado!

¿Es un error o me falta algo?

PD: si se pregunta cómo estoy escribiendo esta pregunta, esto se debe a que en una de las muchas máquinas que uso, un navegador todavía tiene una cookie válida ...

EDITAR: la respuesta de Andrew Arnott a continuación sugirió una forma de solucionar mi problema (es decir, cambiar a un proveedor diferente). Pero todavía me interesan algunos detalles: ¿qué ha cambiado de OpenID 1.1 a 2.0 sobre la delegación? Por qué en las especificaciones se ha elegido permitir que el proveedor " rompa " ¿la delegación? Cuanto más expliques, mejores serán las posibilidades de que tu respuesta sea aceptada.

Answer 1

Creo que la respuesta de Andrew es bastante precisa. Lo único que puedo agregar es un poco sobre cómo la especificación v2.0 terminó como lo hizo, lo que permite al proveedor elegir no trabajar con la delegación. Creo que uno de los motivadores fue la selección de identidad dirigida por el servidor, en la que el usuario simplemente suministra " yahoo.com " (o haga clic en el botón de Yahoo), y luego la ID elegida regresará del servidor en la respuesta id_res. Esto también permite que el servidor haga cosas como ofrecer una elección de qué ID enviar (como lo hace Yahoo) o enviar un identificador único a cada RP (como lo hace Google).

También significa que toda la información necesaria se encuentra en una respuesta id_res , lo que significa que el RP no necesita almacenar el estado de su solicitud checkid para procesar la respuesta. De hecho, un proveedor podría enviar una respuesta de id_res directamente al RP sin que el RP la inicie con una solicitud de checkid en absoluto.

Un proveedor v1.x desconocía por completo cuándo se realizaba la delegación por la noche. Este diseño evitó que un proveedor incluso decidiera no admitir la delegación, pero también solucionó algunos problemas de IU; le preguntaría si desea proporcionar el " joe.coolprovider.com " ID cuando realmente estaba usando su delegado " joesmith.org " ID.

Por lo tanto, está la compensación. La delegación aún es posible, por lo que la esperanza era que los usuarios que realmente quieren la delegación (que, seamos sinceros, se verán enajenados por la cantidad de usuarios de estos grandes sitios) puedan elegir proveedores que ofrezcan las funciones que necesitan. (En otras palabras, deje que el mercado se pelee).

Answer 2

No creo que Yahoo sea compatible con la delegación de OpenID. Es decir, StackOverflow y otros RP pueden realizar un descubrimiento en su propio identificador y configurar la solicitud de autenticación de la delegación correctamente, pero Yahoo podría estar eligiendo (posiblemente en contra de la especificación) para enviar una aserción de identidad para su propio identificador en lugar de la dada por el RP.

Las especificaciones no han cambiado de OpenID 1.1 a 2.0. Las especificaciones no sugieren ni respaldan el comportamiento de Yahoo! y solo Yahoo puede comentar con autoridad sobre su razonamiento.

La delegación de StackOverflow todavía funciona. Yahoo te rompió, al parecer. Le sugiero que aproveche lo que la delegación le compró cambiando a quién delegó la autenticación. www.myopenid.com por ejemplo apoya la delegación. Si cambia su propio identificador para señalarlo, debería poder volver a StackOverflow como su antiguo yo nuevamente. :)