Saltar al contenido principal
El campo email_verified de un perfil de usuario indica si el usuario ha verificado su dirección de correo electrónico. La verificación del correo electrónico es opcional, pero se requieren direcciones de correo electrónico válidas para determinadas acciones, como enviar comunicaciones por correo electrónico, enlaces de restablecimiento o recuperación de contraseña y enlaces mágicos de a los usuarios. Por lo general, un correo electrónico se verifica inmediatamente después de crear la cuenta de usuario o cuando el usuario inicia sesión en la aplicación por primera vez. Es una buena manera de saber que la persona que se registra realmente es propietaria de ese correo electrónico en ese momento. Como la verificación del correo electrónico ocurre una sola vez en ese momento específico, no podemos garantizar que la persona que inicia sesión con la cuenta de usuario más adelante siga siendo propietaria de la dirección de correo electrónico verificada. En el caso de los federados, a veces informan si el usuario tiene un correo electrónico verificado y, en función de ello, Auth0 establece el campo email_verified en el perfil del usuario. Sin embargo, esto transfiere al proveedor de identidad la responsabilidad de hacerlo correctamente, algo que no podemos garantizar. Tampoco sabemos si el usuario sigue siendo propietario del correo electrónico verificado por ese proveedor. Por todas estas razones, debemos ser cautelosos con lo que asumimos a partir de un correo electrónico verificado.

¿Cuándo marca Auth0 los correos electrónicos como verificados?

Cuando los usuarios se registran con correo electrónico y contraseña, reciben un correo de verificación con un enlace. Cuando hacen clic en el enlace, Auth0 verifica su correo electrónico. Para obtener más información, consulta Customize Email Templates. Cuando los usuarios se autentican con un Proveedor de identidad federado (por ejemplo, una conexión social o empresarial), el valor del campo email_verified coincidirá con el que devuelva el Proveedor de identidad en el perfil del usuario. Si el Proveedor de identidad no devuelve ningún valor, se establecerá en false.

Correos electrónicos verificados y vinculación de cuentas

Cuando quiera vincular dos cuentas de usuario, debe asegurarse de que el usuario siga teniendo acceso a ambas cuentas. La única forma de lograrlo es hacer que los usuarios se autentiquen en ambas cuentas antes de vincularlas. No debe vincular cuentas automáticamente basándose en los correos electrónicos del usuario. Siempre pida a los usuarios que se autentiquen de nuevo antes de hacerlo. Esto evitará situaciones como las siguientes:
  • John Doe, un empleado de Travel0, se registra en un sitio con su correo electrónico corporativo john.doe@travel0.com y una contraseña. Meses después, John Doe deja Travel0 y contratan a un nuevo John Doe con la misma cuenta de correo electrónico. Esa persona va al mismo sitio web, se autentica con su Proveedor de identidad corporativo (como Google Workspace) y la cuenta se vincula automáticamente con la del otro usuario.
  • Los Proveedores de identidad federados pueden cometer errores en la forma en que gestionan la verificación del correo electrónico y pueden indicar que los usuarios son propietarios de un correo electrónico que no les pertenece.
Por otro lado, le recomendamos que siga comprobando el campo email_verified antes de realizar la vinculación de cuentas, para mitigar situaciones como las siguientes:
  • Un atacante crea una cuenta de Google attacker@gmail.com.
  • El atacante crea un nuevo usuario de base de datos con el correo electrónico de la víctima (por ejemplo, victim@hotmail.com).
  • El atacante vincula ambas cuentas.
  • El atacante envía un ataque de phishing a la víctima.
  • La víctima intenta registrarse, se le informa de que el usuario ya existe y se le ofrece restablecer la contraseña.
  • El usuario introduce su contraseña e inicia sesión en la cuenta del atacante, que ahora tiene acceso a cualquier dato que la víctima introduzca en la aplicación.

Correos electrónicos verificados y decisiones de autorización

Del mismo modo que no puedes confiar plenamente en el correo electrónico, tampoco puedes confiar plenamente en el dominio del correo electrónico. Si tu aplicación necesita restringir el acceso en función del empleador del usuario, el hecho de que un usuario haya iniciado sesión con un correo electrónico de un dominio corporativo específico no garantiza que se le deba conceder acceso. Por ejemplo:
  • Si tu aplicación permite que los clientes se registren para crear cuentas, y empleados de distintas empresas se autentican con sus credenciales corporativas, a un usuario que se registra con una cuenta user@acme.com no se le debería conceder acceso al mismo conjunto de funcionalidades que a un usuario que se autentica con el directorio corporativo de acme.com.
  • Si tu aplicación admite la autenticación con Azure AD y el directorio admite usuarios invitados, es posible que recibas usuarios de cualquier dominio que inicien sesión desde ese inquilino de Azure AD. No deberías dar a los usuarios invitados el mismo nivel de acceso que al resto de los usuarios que se autentican con ese inquilino.
Como recomendación general, no deberías usar el dominio del correo electrónico para tomar decisiones de autorización. Si necesitas comprobar si el usuario pertenece a una organización específica, es mejor basarte en la conexión que usó para autenticarse o en atributos específicos de la conexión, como el id del inquilino de Azure AD.

Más información