Inicio de sesión con Facebook

Creación manual de un proceso de inicio de sesión

En el caso del inicio de sesión basado en el navegador para una aplicación web o para ordenadores sin nuestros SDK, como una vista web para una aplicación para ordenadores nativa (por ejemplo, Windows 8) o un proceso de inicio de sesión que use únicamente código del servidor, puedes crear un proceso de inicio de sesión mediante los redireccionamientos del navegador. Esta guía te orientará a lo largo del proceso de inicio de sesión y te mostrará cómo implementar sus pasos mediante nuestros SDK:

Para utilizar el inicio de sesión con Facebook en una aplicación para ordenadores, deberás poder insertar un navegador web (a veces denominado “vista web”) en la aplicación a fin de completar el proceso de inicio de sesión.

Comprobación del estado de inicio de sesión

Las aplicaciones que usan nuestros SDK pueden comprobar si alguien ya ha iniciado sesión con las funciones integradas. Todas las demás aplicaciones deben crear su propio método de determinar cuándo una persona ha iniciado sesión y, en el caso de que no exista ese indicador, deben suponer que la ha cerrado. Si una persona ha cerrado la sesión, tu aplicación debe redirigirla al cuadro de diálogo de inicio de sesión en el momento adecuado, por ejemplo, si hace clic en el botón “Iniciar sesión”.

Inicio de sesión de los usuarios

Si una persona no tiene la sesión iniciada en tu aplicación ni en Facebook, puedes utilizar el cuadro de diálogo de inicio de sesión para solicitarle que lo haga. Si no tiene la sesión iniciada en Facebook, se le solicitará que primero la inicie en la plataforma y, luego, en tu aplicación. Esto se detecta automáticamente, de modo que no tienes que hacer nada para activar este comportamiento.


Invocación del cuadro de diálogo de inicio de sesión y configuración de la URL de redireccionamiento

Tu aplicación debe iniciar un redireccionamiento a un extremo que mostrará el cuadro de diálogo de inicio de sesión:

https://www.facebook.com/v21.0/dialog/oauth?
  client_id={app-id}
  &redirect_uri={redirect-uri}
  &state={state-param}

Este extremo tiene los siguientes parámetros necesarios:

  • client_id: identificador de tu aplicación, que puedes encontrar en el panel de la aplicación.
  • redirect_uri: URL a la que quieres redirigir a la persona que vuelve a iniciar sesión. Esta URL capturará la respuesta del cuadro de diálogo de inicio de sesión. Si la utilizas en una vista web de una aplicación para ordenadores, deberás establecerla en https://www.facebook.com/connect/login_success.html. Puedes confirmar que la has establecido para tu aplicación en el panel de aplicaciones. En la sección Productos del menú de navegación izquierdo del panel de aplicaciones, haz clic en Inicio de sesión de Facebook y, luego, en Configuración. Verifica los URI de redireccionamiento de OAuth válidos en la sección Configuración de OAuth del cliente.
  • state: valor de cadena que ha creado tu aplicación para mantener el estado entre la solicitud y la devolución de llamada. Este parámetro debe usarse para impedir la falsificación de solicitudes entre sitios y se te devolverá sin modificaciones en tu URI de redireccionamiento.

Por ejemplo, si la solicitud de inicio de sesión tiene el aspecto siguiente:

https://www.facebook.com/v21.0/dialog/oauth?
  client_id={app-id}
  &redirect_uri={"https://www.domain.com/login"}
  &state={"{st=state123abc,ds=123456789}"}

Se llamará al URI de redireccionamiento con el código siguiente:

https://www.domain.com/login?state="{st=state123abc,ds=123456789}"

También tiene los parámetros opcionales siguientes:

  • response_type: determina si los datos de la respuesta incluidos cuando se produce el redireccionamiento de vuelta a la aplicación se expresan en fragmentos o parámetros de URL. Consulta la sección Confirmación de la identidad para elegir el tipo que debes usar para tu aplicación. Puede ser uno de los siguientes:
    • code: los datos de la respuesta se incluyen como parámetros URL y contienen el parámetro code (una cadena cifrada única en cada solicitud de inicio de sesión). Este es el comportamiento predeterminado si no se especifica este parámetro. Resulta más útil cuando el servidor gestiona el identificador.
    • token: los datos de la respuesta se incluyen como un fragmento de URL y contienen un identificador de acceso. Las aplicaciones para ordenadores deben usar esta configuración para response_type. Resulta más útil cuando el cliente gestiona el identificador.
    • code%20token: los datos de la respuesta se incluyen como un fragmento de URL y contienen un identificador de acceso y el parámetro code.
    • granted_scopes: devuelve una lista separada por comas de todos los permisos que concede el usuario a la aplicación en el momento del inicio de sesión. Se puede combinar con otros parámetros response_type. Cuando se combina con token, los datos de la respuesta se incluyen como un fragmento de URL. De lo contrario, se incluyen como un parámetro de URL.
  • scope: lista separada por espacios o comas de los permisos que se deben solicitar a la persona que utiliza la aplicación.
Para las aplicaciones de Windows 8

Si estás creando el inicio de sesión para una aplicación Windows, puedes utilizar el identificador de seguridad de paquete como redirect_uri. Para activar el cuadro de diálogo de inicio de sesión, llama a WebAuthenticationBroker.AuthenticateAsync y utiliza el extremo del cuadro de diálogo de inicio de sesión como requestUri. A continuación, puedes ver un ejemplo en JavaScript:

var requestUri = new Windows.Foundation.Uri(
  "https://www.facebook.com/v21.0/dialog/oauth?
    client_id={app-id}
    &display=popup
    &response_type=token
    &redirect_uri=ms-app://{package-security-identifier}");

Windows.Security.Authentication.Web.WebAuthenticationBroker.authenticateAsync(
  options,
  requestUri)
  .done(function (result) {
    // Handle the response from the Login Dialog
  }
);

Devolverá el proceso de control a la aplicación con un identificador de acceso si se completa correctamente. De lo contrario, se producirá un error.

Gestión de la respuesta del cuadro de diálogo de inicio de sesión

En este punto del proceso de inicio de sesión, la persona verá el cuadro de diálogo de inicio de sesión y tendrá la opción de cancelarlo o permitir a la aplicación que acceda a sus datos.

Si la persona que utiliza la aplicación elige Aceptar en el cuadro de diálogo de inicio de sesión, concederá acceso a su perfil público, la lista de amigos y cualquier permiso adicional que haya solicitado la aplicación.

En cualquier caso, el navegador volverá a la aplicación y se incluirán los datos de respuesta que indicarán si alguien se conectó o canceló la conexión. Cuando la aplicación utiliza el método de redireccionamiento tal y como se ha indicado, se anexan parámetros o fragmentos de URL, que se deben capturar, al parámetro redirect_uri que devuelve dicha aplicación (según el parámetro response_type elegido).

Debido a que se pueden usar diversas combinaciones de lenguajes de programación en las aplicaciones web, nuestras guías no muestran ejemplos específicos. Sin embargo, la mayoría de lenguajes modernos pueden realizar análisis de URL, según se indica a continuación:

El código JavaScript de cliente puede capturar fragmentos de URL (por ejemplo, jQuery BBQ), mientras que los parámetros URL se pueden capturar tanto desde el código de cliente como de servidor (por ejemplo, $_GET en PHP, jQuery.deparam en jQuery BBQ, querystring.parse en Node.js o urlparse en Python). Microsoft proporciona una guía y un ejemplo de código para las aplicaciones Windows 8 que se conectan a un “proveedor de internet”; en este caso, Facebook.

Al iniciar sesión en una aplicación para ordenadores, Facebook redirige a los usuarios al parámetro redirect_uri mencionado anteriormente y coloca un identificador de acceso junto con otros metadatos (como la hora de expiración del identificador) en el fragmento de URI:

https://www.facebook.com/connect/login_success.html#
    access_token=ACCESS_TOKEN...

Tu aplicación debe detectar este redireccionamiento y, luego, leer el identificador de acceso del URI mediante los mecanismos que proporciona el sistema operativo y el marco de desarrollo que utilizas. A continuación, puedes ir directamente al paso Inspección de los identificadores de acceso.


Cancelación del inicio de sesión

Si los usuarios de tu aplicación no aceptan el cuadro de diálogo de inicio de sesión y hacen clic en Cancelar, se les dirigirá aquí:

YOUR_REDIRECT_URI?
 error_reason=user_denied
 &error=access_denied
 &error_description=Permissions+error.

Consulta Gestión de los permisos que faltan para obtener más información sobre lo que deben hacer las aplicaciones cuando los usuarios rechazan el inicio de sesión.

Confirmación de la identidad

Dado que este proceso de redireccionamiento envía a los navegadores a las URL de tu aplicación desde el cuadro de diálogo de inicio de sesión, el tráfico podría acceder directamente a esta URL con fragmentos o parámetros falsos. Si la aplicación asume que los parámetros son válidos, utilizará los datos falsos con fines potencialmente maliciosos. Como resultado, tu aplicación deberá confirmar que la persona que la utiliza es la misma de la que tienes datos de respuesta antes de generarle un identificador de acceso. La confirmación de identidad se realiza de distintas formas en función del parámetro response_type recibido anteriormente:

  • Cuando se recibe el elemento code, este debe intercambiarse por un identificador de acceso mediante un extremo. La llamada deberá realizarse de servidor a servidor, ya que implica una clave secreta de la aplicación. (La clave secreta de la aplicación nunca debe finalizar con el código del cliente).
  • Cuando se recibe el elemento token, este debe verificarse. Deberás realizar una llamada a la API a un extremo de inspección que indicará el usuario para el que se generó el identificador, así cómo la aplicación que lo creó. Dado que esta llamada a la API requiere el uso de un identificador de acceso a la aplicación, no debes realizarla nunca desde un cliente. En su lugar, realízala desde un servidor en el que puedas almacenar con seguridad la clave secreta de la aplicación.
  • Cuando se reciban los elementos code y token, deben llevarse a cabo ambos pasos.

Ten en cuenta que también puedes generar tu propio parámetro state y utilizarlo con la solicitud de inicio de sesión para proporcionar protección frente a CSRF.

Intercambio de código para un identificador de acceso

Para obtener un identificador de acceso, realiza una solicitud HTTP GET al siguiente extremo OAuth:

GET https://graph.facebook.com/v21.0/oauth/access_token?
   client_id={app-id}
   &redirect_uri={redirect-uri}
   &client_secret={app-secret}
   &code={code-parameter}

Este extremo tiene algunos parámetros necesarios:

  • client_id: los identificadores de tu aplicación
  • redirect_uri: este argumento es obligatorio y debe ser el mismo que el parámetro request_uri original que utilizaste al iniciar el proceso de inicio de sesión de OAuth.
  • client_secret: tu clave secreta de la aplicación, que se muestra en el panel de aplicaciones. No incluyas nunca esta clave secreta de la aplicación en el código del cliente o en archivos binarios que se puedan descompilar. Es muy importante que permanezca completamente en secreto a fin de preservar la seguridad de tu aplicación y de todas las personas que la utilizan.
  • code: parámetro recibido del redireccionamiento del cuadro de diálogo de inicio de sesión anterior.

Nota: A partir de la versión 2.3, este extremo devolverá una respuesta JSON adecuada. Si tu aplicación no especifica ninguna versión, se establecerá de manera predeterminada en la versión más antigua disponible.

Respuesta

La respuesta que recibirás de este extremo se devolverá en formato JSON y, en el caso de que la operación se complete correctamente, tendrá el aspecto siguiente:

{
  "access_token": {access-token}, 
  "token_type": {type},
  "expires_in":  {seconds-til-expiration}
}

Si no se completa correctamente, recibirás un mensaje de error descriptivo.

Inspección de los identificadores de acceso

Tanto si tu aplicación utiliza los elementos code o token como parámetro response_type en el cuadro de diálogo de inicio de sesión como si no, habrá recibido un identificador de acceso. Puedes realizar las comprobaciones automáticas en estos identificadores con un extremo de la API Graph:

GET graph.facebook.com/debug_token?
     input_token={token-to-inspect}
     &access_token={app-token-or-admin-token}

Este extremo toma los parámetros siguientes:

La respuesta de la llamada a la API es una matriz JSON que contiene datos sobre el identificador inspeccionado. Por ejemplo:

{
    "data": {
        "app_id": 138483919580948, 
        "type": "USER",
        "application": "Social Cafe", 
        "expires_at": 1352419328, 
        "is_valid": true, 
        "issued_at": 1347235328, 
        "metadata": {
            "sso": "iphone-safari"
        }, 
        "scopes": [
            "email", 
            "publish_actions"
        ], 
        "user_id": "1207059"
    }
}

Los campos app_id y user_id ayudan a la aplicación a verificar que el identificador de acceso es válido para la persona y la aplicación. A fin de obtener una descripción completa de los demás campos, consulta la guía para obtener información sobre los identificadores de acceso.

Comprobación de permisos

Puede llamarse al perímetro /me/permissions para recuperar una lista de permisos que ha concedido o rechazado un usuario concreto. Tu aplicación puede utilizarlo para comprobar cuál de los permisos solicitados no puede emplear para un usuario en concreto.

Nueva solicitud de permisos rechazados

El inicio de sesión con Facebook permite a las personas denegar el uso de algunos permisos a la aplicación. El cuadro de diálogo contiene una pantalla con el aspecto siguiente:

El permiso public_profile siempre es obligatorio y se muestra atenuado porque no se puede inhabilitar.

Sin embargo, si alguien quisiera desmarcar el parámetro user_likes (Me gusta) de este ejemplo, al comprobar los permisos que se han concedido en /me/permissions, se obtendría el resultado siguiente:

{
  "data":
    [
      {
        "permission":"public_profile",
        "status":"granted"
      },
      {
        "permission":"user_likes",
        "status":"declined"
      }
    ]
}

Ten en cuenta que el parámetro user_likes se ha rechazado, en lugar de concederse.

Aún así, se puede volver a solicitar a una persona que conceda a la aplicación permisos que ya rechazó. Para ello, deberías mostrar una pantalla informativa que explique por qué piensas que debería reconsiderarlo y, después, solicitar el permiso de nuevo. Sin embargo, si invocas el cuadro de diálogo de inicio de sesión como se ha descrito anteriormente, no se solicitará ese permiso.

El motivo es que, una vez que se rechaza un permiso, el cuadro de diálogo de inicio de sesión no vuelve a solicitarlo, salvo que le indiques expresamente que solicite de nuevo un permiso rechazado.

Para hacerlo, debe añadirse el parámetro auth_type=rerequest a la URL del cuadro de diálogo de inicio de sesión:

https://www.facebook.com/v21.0/dialog/oauth?
    client_id={app-id}
    &redirect_uri={redirect-uri}
    &auth_type=rerequest
    scope=email

De este modo, el cuadro de diálogo de inicio de sesión volverá a solicitar el permiso rechazado.

Almacenamiento de los identificadores de acceso y el estado de inicio de sesión

En este momento del proceso, tienes un usuario autenticado con la sesión iniciada. Tu aplicación está lista para realizar llamadas a la API en su nombre. Sin embargo, antes debe almacenar el identificador de acceso y el estado de inicio de sesión de la persona que utiliza la aplicación.

Almacenamiento de los identificadores de acceso

Una vez que tu aplicación reciba el identificador de acceso del paso anterior, este debe almacenarse para estar disponible en todas las partes de la aplicación cuando realice llamadas a la API. Para ello, no existe ningún proceso específico. No obstante, por lo general, si creas una aplicación web, se recomienda añadir el identificador como una variable de la sesión a fin de asociar esa sesión del navegador con una persona concreta. En el caso de que crees un ordenador nativo o una aplicación para móviles, deberás utilizar el almacén de datos disponible para tu aplicación. Además, la aplicación debe almacenar el identificador en una base de datos junto con user_id para poder identificarlo.

Consulta nuestra nota sobre el tamaño de los identificadores de acceso en el documento de identificadores de acceso.

Seguimiento del estado del inicio de sesión

De nuevo, tu aplicación debe almacenar el estado de inicio de sesión de una persona, ya que evita tener que realizar llamadas adicionales al cuadro de diálogo de inicio de sesión. Independientemente del procedimiento que elijas, modifica la comprobación del estado de inicio de sesión para tenerlo en cuenta.

Cierre de sesión de los usuarios

Para cerrar la sesión de los usuarios, debes deshacer cualquier indicador de estado de inicio de sesión que hayas añadido; por ejemplo, mediante la eliminación de la sesión que indica que una persona ha iniciado sesión. También debes eliminar el identificador de acceso almacenado.

Cerrar la sesión de un usuario no es lo mismo que revocar el permiso de inicio de sesión (eliminar la autenticación concedida anteriormente) y estos son procesos que pueden realizarse por separado. Por este motivo, cuando crees tu aplicación, haz que no redirija automáticamente al cuadro de diálogo de inicio de sesión a las personas que han cerrado sesión.

Detección de cuándo desinstalan aplicaciones los usuarios

Una persona puede desinstalar aplicaciones desde Facebook.com sin tener que interactuar con ellas. Para que las aplicaciones puedan detectarlo, permitimos que proporcionen una URL de devolución de llamada de retirada de autorización. Esta llamada se realiza en el momento de la desinstalación.

Puedes activar la devolución de llamada de retirada de autorización mediante el panel de aplicaciones.

Respuestas a solicitudes para eliminar datos de los usuarios

Las personas pueden solicitar a una aplicación que elimine toda la información que ha recibido de Facebook sobre ellas. Para responder a estas solicitudes, consulta Devolución de llamada de la solicitud de eliminación de datos.