Su pregunta tiene que partes principales a ella:
- autenticación
- Autorización
Por lo general, los dos no son tratados de manera diferente si el proveedor de identidad (IP) corre a su propia, que tiene sido la configuración más común en aplicaciones web hasta ahora.
Al utilizar un proveedor de OpenId como Google, la parte de autenticación está separada de su control. Obtendrá un token que le indicará si el usuario está autenticado o no. El token normalmente contendrá las siguientes afirmaciones: nombre, correo electrónico e identidad con nombre, donde el último es el ID único de la identidad en el IP.
Hasta ahora todo bien.
El truco es ahora como usted pregunta, ¿cómo puedo autorizar a este usuario?
Bueno, hay un par de enfoques para esto.
En primer lugar, cuando crea un usuario local en su sistema, puede rellenar previamente los valores de Nombre y Correo electrónico basados en los reclamos que obtiene 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 necesita saber sobre el usuario.
Entonces, ¿cómo evitar que el usuario no se vuelva a registrar si cambian de google a facebook como IP?
Aquí es donde las cosas se ponen difíciles. El reclamo 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 intentar hacer coincidir la reclamación entrante con los clientes existentes en su aplicación. Sin embargo, esto no es a prueba de fallas, 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 coincidir con los correos electrónicos, ya que sabemos que la mayoría de los IP validan las direcciones de correo electrónico. Esto reducirá mucho los duplicados. Después de ese control, comenzamos nuestro propio proceso de validación donde el objetivo es ver si la persona ya está registrada. Este proceso busca el número móvil de los clientes en nuestra base de datos, y si se encuentra una coincidencia, le enviamos una contraseña de un solo uso al cliente para verificar la correcta propiedad 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 cliente. 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)
Tendrás que decidir de alguna manera para reconciliar las credenciales de inicio de sesión dispares-- esto generalmente se hace usando el correo electrónico del usuario como una clave serogate única entre oAuth y usuarios de openID. – colinross