Estoy intentando entender cómo agregar el inicio de sesión social y el registro a un servicio. Después de leer muchas publicaciones de blogs, muchas me recuerdan los inconvenientes de diseñar un sistema de este tipo, del hecho de que Oauth es para Autorización no Autenticación, la mayoría escritas por personas que exploran este tema mientras escriben, todas con opiniones diferentes sobre lo que conecta OpenID / OpenID / etc se trata, me encuentro más confundido que antes de empezar.
Entiendo que con el inicio de sesión social, el proveedor de ID realiza la autenticación. Cuando se autentica al usuario, el cliente (o el agente del usuario) debe estar en posesión de algo (¿un token seguro?) Que indique que el usuario logró probar su identidad. En las solicitudes posteriores a / the / API, el servidor, que desde el punto de vista del proveedor de ID es un tercero (¿se llama un usuario de confianza en algunos documentos?) Debería ser capaz de verificar este "token" y debe ser capaz de derivar de este "token" quién es el usuario real.
Entonces, en términos prácticos:
- ¿Qué recibiría la API del cliente cuando un usuario inicia sesión? Usando con Social Login?
- ¿Qué recibiría la API del cliente cuando un usuario se registre con Social Login?
- Como mínimo, ¿qué debo almacenar acerca de cada usuario con fines de autenticación (¿ID de usuario? ¿Correo electrónico para recuperar / vincular varias cuentas? ¿Proveedor de ID (en qué formato?), ¿Lista de sesiones actuales / fechas de vencimiento? Última ¿Tiempo de acceso / actualización tal vez? ¿Qué más?)
El sistema actual (una API llena de REST) emite un token cuando el usuario inicia sesión con el correo electrónico / contraseña con una publicación en api.example.com/session . En este caso, la API puede verificar que el usuario proporcionó las credenciales correctas.
Supongo que muchos artículos en línea solo hablan sobre cómo usar los tokens para consumir los recursos proporcionados por esa misma organización, por ejemplo, el inicio de sesión de Facebook para consumir las API de Facebook. Sin embargo, este podría ser mi malentendido.
Algunas preguntas específicas:
- ¿Qué aspecto tiene este token? ¿Revela el proveedor de identidad o cómo verificar la validez del token?
- ¿El token le da a la parte que confía (los servidores backend de la API) una forma de obtener, por ejemplo, el nombre completo o la dirección de correo electrónico del usuario? ¿O sería esa funcionalidad delegada al cliente?
- ¿Quién determina qué información proporciona este token? ¿El proveedor de ID o la aplicación cliente?
- ¿Qué sucede con el caso de un cliente web en el que el cliente y el agente de usuario no se ejecutan en el mismo dispositivo? ¿Puede el cliente o el agente de usuario "construir" un token nuevo que se puede usar para firmar solicitudes a la API e incluir los detalles importantes (ID de usuario, proveedor de ID, fecha de caducidad, ID de cliente)?
- ¿Se puede extender el punto final de "sesión" de la API para manejar tokens de "inicio de sesión social" o no es el enfoque correcto?
- ¿Es importante identificar / autenticar al cliente? Si es así, ¿cómo ... creo que los clientes móviles no pueden almacenar una clave de firma de forma segura?
Una nota sobre oAuth y Autorización: No creo que necesite autorización aquí. La API ya determina si las solicitudes se autorizan en función del usuario identificado.