Inicio de sesión social y vinculación de cuentas

Cuando una persona entra con un proveedor social, la tienda recibe del proveedor un identificador de esa persona y, normalmente, un correo. El identificador, junto con el nombre del proveedor, sirve para reconocer a la misma persona en el siguiente ingreso: el estándar de OpenID Connect lo define como un valor que identifica a la persona en ese emisor y que no debe reasignarse a otra.

El correo es otra cosa: la persona puede cambiarlo, el proveedor puede no haberlo verificado y un correo escrito a mano en un perfil no prueba nada. Por eso la regla V2 de Almendro usa el par proveedor más identificador como clave y trata el correo como dato de contacto.

El escenario de riesgo es conocido: alguien crea una cuenta en un proveedor con un correo que no controla (por ejemplo, el de otra persona) y, si la tienda vincula por correo coincidente sin más, se queda con la cuenta existente de esa persona. Para cerrar esa puerta, Almendro exige dos condiciones juntas para unir un ingreso social a una cuenta existente: que el proveedor afirme que verificó el correo (V1) y que la persona haya iniciado sesión en la cuenta en el mismo trámite (V3).

En ingresos-sociales.csv busca un evento de acción «vinculada» sobre una cuenta que ya existía, donde falten ambas condiciones.

Una cosa es el evento más grave y otra es el tamaño del problema. La sesión previa (V3) protege aunque el proveedor sí verifique el correo, porque una cuenta de proveedor puede tomarse y entonces el correo verificado sería el de un ladrón de esa cuenta. Cuenta todas las vinculaciones del archivo en las que la persona no había iniciado sesión en la cuenta existente. Un ingreso rechazado no es una vinculación.

Cada permiso que la tienda pide a un proveedor es un dato más que el cliente cede y una puerta más si el proveedor o la tienda sufren un incidente. La regla V4 pide limitarse a lo necesario. Un permiso que la tienda recibe y no usa es un hallazgo fácil, que suele nacer de copiar una configuración de ejemplo.

En permisos-pedidos.csv hay la lista de lo que se pide a cada proveedor y si la tienda lo usa.

Ante una vinculación que no cumplió las reglas, la respuesta defensiva no es borrar la cuenta del cliente. Es deshacer la unión o suspenderla, avisar a la dirección de contacto que ya estaba en la cuenta y pedir a su dueño que la confirme desde una sesión suya. Si el dueño no responde, el ingreso social queda desvinculado y la cuenta original sigue intacta. Así se corrige el error sin castigar a quien no tiene culpa.