php - Integración de openID y oauth como sistema de inicio de sesión, inicio de sesión y autenticación del sitio web.
openid connect (3)
En primer lugar, permítanme comenzar diciendo que esta pregunta no tiene que ver con las diferentes implementaciones de openID y oAuth. Hay muchas clases sobre estos.
Mi pregunta es qué hacer después de autenticar a un usuario:
- ¿Cómo agregar este usuario a la tabla de usuarios en la base de datos?
- ¿Cómo manejar diferentes inicios de sesión para el mismo usuario? (El example Remy Sharp sugiere algo para openID)
- ¿Cómo combinar oAuth y openID en la base de datos?
¿Algunas ideas?
Implementé el inicio de sesión a través de OpenID de google y encontré problemas similares. Utilicé la library openid de janrain.
No he creado una tabla separada para openid. En su lugar, utilicé correos electrónicos secundarios (los correos electrónicos secundarios se almacenan en la tabla de usuarios).
Al iniciar sesión a través de Google, es posible exigir correos electrónicos de usuarios (creo que existe la misma oportunidad en cualquier otro proveedor de OpenID). Después de que recibo una respuesta de google, el usuario ha iniciado sesión, busco en la tabla de usuarios. Si el correo electrónico proporcionado se encontró en la tabla (no importa si es primario o secundario), inicio la sesión del usuario. Si no se encuentra el correo electrónico, le pregunto al usuario si tiene una cuenta. En caso afirmativo, se le propone iniciar sesión con el nombre de usuario / contraseña existente, después de eso agrego un correo electrónico secundario al usuario. Si el usuario no tiene una cuenta, se crea una nueva cuenta.
Así que no necesitas nuevas tablas especiales para estos trucos.
La forma más simple me parecería, tener una tabla de usuario básica, donde agrega el usuario al registro y tiene una tabla 1: n adicional donde guarda las autenticaciones posibles. Quizás necesite más de una tabla, si hay métodos, que necesitan muchas más columnas que otros.
Tu pregunta tiene que ser parte principal:
- Autenticación
- Autorización
Por lo general, los dos no se tratan de manera diferente si el proveedor de identidad (IP) es el suyo, que ha sido la configuración más común en las aplicaciones web hasta ahora.
Cuando se utiliza un proveedor de OpenId como Google, la parte de autenticación se separa de su control. Recibirá un token que le informará si el usuario está autenticado o no. El token normalmente contendrá los siguientes reclamos: Nombre, correo electrónico e identidad con nombre, donde el último es el ID único de la identidad en el IP.
Hasta ahora tan bueno.
El truco es ahora como preguntas, ¿cómo autorizo a este usuario ?
Bueno, hay un par de enfoques para esto.
En primer lugar, cuando cree un usuario local en su sistema, puede rellenar previamente los valores de Nombre y Correo electrónico en función de las reclamaciones que reciba de la IP. En este proceso, puede comenzar y decir que todos los usuarios que tienen un perfil almacenado en su sistema están autorizados, o puede desarrollar procesos adicionales que agregarán los detalles que necesite saber sobre el usuario.
Entonces, ¿cómo evitar que el usuario no se vuelva a registrar si cambia de google a facebook como IP?
Aquí es donde las cosas se ponen complicadas. La reclamación más común que Google, Yahoo, Facebook le proporcionará es la dirección de correo electrónico y el Nombre. Entonces, lo que puede hacer es tratar de hacer coincidir la reclamación con los clientes existentes en su aplicación. Sin embargo, esto no es seguro, ya que las personas pueden tener diferentes correos electrónicos en diferentes sistemas.
El valor del nombre tampoco es seguro.
En nuestra configuración, comenzamos por hacer coincidir los correos electrónicos, ya que sabemos que la mayoría de las direcciones IP validan las direcciones de correo electrónico. Esto reducirá mucho los duplicados. Después de esa verificación, comenzamos nuestro propio proceso de validación donde el objetivo es ver si la persona ya está registrada. Este proceso busca el número de teléfono móvil de los clientes en nuestra base de datos y, si se encuentra una coincidencia, enviamos una contraseña de un solo uso al cliente para verificar la propiedad correcta del número de teléfono.
Dado que el inicio de sesión es una configuración sensible al tiempo, se crea una tabla SQL simple que asigna identidades externas a nuestros números de clientes. Esto nos permite implementar este tipo de lógica de validación fuera de todas nuestras aplicaciones web (y por lo tanto reducir la redundancia de código)