Objetivo: permitir que un usuario se autentique con Facebook en una aplicación de iOS que requiere acceso a un servicio web protegido que estoy ejecutando.
Suposiciones: existe un sistema de autenticación (y registro) nativo para aquellos usuarios que optan por no usar Facebook para iniciar sesión.
Detalles:
- Supongamos que queremos ofrecer la opción para que un usuario inicie sesión con Facebook sin crear una cuenta / credencial separada para nuestro sistema.
- Debido a que admitimos nuestro propio mecanismo de autenticación nativo (nombre de usuario y contraseña), tenemos nuestras propias ID de usuario y emitimos un token de autenticación que se utiliza para las interacciones posteriores después de la validación de credencial inicial.
Me sorprende que Facebook no tenga las mejores prácticas para esto en su documentación para desarrolladores. Toda la documentación existente supone que está incorporando la autenticación FB en un sitio web o una aplicación móvil independiente sin servicio que requiera autenticación.
Aquí están mis pensamientos iniciales sobre cómo se diseñaría esto, pero quiero validar si es correcto.
- El cliente muestra el inicio de sesión de Facebook iOS
- El usuario de la interfaz de usuario inicia sesión con credenciales de Facebook y obtiene token de acceso
- La aplicación iOS pasa el token de acceso a nuestro servidor
Nuestro servidor se comunica con la API de gráficos FB utilizando el token de acceso para (a) validar el token y (b) obtener la ID de usuario de FB para ese token de acceso.
por ejemplo, nuestro servidor llamaría a https://graph.facebook.com/me/?access_token=XYZ que devolvería información de perfil en un objeto JSON
Suponiendo que sea válido, nuestro servidor extrae la ID de usuario del objeto JSON y verifica si el usuario ya tiene una cuenta. Si es así, emitimos nuestro propio boleto de autenticación al cliente para usar en esa sesión. Si el usuario no tiene una cuenta, creamos una nueva con la ID de usuario de Facebook, asignamos nuestra propia ID de usuario única y emitimos nuestro ticket de autenticación.
- El cliente luego devuelve el ticket de autenticación en las interacciones posteriores que necesitan autenticación.
Este parece ser el enfoque correcto para mí, pero no estoy seguro de si me estoy perdiendo algo increíblemente básico y estoy yendo por el camino equivocado (complicado).
Respuestas:
Acabo de lidiar con esto yo mismo, y aquí está la parte que me mordió:
En su paso 5 ... Es posible que un usuario se registre para una cuenta con usted completamente separada de su ID de Facebook, ¿verdad? Luego, en otro momento, inician sesión con Facebook ... Y acabas de crearles una segunda cuenta y perdiste la primera.
Debe haber una manera de iniciar sesión en su servicio web, luego iniciar sesión en Facebook y capturar la asociación entre la identificación de Facebook y la cuenta local.
Aparte de eso, su plan suena sólido.
Actualización : Facebook ha agregado un documento que describe tal escenario AQUÍ
fuente
Use https para transmitir el token de autenticación a su servidor, como lo indica Facebook
fuente
Un problema que puedo ver con esta estrategia es que alguien puede darle un token de acceso obtenido para una aplicación de Facebook diferente. Hasta donde yo sé, no hay forma de verificar que el token de acceso sea para su aplicación, por lo que simplemente deberá seguir usándolo.
Sin embargo, no suena muy dañino. En general, las personas / aplicaciones intentan proteger los tokens de acceso, en lugar de compartirlos.
Una posible hazaña de esto sería que alguien cree su propio sitio o aplicación móvil, obtenga tokens de acceso para sus usuarios e intente autenticarlos, utilizando su API. Si esto tiene éxito (el usuario tiene una cuenta de Facebook en su sitio), el sitio malicioso podrá usar su API para hacerse pasar por el usuario.
Es un poco arriesgado, pero creo que podría funcionar.
Editar: parece que hay una manera de validar el token de acceso después de todo. Vea la respuesta de @Daaniel en la pregunta Obtenga la identificación de la aplicación del token de acceso del usuario (o verifique la aplicación de origen para un token) .
fuente
appsecret_proofdebería evitar esto (ver aquí )appsecret_proofayuda aquí? Según tengo entendido, sirve para demostrarle a Facebook que el servidor conoce la clave secreta. Sin embargo, ivant se refería a una aplicación maliciosa que obtenía tokens y luego los enviaba a su API. El servidor puede verificar la identificación de la aplicación, pero una aplicación maliciosa puede suplantarla fácilmente. Entonces ... ¿cómo se mitigaría esto?https://graph.facebook.com/app/?access_token=[user_access_token]cual se devuelve la identificación de la aplicación y luego se comparan los identificadores de la aplicaciónSu solución funciona totalmente.
Tal vez una alternativa: ¿por qué no simplemente recibir el correo electrónico del cliente desde la solicitud inicial del servicio social y enviarlo a su servicio web? El servicio web podría simplemente almacenar el correo electrónico, y quizás también un proveedor social. Entiendo que su servicio web no podrá validar de dónde proviene el correo electrónico, pero ¿no existe una relación de alta confianza entre su servicio web y su cliente? Si lo hay, parece que puede depender del correo electrónico proveniente del lugar correcto. Alguien, por favor, hágame saber qué cosa obvia me estoy perdiendo que hace que el enfoque basado en correo electrónico sea tonto ...
fuente