Facebook oAuth2 para la aplicación de cliente Javascript

Question

Facebook oAuth2 para la aplicación de cliente Javascript

#1 de Trace (3 votos)

4

Al implementar el inicio de sesión de Facebook usando oAuth2 (la versión de Javascript), recibo un token de acceso del servidor de autenticación de Facebook. Hasta ahora tan bueno.

El problema que tengo es que quiero implementar un back-end RESTful, donde el usuario necesita autenticarse en cada solicitud para acceder a un recurso de back-end, utilizando un token generado por el servidor. Lo que sucede es que cuando uso el inicio de sesión estándar en mi sitio web (correo electrónico + contraseña), este token se genera en el servidor mediante mi propia aplicación y luego se envía al servidor donde está almacenado (todas las transacciones se realizan a través de https).

Así que pensé en usar el token de acceso que recibo de Facebook para almacenarlo en mi back-end, si el usuario desea iniciar sesión usando Facebook. De esta manera, cada solicitud RESTful al back-end podría verificarse con este token.

Sin embargo, el problema es que el back-end no puede verificar si el token recibido del cliente es un token de acceso a Facebook válido (esta es una aplicación de cliente Javascript, que depende en gran medida de Ajax para todas las comunicaciones del servidor). A pesar de que puedo escribir Javascript para enviar solo el token de acceso al back-end después de una autenticación exitosa con el servidor FB, este proceso no es confiable ya que el Javascript no está protegido.

Mi pregunta es:

¿Cómo puedo guardar de forma segura un token en mi back-end, después del usuario? ¿Autenticado con Facebook?

Tenga en cuenta que estoy creando una aplicación Javascript utilizando Backbone.

authentication oauth facebook javascript

pregunta Trace 16.06.2014 - 14:41

fuente

1 respuesta

Lea otras preguntas en las etiquetas authentication oauth facebook javascript

¿Qué navegadores son compatibles con TACK? ¿Cómo se puede enviar un correo electrónico desde una dirección de Yahoo a través de Yahoo sin autenticación?

score 3 · Answer 1

Editar: cambié el flujo de trabajo para el inicio de sesión. Si un usuario tuviera varias cuentas de terceros y cada cuenta usa una dirección de correo electrónico diferente, entonces la dirección de correo electrónico no es un identificador válido. Ahora estoy usando ID de usuario local.

1) Cuando el usuario desea iniciar sesión utilizando un acceso de terceros como Facebook o Google, el cliente solicita un token de acceso con Javascript al servidor de autenticación de este tercero. Cuando se autentica el propietario del recurso (usuario), se devuelve el ID de usuario (y otros datos relacionados) en la respuesta, junto con el token de acceso. Este token se almacena en el cliente en forma de una cookie de tiempo limitado persistente (por ejemplo, 60 minutos);

2) El cliente envía una solicitud Ajax al servidor Zwoop, enviando la tercera parte (FB / Google), la tercera ID de usuario y el token de acceso con una solicitud POST;

3) El servidor Zwoop recibe la solicitud de Ajax y envía una solicitud (con PHP) al servidor de autenticación de terceros (basado en el que está definido en la solicitud de ajax) para obtener el ID de usuario de terceros, basado en el acceso token (que se recibió de la solicitud ajax). Cuando la coincidencia de userId es exitosa, el servidor Zwoop ha verificado que el cliente ha enviado las credenciales correctas.

Este enfoque hace que el token de acceso oauth2 funcione como una contraseña, y se verifique en el back-end contra el servidor Auth del tercero. Ningún usuario malintencionado debe poder simular la misma combinación de credenciales y la comunicación se realiza a través de SSL (sin intercepción);

4) Después de que se haya realizado la verificación de coincidencia de token de userId en el servidor, se puede recuperar el userId local y devolverlo al cliente. El ID de usuario local es el ID de usuario que Zwoop define. Para todas las solicitudes adicionales de recursos para el back-end de Zwoop, utilizamos el ID de usuario local en lugar del ID de usuario de terceros, por eso lo recuperamos en este paso.

El token ahora se puede guardar en MySQL y el token de Zwoop userId + se puede almacenar en caché en Redis / memcached.

5) El ID de usuario local de Zwoop se reenvía al cliente. Usamos el ID de usuario local para más solicitudes al back-end. Solo utilizamos el ID de usuario de terceros en caso de que necesitemos acceso a recursos específicos de terceros (por ejemplo, noticias de Facebook, calendario, etc.). Si la autenticación falla, no se enviará el ID de usuario;

Ahora se pueden realizar más solicitudes REST, mientras que el token de acceso oAuth (cliente) se compara con el token (servidor) en caché, para identificar si el usuario tiene permiso para acceder a ciertos recursos en nuestra propia aplicación; Cuando la cookie o el token de acceso hayan caducado, el cliente solicitará uno nuevo y se repetirá el mismo procedimiento.