Principio: las medidas de seguridad "excesivas" hacen que los usuarios busquen formas de eludir la seguridad, lo que anula el propósito.
Desde mi experiencia en la implementación de sistemas similares, y la lógica que usamos para diseñarlos:
- La idea de la autenticación federada es "depender" del proveedor de identidades para hacer el trabajo de base para ciertas propiedades de la identidad, para que no tenga que hacerlo. Si está utilizando los inicios de sesión de Google / FB / LinkedIn o redes sociales similares, esta es una premisa básica.
La clave aquí es asegurarse de que los procesos del proveedor de identidad estén verificando la propiedad (atributo) que están afirmando.
Entonces, en general (es decir, a menos que su modelo de amenaza indique una excepción), no necesita verificar más una dirección de correo electrónico (que se encuentra entre los atributos de identidad más básicos).
** Usted mencionó "asumiendo que la cuenta social no era suya": para la mayoría de las aplicaciones, diría que este no es un escenario de amenaza que el diseñador de la aplicación deba cubrir.
En definitiva, pedir que el correo electrónico sea verificado nuevamente después de que una autenticación federada parezca ser un poco excesivo de precaución, lo que perjudica la causa de seguridad más que a la ayuda.
- Hay varios flujos de restablecimiento de contraseña recomendados
- uno notable que recuerdo es por Troy Hunt - aquí: enlace
- mi favorito es de Jim Manico (OWASP / Manicode.net); El último bit de este documento (flujo de trabajo de contraseña olvidada) debería ayudar: enlace
Aunque no se indica explícitamente en ninguno de los anteriores, la necesidad de restablecer la contraseña a través de un correo electrónico registrado no aumenta la necesidad de verificación adicional en el paso 1.
Resumen: a menos que su aplicación tenga una amenaza específica, el correo electrónico de un flujo de autenticación de un proveedor de identidad reputado debería ser suficiente sin más verificación.