Cómo pasar el Id de Facebook del cliente al servidor de forma segura

Question

Tengo una aplicación de Facebook para lienzos. Estoy usando JS SDK para autenticar al usuario en el navegador y solicitar información a través de FB.api (por ejemplo, nombre, amigos, etc.).

También quiero persistir alguna información adicional del usuario (no se celebró en Facebook) a la base de datos en mi servidor al hacer una llamada AJAX:

{ userFavouriteColour: "Red" } 

Para guardar esto en el servidor y asociarse con el usuario correcto , Necesito saber el uid de Facebook y esto presenta un problema. ¿Cómo paso el uid desde el cliente al servidor?

Opción 1: Añadir fluido a la petición ajax:

{ uid: "1234567890", 
    userFavouriteColour: "Red" } 

Esto obviamente no es bueno. Sería trivial para cualquier persona hacer una solicitud de AJAX a mi servicio web usando el ID de Facebook de otra persona y cambiar su color favorito.

Opción 2: en el servidor, extraer el uid de una cookie: ¿Esto es posible? He leído que Facebook establece una cookie que contiene el token uid y de acceso, pero ¿tengo acceso a esta cookie en mi dominio? Más importante aún, ¿puedo segura extraer el fluido forma la cookie o se trata abierta a la suplantación de identidad al igual que la opción 1.

Opción 3: El usuario de autenticación de servidor en el servidor: que podía usar el servidor- Autenticación lateral para validar la identidad del usuario en mi servidor. Pero, ¿funcionará si ya estoy usando la autenticación del lado del cliente en el navegador? ¿Terminaré con dos tokens de acceso diferentes? Me gustaría realizar solicitudes FB.api desde el navegador, así que necesito el token de acceso en el cliente (no solo en el servidor).

Esto debe ser un escenario muy común, así que creo que me falta algo fundamental. He leído mucha de la documentación de Facebook (varios flujos de autenticación, tokens de acceso, signed_request, etc.) y muchas publicaciones en SO, pero todavía no entiendo cómo la autenticación del lado del cliente y la autenticación del lado del servidor funcionan muy bien juntas.

En resumen, quiero saber la identidad del usuario en el servidor pero aún así hacer las solicitudes a la API de Facebook desde el navegador del cliente?

(estoy usando ASP.NET y C# SDK de Facebook en el servidor)

EDITAR: Añadido recompensa. Esperaba obtener una recomendación oficial más deifnitiva sobre cómo manejar esta situación, o incluso un ejemplo. Como ya he dicho, ya he leído muchos de los documentos oficiales de FB sobre los flujos de autenticación, pero todavía no encuentro nada definitivo sobre cómo la autenticación del lado del cliente y la del lado del servidor funcionan juntas.

Answer 1

Opción 1: La manera más fácil de lo que puedo pensar es incluir la accessToken en JS y pasarlo con la llamada Ajax.

Opción 2: Usando lo mismo que en la opción 1, pero en lugar de enviar simplemente el accessToken, envíe el signedRequest.

En el lado del servidor puede descifrar usando (TryParseSignedRequest método) que le dará la UserID :-)

Nota: signedRequest se cifra con el secreto de la aplicación. eres el único que debería saberlo, así que estás a salvo en ese extremo.

responsabilidad:

que no tienen experiencia de codificación en C#, pero un poco de búsqueda en Google me dio esto:

Facebook C# SDK for ASP.NET

Making AJAX Requests with the Facebook C# SDK

Answer 2

No sé si es un idioma específico, pero usar tanto la autenticación del lado del servidor como la del lado del cliente no hace daño.

Puede trabajar en la opción 2 pero sí, eso también será vulnerable a la suplantación.

Al hacer la opción 3, tendrá un token de acceso único para esa sesión de usuario, por lo que sería la mejor opción, ya que siempre tiene la posibilidad de suplantar cuando pasa información del usuario del lado del cliente.

Answer 3

Hace exactamente exactamente lo mismo. Es la opción 2. Compruebe this post desde el blog de Facebook.

Para ser sincero, no soy lo suficientemente hacker como para saber si puedes tapar el UID en la cookie, pero esta parece ser la manera "oficial" de hacerlo.

EDITAR: a la otra pregunta en la opción 2, sí, creo que tiene que acceder a esta cookie en su dominio.

Answer 4

Es muy simple en realidad.

Cuando el usuario carga su aplicación, use server side authentication, obtenga el token de acceso y cargue los datos del usuario emitiendo una solicitud de API del servidor.
En el lado del servidor, tendrá todo lo que necesita y es un espacio aislado.

Cuando la página rinde para el usuario, utilizando js sdk obtenga los datos de autenticación del usuario, debe poder usar FB.getLoginStatus ya que el usuario ya pasó por la autenticación del lado del servidor.
Ahora en el lado del cliente también tiene un token de acceso que puede usar para obtener los datos del usuario de la API del gráfico.

Los dos tokens serán diferentes, y también tendrán una fecha de caducidad diferente, pero eso no debería ser un problema, ambos tokens deberían funcionar correctamente como usted esperaría.
Dado que ambos lados tienen su propio token y una forma de realizar solicitudes a la API, no hay necesidad de enviar ningún dato de fb entre ellos.

Así que la tercera opción que mencionas, para mí, suena mejor, y es muy simple de implementar también.

---

Editar

Todos los SDK de Facebook son sólo envoltorios de petición http ya que todo el API fb se hace en las solicitudes HTTP.
Los SDK solo le brindan acceso fácil y más corto a los datos sin la necesidad de construir la URL usted mismo (con todos los diferentes parámetros posibles), realizar la solicitud y analizar la respuesta.

Para ser completamente honesto, creo que dejar de proporcionar una forma para que el C# SDK sea compatible con la autenticación del lado del servidor es una muy mala decisión.
¿De qué sirve proporcionar un SDK que no implemente toda la API?

La mejor respuesta a su pregunta, desde mi experiencia, es utilizar tanto la autenticación del lado del servidor como del lado del cliente, y dado que el SDK C# no lo admite, mi consejo es crear su propio SDK.
No es complicado en absoluto, ya lo implementé para python y java (dos veces), y como lo desarrollará para sus propias necesidades, puede adaptarse a sus necesidades exactas, a diferencia de un SDK público que debería admitir todos los posibles opciones.

---

segunda edición

No hay necesidad de crear un nuevo SDK, sólo puede "extender" los que usted está usando y añadir las partes que faltan que usted necesita, como soporte de autenticación lado del servidor.