¿Por qué un operador de sitio web necesita confiar en un proveedor de openid?

Question

¿Por qué un operador de sitio web necesita confiar en un proveedor de openid?

#1 de Gilles (6 votos)

8

Estoy trabajando en un sitio web y estoy considerando usar OpenID para la autenticación. El sitio tendrá algunos servicios premium de bajo costo ($ 3 a $ 5), pero no protegerá datos del usuario particularmente confidenciales, solo se guardó el estado del juego. Desde mi punto de vista, mi principal preocupación con respecto a la autenticación es que la persona que pagó por esos servicios es la misma persona que usa esos servicios. No me importa verificar que el usuario pertenezca a una dirección de correo electrónico particular u otra identidad pública.

¿A qué riesgos me abro si permito usar johndoeblog.com/openid en comparación con un proveedor conocido como Google? ¿Quizás el propio usuario confía más en su propio servidor privado que en Google? ¿Por qué debería obligarlo a confiar en los mismos proveedores de autenticación en los que confío?

El único factor que puedo ver es que el usuario comparte voluntariamente sus credenciales o está comprometido, lo que permite que varias personas accedan a los servicios premium, pero ese es un problema que tengo que mitigar independientemente del proveedor de autenticación que use. ¿Qué me estoy perdiendo aquí?

trust openid

pregunta Karl Bielefeldt 15.04.2014 - 20:15

fuente

1 respuesta

Lea otras preguntas en las etiquetas trust openid

Construir un canal seguro sin SSL / TLS Riesgos de ejecutar Honeypot [configuración específica]

score 6 · Accepted Answer

Básicamente, no es necesario confiar en un proveedor de OpenID: el usuario lo hace.

Comparemos, desde la perspectiva estricta de la autenticación, las contraseñas con OpenID.

Contraseña: Usuario: "hey, servidor, soy yo! Sabes que soy yo porque nadie más conoce la palabra mágica correcthorsebatterystaple , que te dije cuando creé la cuenta ".
OpenID: Usuario: "hey, servidor, soy yo! Sabes que soy yo porque johndoeblog.com/openid dice que soy yo, y te dije que confiaras en johndoeblog.com/openid cuando dice que soy yo cuando creé la cuenta ".

En ambos casos, como servidor, usted confía en la disposición y la capacidad del usuario para elegir un método de autenticación confiable. Con las contraseñas, el usuario debe elegir una contraseña que nadie más sepa. Con OpenID, el usuario debe elegir un punto final de OpenID que nadie más pueda usar.

Para fines de autenticación, no hay ninguna razón, como operador de servidor, para preferir un proveedor de OpenID a otro. Puede (o no) preferir recomendar proveedores de OpenID que sepa que son confiables, pero no necesita confiar en el proveedor de OpenID de ninguna manera para autenticar al usuario.

Ambos casos dependen igualmente de la cooperación del usuario para garantizar que el usuario que pagó sea el que usa el servicio. Un usuario autenticado por contraseña puede compartir su contraseña; un usuario autenticado con OpenID puede permitir el uso de su punto final de OpenID.

Todo esto se debe a que solo te importa la identidad del usuario como cuenta # 1234 en tu servidor. Por supuesto, sería completamente diferente si quisiera saber que el propietario de la cuenta # 1234 se conoce como Joe Bloggs por el gobierno de Syldavia: entonces deberá confiar en el proveedor de OpenID para que le brinde el nombre real de Joe Bloggs.

Una razón menor para confiar en un proveedor de OpenID es descargar el trabajo de limitar las tasas de creación de cuentas: si sabe que Myriad tiene medidas para restringir la tasa de creación de cuentas y solo acepta las cuentas de Myriad OpenID, entonces esto se restringe automáticamente La tasa de creación de cuenta para su servicio. Esto no se aplica a usted: dado que está ejecutando un servicio de pago, la restricción de la tasa de creación de cuentas está integrada.