¿Puede un proveedor de identidad hacerse pasar por mí? (¿Puede Facebook publicar preguntas de desbordamiento de pila bajo mi nombre?)

Sí, pueden.

Respuesta simple: usted se autentica de alguna manera con su proveedor de identidad, generalmente a través de un nombre de usuario y contraseña. El administrador incorrecto puede almacenar las credenciales transmitidas y simplemente reutilizarlas. Este ataque no depende de cómo se implementa el backend.

En general, su contraseña para el proveedor de identidad no se usa en absoluto para la autenticación a servicios de terceros, lo que significa que su proveedor de identidad realmente tiene sus claves de inicio de sesión (y no las tiene).

Podría pensar en esquemas que incorporen su contraseña en el proceso de autenticación sin almacenarla después sin cifrar, pero en la práctica no conozco ningún esquema de este tipo.

TL; DR : Un administrador malo de Facebook que puede falsificar su inicio de sesión en Facebook puede publicar cosas malas bajo su nombre en Facebook, y eso generalmente se considera peor que publicar una pregunta en Stack Exchange.

Mi respuesta más detallada se centra en OAuth 2.0 , que es el estándar de la industria para este caso de uso y está detrás del boceto de autorización de Google en el OP ¹ .

El marco de trabajo de OAuth 2.0 no fue originalmente diseñado solo para la autenticación, sino para el caso de uso más general de la autorización: el Servicio A desea acceder a algún recurso que es propiedad del Usuario del Servicio B.

Por ejemplo, el usuario tiene una cuenta tanto en el Servicio A (una aplicación de edición de fotos) como en el Servicio B (Google Drive). Con OAuth 2.0, el usuario otorga a la aplicación la autorización para acceder a sus fotos en Goole Drive. Algunos puntos de atención:

• El Servicio A debe ser una aplicación registrada en el Servicio B: en el ejemplo, el desarrollador tuvo que registrar su aplicación de edición de fotos en Google Developer . Al iniciar el flujo de autorización, el servicio A se identifica con el servicio B a través de la identificación del cliente y el secreto del cliente (si es el flujo del lado del servidor) o la identificación del cliente y el nombre del host (si es el flujo del lado del cliente).
• El Servicio A redirige al Usuario al punto final de autorización del Servicio B, y el Usuario debe ingresar la credencial de su Servicio B solo en el Servicio B. El Servicio A no puede falsificar el inicio de sesión del Servicio B, porque no controla El punto final de la autorización. El Servicio B no puede falsificar el inicio de sesión del Servicio A, ya que no lo proporciona el Usuario.
• La Respuesta de token final, que el Servicio A puede usar para acceder al recurso del Usuario en el Servicio B, viene con un alcance. El Servicio B permitirá que el Servicio A solo acceda a los recursos que están dentro del alcance autorizado. El alcance se explica al Usuario en la ventana de autorización a la que se redirige. En el ejemplo, la ventana de autorización de Google Drive explicará algo como "Esta aplicación de edición de fotos puede ver y modificar sus fotos en Drive" . Luego, Google permitirá que la aplicación acceda a las fotos, pero no publique algo en Google Plus, ya que no está dentro del alcance autorizado.

El inicio de sesión de terceros es un caso especial muy común, donde el recurso que posee el Usuario es la información básica de su cuenta en el Servicio B. En lugar de requerir que el Usuario se registre en su servicio, el desarrollador eligió pedir a Google que verifique la identidad del Usuario.

El sistema solo funciona si

1. El servicio A confía en el servicio B
2. El usuario confía en el Servicio B

Lo bueno es que el Usuario no tiene que confiar en el Servicio A.

Si el Usuario, sin embargo, confía en el Servicio A más que en el Servicio B, no debe usar el inicio de sesión de terceros y registrarse en el Servicio A (cuando la opción está disponible).

^{1 Publicación original}

Si pueden. Mario ha explicado cómo funciona técnicamente. Me centraré aquí en la parte trust .

Cualquier acción que hagas en una computadora implica confianza. Confías en el editor de sistema operativo de tu sistema y de tu teléfono. Confías en todos los editores de cualquier programa que hayas instalado en ellos. Confías en cualquier servicio en línea que uses. Y confías en que tu banco no haga nada en tu cuenta (esta va más allá de la informática ...).

Pero hay algunos grados en el nivel de confianza. Confío lo suficiente en el sistema de reserva de vuelos para comprarles algo, pero no confío en ellos hasta el punto de dar mis credenciales bancarias. De todos modos, confío en mi programa de almacenamiento de contraseñas lo suficiente para ello.

Entonces, en una cadena de confianza, lo que importa es: ¿alguno de los actores de la cadena solo merece un nivel de confianza más bajo que la acción general? Probablemente esté bien usar una cuenta de Facebook para SO, el riesgo de ataque y las posibles consecuencias son IMHO compatibles con la confianza que tengo en Facebook. Pero nunca usaría una cuenta de Facebook para mi banco (no lo ofrecen de todos modos). Y, por supuesto, confiar en un sistema implica confianza para cualquiera de sus administradores.

Sí. Es por eso que hay tecnología disponible que hace esto imposible (como las credenciales basadas en atributos de preservación de la privacidad) pero se considera demasiado impráctico para los usuarios promedio a partir de ahora (y no estoy al tanto de ningún software con usabilidad razonable y no hay nada) soporte del navegador para ello). Esta tecnología no les permite hacerse pasar por usted y aún más, por lo que los inicios de sesión pueden realizarse sin conexión a un proveedor central. (El problema con los enfoques actuales es que filtra los sitios que está utilizando al proveedor de identidad).