Diseñe para la autenticación de Facebook en una aplicación de iOS que también tenga acceso a un servicio web seguro


Answers

Use https para transmitir el token de autenticación a su servidor, como lo indica Facebook

Uso compartido de tokens de acceso

Nuestras Políticas de datos prohíben explícitamente cualquier intercambio de un token de acceso para su aplicación con cualquier otra aplicación. Sin embargo, permitimos que los desarrolladores compartan Tokens entre una implementación nativa y una implementación de servidor de la misma Aplicación (es decir, usando el mismo ID de Aplicación) siempre que la transferencia se realice usando HTTPS.

Question

Objetivo: Permitir que un usuario autentique con Facebook en una aplicación de iOS que requiera acceso a un servicio web protegido que estoy ejecutando.

Supuestos: 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 de que un usuario inicie sesión con Facebook sin crear una cuenta / credencial separada para nuestro sistema.
  • Como admitimos nuestro propio mecanismo auth auth (nombre de usuario y contraseña), tenemos nuestros propios ID de usuario y emitimos un token de autenticación que se utiliza para interacciones posteriores después de la validación inicial de credenciales.

Me sorprende que Facebook no tenga las mejores prácticas para esto en su documentación de desarrollador. Toda la documentación existente supone que estás creando autenticación de FB en un sitio web o una aplicación móvil independiente sin ningún 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.

  1. El cliente aparece el inicio de sesión de Facebook en iOS
  2. Usuario de UI inicia sesión con credenciales de Facebook y obtiene token de acceso
  3. La aplicación iOS pasa el token de acceso a nuestro servidor
  4. Nuestro servidor habla con la API de gráficos de FB mediante el token de acceso para (a) validar el token y (b) obtener el 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

  5. 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 ticket de autenticación para que el cliente lo use para esa sesión. Si el usuario no tiene una cuenta, creamos una nueva con el ID de usuario de Facebook, asignamos nuestra propia ID de usuario y emitimos nuestro ticket de autenticación.

  6. El cliente vuelve a pasar el ticket de autenticación a interacciones posteriores que necesitan autenticación.

Este parece ser el enfoque correcto para mí, pero no estoy seguro si me estoy perdiendo algo increíblemente básico y voy por el camino equivocado (complicado).




tu solución funciona totalmente

Tal vez una alternativa: ¿por qué no simplemente recibir el correo electrónico del cliente de la solicitud de servicio social inicial y enviarlo a su servicio web? El servicio web podría simplemente almacenar el correo electrónico, y tal vez también un proveedor social. Entiendo que su servicio web no podrá validar de dónde vino 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 confiar en que el correo electrónico provenga del lugar correcto. Alguien, por favor, hágame saber qué cosa obvia que me falta hace que el enfoque basado en correo electrónico sea tonto ...






Links