¿Cómo puede un usuario final verificar la autenticidad del formulario de inicio de sesión de un proveedor de autenticación externo?

  

¿cómo pueden los usuarios finales verificar la autenticidad de los formularios de inicio de sesión que recopilan sus credenciales?

Los protocolos de autenticación de terceros en la web suelen depender de redireccionar al proveedor de autenticación en lugar de permitir que los sitios (potencialmente no confiables) incorporen sus controles de autenticación.

Cuando un usuario es redirigido a un dominio que es propiedad del proveedor de autenticación, puede verificar la autenticidad del proveedor al verificar los indicadores de seguridad de su navegador (la URL completa, el ícono de bloqueo de SSL verde, etc.) antes de ingresar sus credenciales. Por lo general, también se les informa sobre el alcance de los datos compartidos y los permisos otorgados a la aplicación.

Por ejemplo, si se está autenticando con Google, espere ser redirigido a una pantalla de consentimiento como esta:

(Fuente de imagen)

  

¿Qué es lo que impide que un sitio web malicioso muestre un formulario de inicio de sesión de Google o Facebook fraudulento, con el fin de recopilar las credenciales de los usuarios?

Si se le solicita que ingrese sus credenciales integradas en un sitio que no sea de confianza o dentro de una aplicación que no sea de confianza, no tiene medios confiables para verificar que su información es segura (a menos que esté dispuesto a inspeccionar cuidadosamente la fuente de la aplicación, que no es realista para el usuario promedio).

RFC 6749 (The OAuth 2.0 Authorization Framework) comenta sobre el problema de la autenticación integrada en algunos lugares. Se trata de aplicaciones nativas en particular, pero ilustra el problema general con la incrustación:

9.  Native Applications

   (...)

   When choosing between an external or embedded user-agent, developers
   should consider the following:

   (...)

   o  An embedded user-agent poses a security challenge because resource
      owners are authenticating in an unidentified window without access
      to the visual protections found in most external user-agents.  An
      embedded user-agent educates end-users to trust unidentified
      requests for authentication (making phishing attacks easier to
      execute).

(Propietario del recurso = el usuario)

Y de la sección sobre consideraciones de seguridad:

10.11.  Phishing Attacks

   Wide deployment of this and similar protocols may cause end-users to
   become inured to the practice of being redirected to websites where
   they are asked to enter their passwords.  If end-users are not
   careful to verify the authenticity of these websites before entering
   their credentials, it will be possible for attackers to exploit this
   practice to steal resource owners' passwords.

   Service providers should attempt to educate end-users about the risks
   phishing attacks pose and should provide mechanisms that make it easy
   for end-users to confirm the authenticity of their sites.  Client
   developers should consider the security implications of how they
   interact with the user-agent (e.g., external, embedded), and the
   ability of the end-user to verify the authenticity of the
   authorization server.

(Enfatiza lo mío)

El comentario de Arminius responde a tu pregunta para todas las implementaciones reales de esto.

Sin embargo, si el formulario está incrustado en la página principal, puede abrir las herramientas del desarrollador y verificar el dominio desde el que se cargó el iframe. También puede ingresar credenciales falsas y ver dónde se envió la solicitud.

Todas las versiones recientes de los principales navegadores de escritorio (chrome, Firefox, es decir, opera, Edge, etc.) tienen los conjuntos de herramientas necesarios para realizar los dos anteriores.