Es una cuestión arquitectónica más que técnica. Nuestra aplicación web y móvil dependen totalmente de la autenticación social y estamos utilizando proveedores de autenticación social como Google , Facebook y muchos otros.
Cuando el usuario inicia sesión con éxito, proveedores como Google y Facebook devuelven los datos del usuario con un correo electrónico y una identificación única. Estamos almacenando esos datos en la base de datos algo como esto.
+----+--------------------------------------------------------------+---------------+----------+ | id | socialId | email | provider | +----+--------------------------------------------------------------+---------------+----------+ | 1 | $2a$12$Qx.FVkgYkXqJGF4PyJ1kb.JlSDe9bV6TJFodpTx2eBsYxvqn6Gywa | a@example.com | Facebook | +----+--------------------------------------------------------------+---------------+----------+ | 2 | $2a$12$N2fCTRxymPlcaID5oP617OJTXkrvKAHZ/taFJ.lePZddfW3E6U.Fe | b@example.com | Google | +----+--------------------------------------------------------------+---------------+----------+Todos los campos de la base de datos son obligatorios y no anulables.
Nota: También almacenamos socialIds en un formato hash por razones de seguridad y el almacenamiento de correo electrónico nos ayuda a saber si el usuario es un usuario nuevo o antiguo y ayuda a evitar registros duplicados.
Pero hay un problema, hay algunos proveedores que no devuelven los correos electrónicos de los usuarios.
Por lo que se ha convertido en un problema identificar si el usuario es nuevo o antiguo, también crea el riesgo de filas duplicadas.
¿Cuál es la mejor manera de resolver este problema? ¿Es bueno almacenar identificaciones en forma cruda en la base de datos?
Buena pregunta, así que aquí hay algunos puntos arquitectónicos:
VINCULACIÓN DE CUENTAS A NIVEL DE APLICACIÓN
Parece que es posible que deba avisar al usuario al regresar del inicio de sesión cuando no esté seguro de su identidad. Una opción podría ser una pantalla Complete Your Profile que capture información que le permita vincular cuentas cuando sea necesario.
Por supuesto, si solicita el correo electrónico, el teléfono, etc., debe verificar que el usuario sea el propietario, por ejemplo, mediante verificación por correo electrónico o SMS, por lo que debe agregar esa plomería a su aplicación.
También tenga en cuenta que el proveedor social puede haber pedido al usuario que dé su consentimiento para usar su nombre de usuario pero no su correo electrónico, por lo que debe explicarle al usuario por qué su aplicación necesita información adicional.
ENLACE DE CUENTA DE SERVIDOR DE AUTORIZACIÓN
Curiosamente, como una solución a más largo plazo, el uso de un servidor de autorización (AS) puede externalizar toda esta plomería de su aplicación y mejorar la arquitectura.
El AS puede administrar las diferencias de proveedores sociales para que sus aplicaciones y usuarios obtengan las mismas cualidades, independientemente del método de inicio de sesión:
Sus propios datos de usuario podrían tener este aspecto, o podría agregar su propia ID de usuario a los tokens emitidos para que no necesite ningún tipo de almacenamiento.
| ID de usuario específico del dominio | PPID |
|---|---|
| 1 | IDUUID 1 |
| 2 | IDUUID 2 |
El servidor de autorización también puede desempeñar un papel importante en la externalización de la gestión de la información de identificación personal (PII) de sus aplicaciones, como se explica en este artículo .
La lógica de vinculación aún debe implementarse, ya que OAuth es un marco en lugar de una solución lista para usar. Pero un buen AS (gratis/pago) le brindaría elementos básicos más grandes para este tipo de solución, por ejemplo, acciones que pueden incluir preguntar al usuario.
Lo más importante que debe verificar antes de comprometerse con un AS es que satisfaga sus casos de uso y que no haya problemas de bloqueo para sus aplicaciones.
No sé por qué necesita hash el socialId, el socialId (o más generalmente hablando, es un identificador de usuario relativo a su aplicación de registro en el proveedor de autenticación social), por lo que es el identificador más general sobre su usuario mientras usa la autenticación social
lo mejor es dividir dos mesas. uno para la información de usuario de su sistema (ID de usuario, correo electrónico de usuario, dirección, etc.) , y el segundo es para mantener (ID social, ID de usuario, etc.) . Si se requiere el correo electrónico del usuario para su sistema, en el flujo de autenticación, puede llevar al usuario a completar el proceso de inicio de sesión mientras que el proveedor de autenticación no admite el correo electrónico de devolución.