Inicio de sesión con Facebook

Crear un proceso de inicio de sesión de forma manual

Si quieres implementar un inicio de sesión basado en un navegador para una app web o para computadoras sin usar nuestros SDK, como en una vista web de una app nativa para computadoras (por ejemplo, Windows 8) o un proceso de inicio de sesión que utiliza completamente códigos del servidor, puedes compilar un proceso de inicio de sesión por tu cuenta usando redireccionamientos de navegador. En esta guía se explica cada paso del proceso de inicio de sesión y se muestra cómo implementarlos sin usar nuestros SDK:

A fin de usar el inicio de sesión con Facebook en una app para computadoras, es necesario que puedas insertar un navegador web (algunas veces, llamado "vista web") dentro de la app para realizar el proceso de inicio de sesión.

Comprobar el estado del inicio de sesión

Las apps que usan nuestros SDK pueden verificar si alguien ya inició sesión mediante las funciones integradas. Todas las demás apps deben crear su propia forma de almacenamiento cuando una persona inicia sesión y, cuando dicho indicador no se encuentra allí, se procede a asumir que cerraron la sesión. Si alguien cierra la sesión, la app deberá volver a dirigir a esa persona al cuadro de diálogo de inicio de sesión en el momento apropiado, por ejemplo, cuando haga clic en el botón "Iniciar sesión".

Iniciar la sesión

Si una persona no inició sesión en la app o en Facebook, puedes usar el cuadro de diálogo de inicio de sesión para indicarle que inicie sesión en tu página y en Facebook. Si la persona no inició sesión en Facebook, se le pedirá que lo haga y, después, que inicie sesión en la app. Se detectará de manera automática, por lo que no es necesario hacer nada extra para activar este comportamiento.


Invocar el cuadro de diálogo de inicio de sesión y la configuración de la URL de redireccionamiento

La app debe iniciar un redireccionamiento a un punto de conexión, que mostrará el cuadro de diálogo de inicio de sesión:

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

Este punto de conexión requiere los siguientes parámetros:

  • client_id. Es el identificador de la app que se encuentra en el panel de la app.
  • redirect_uri. La URL a la que deseas redirigir a la persona que inicia sesión. Esta URL capturará la respuesta del cuadro de diálogo de inicio de sesión. Si se utiliza esto en una vista web dentro de una app para computadoras, debe establecerse en https://www.facebook.com/connect/login_success.html. Puedes confirmar si esta URL está configurada para la app en el panel de apps. En Productos, en el menú de navegación del lado izquierdo del panel de apps, haz clic en Inicio de sesión con Facebook y, a continuación, en Configuración. Verifica los URI de redireccionamiento de OAuth válidos en la sección Configuración de OAuth de cliente.
  • state. Un valor de cadena creado por la app para mantener el estado entre la solicitud y la devolución de llamada. Este parámetro se debe usar para prevenir la falsificación de solicitudes entre sitios, y se te devolverá sin cambios en el URI de redireccionamiento.

Por ejemplo, si la solicitud de inicio de sesión se ve así:

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

el URI de redireccionamiento se llamaría así:

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

También presenta los siguientes parámetros opcionales:

  • response_type. Determina si los datos de la respuesta incluida al producirse el redireccionamiento a la app están en forma de fragmentos o parámetros de URL. Consulta la sección Confirmación de identidad para seleccionar qué tipo debería usar tu app. Puede ser alguna de estas opciones:
    • code. Los datos de la respuesta se incluyen como parámetros URL y contienen el parámetro code (un elemento único en cadena cifrado para cada solicitud de inicio de sesión). Este es el comportamiento predeterminado si no se especificó este parámetro. Es más útil si el servidor administra el token.
    • token. Los datos de la respuesta se incluyen como fragmento de URL y contienen un token de acceso. La app para computadoras debe usar esta configuración para response_type. Es más útil si el cliente administra el token.
    • code%20token. Los datos de la respuesta se incluyen como fragmento de la URL y contienen un token de acceso y el parámetro code.
    • granted_scopes. Devuelve una lista separada por comas de los permisos que el usuario le otorgó a la app al momento de iniciar la sesión. Puede combinarse con otros valores response_type. Cuando se combina con token, los datos de respuesta se incluyen como fragmento de la URL; caso contrario, se incluyen como parámetro de URL.
  • scope. Una lista separada por comas o espacios de los permisos que se le solicitarán a la persona que usa la app.
Para apps de Windows 8

Si compilas un inicio de sesión para una app de Windows, puedes usar el identificador del paquete de seguridad como tu redirect_uri. Activa el cuadro de diálogo de inicio de sesión llamando a WebAuthenticationBroker.AuthenticateAsync y usa el punto de conexión del cuadro de diálogo de inicio de sesión como requestUri. Aquí se muestra un ejemplo en JavaScript:

var requestUri = new Windows.Foundation.Uri(
  "https://www.facebook.com/v19.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
  }
);

Se devolverá un proceso de control a la app con un token de acceso en caso de ser satisfactorio, o un error en caso de que falle.

Administrar 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 posibilidad de cancelar o permitir que la app acceda a sus datos.

Si la persona que usa la app elige Aceptar en el cuadro de diálogo de inicio de sesión, otorga acceso a su perfil público, lista de amigos y a los permisos adicionales que solicitó la app.

En todos los casos, el navegador devuelve una respuesta a la app, y se incluyen los datos de la respuesta que indican si alguna persona se conectó o canceló la solicitud. Si la app usa el método de redireccionamiento según se describió anteriormente, el redirect_uri que devuelve la app se agregará a los parámetros o fragmentos de URL (según el response_type elegido), lo que debe capturarse.

Dado que las apps web podrían usar muchas combinaciones distintas de lenguajes de programación, nuestra guía no muestra ejemplos específicos. Sin embargo, los lenguajes más modernos podrán analizar la URL de la siguiente manera:

JavaScript del lado del cliente puede capturar fragmentos de URL (por ejemplo jQuery BBQ), mientras que el código del lado del cliente y del servidor puede capturar los parámetros de URL (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 apps de Windows 8 que se conectan a un "proveedor en línea", en este caso, Facebook.

Cuando se usa una app para computadoras y se inicia sesión, Facebook redirige a las personas al redirect_uri que se indicó anteriormente y proporciona un token de acceso junto con otros metadatos (como la fecha de caducidad del token) en el fragmento de URI:

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

La app debe detectar este redireccionamiento y luego leer el token de acceso desde el URI usando los mecanismos proporcionados por el sistema operativo y el marco de desarrollo que se está utilizando. Luego, puedes ir directo al paso inspeccionar tokens de acceso.


Inicio de sesión cancelado

Si las personas que usan la app no aceptan el cuadro de diálogo de inicio de sesión y hacen clic en Cancelar, serán redirigidas a:

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

Consulta Administra los permisos faltantes para obtener más información sobre qué deberían hacer las apps cuando las personas deciden no iniciar sesión.

Confirmar la identidad

Dado que este proceso de redireccionamiento implica que se redireccionen los navegadores a las URL de la app desde el cuadro de diálogo de inicio de sesión, el tráfico podría acceder directamente esta URL con los parámetros o fragmentos inventados. Si la app asumió que estos parámetros eran válidos, la app podría usar los datos inventados con fines potencialmente maliciosos. Como consecuencia, la app debería confirmar que la persona que usa la app es la misma de quien tienes datos de respuesta antes de generarle un token de acceso. Se puede lograr confirmar la identidad de diferentes maneras según el response_type recibido más arriba:

  • Cuando se recibe un code, debe intercambiarse por un token de acceso mediante un punto de conexión. Es necesario que la llamada sea de servidor a servidor, dado que implica indicar la clave secreta de la app (la clave secreta de la app no debería aparecer nunca en código del cliente).
  • Cuando se recibe el token, debe ser verificado. Deberías realizar una llamada a la API de un punto de conexión de inspección que indicará para quién se generó el token y qué app lo hizo. Dado que esta llamada a la API requiere que se use un token de acceso a la app, nunca hagas esta llamada desde un cliente. En cambio, haz esta llamada desde un servidor en el que puedas almacenar de manera segura la clave secreta de la app.
  • Cuando se reciben code y token, se deben realizar ambos pasos.

Ten en cuenta que también puedes generar tu propio parámetro state y usarlo con la solicitud de inicio de sesión para proporcionar protección contra CSFR.

Intercambiar código por un token de acceso

Para obtener un token de acceso, realiza una solicitud GET HTTP al siguiente punto de conexión de OAuth:

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

Este punto de conexión tiene algunos parámetros obligatorios:

  • client_id. Los identificadores de la app
  • redirect_uri. Este argumento es obligatorio y debe ser idéntico al del request_uri original que utilizas cuando comienzas el proceso de inicio de sesión de OAuth.
  • client_secret. La clave secreta de la app que se muestra en el panel de apps. No incluyas nunca la clave secreta de tu app en el código del cliente ni en binarios que puedan descompilarse. Es imperioso que continúe siendo totalmente secreta, porque es el punto central de la seguridad de la app y de todas las personas que la usan.
  • code. El parámetro recibido del cuadro de diálogo de inicio de sesión que se redirigió anteriormente.

Nota: A partir de la versión 2.3, este punto de conexión devolverá una respuesta JSON propia. Si la llamada no tiene una versión especificada, se establecerá de manera predeterminada la más antigua disponible.

Respuesta

La respuesta recibida de este extremo tiene el formato JSON y, si no hay problemas, tendrá el siguiente aspecto:

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

De no ser satisfactoria, recibirás un mensaje de error con una explicación.

Inspeccionar los tokens de acceso

Independientemente de que la app use o no los valores code o token como response_type del cuadro de diálogo de inicio de sesión, ya debería haber recibido un token de acceso. Puedes realizar verificaciones automáticas de estos tokens con el punto de conexión de la API Graph:

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

Este punto de conexión admite los siguientes parámetros:

La respuesta de la llamada a la API es una matriz JSON que contiene datos acerca del token 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 app a verificar que el token de acceso sea válido para la persona y la app. Para obtener una descripción completa de los otros campos, consulta la guía sobre tokens de acceso.

Verificar permisos

Es posible llamar al perímetro /me/permissions con el fin de recuperar una lista de permisos que otorgó o rechazó un usuario en particular. La app puede usarlo para verificar cuál de los permisos solicitados no puede usarse para algún usuario en particular.

Volver a solicitar permisos rechazados

El inicio de sesión con Facebook permite a las personas no conceder algunos permisos a la app. El cuadro de diálogo de inicio de sesión contiene una pantalla con este aspecto:

El permiso public_profile siempre es necesario y aparece atenuado, ya que no se puede desactivar.

Sin embargo, si alguien desmarca user_likes (Me gusta) en este ejemplo, al marcar /me/permissions para determinar qué permisos se concedieron se obtendrá el siguiente resultado:

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

Ten en cuenta que user_likes se rechazó en lugar de concederse.

Es aceptable pedir a una persona que conceda a la app permisos que ya rechazó. Muéstrale una pantalla informativa que explique por qué es importante que conceda el permiso y, después, vuelve a solicitarlo. Sin embargo, si invocas el cuadro de diálogo de inicio de sesión del mismo modo que antes, no 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 lo vuelve a solicitar a menos que se lo indiques explícitamente.

Para ello, puedes agregar el parámetro auth_type=rerequest a la URL del cuadro de diálogo de inicio de sesión:

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

Al usarlo, el cuadro de diálogo de inicio de sesión volverá a solicitar el permiso rechazado.

Almacenar los tokens de acceso y el estado del inicio de sesión

A esta altura del proceso, cuentas con una persona autenticada que inició sesión. La app está lista para realizar llamadas a la API en su nombre. Antes de hacerlo, debería almacenar el token de acceso y el estado de inicio de sesión de la persona que usa la app.

Almacenar tokens de acceso

Una vez que la app recibe el token de acceso del paso anterior, este se debe almacenar de modo que esté disponible para todas las partes de la aplicación al realizar llamadas a la API. No hay ningún proceso específico aquí. Sin embargo, por lo general, si creas una app web, es mejor agregar el token como variable de la sesión para identificar a una persona en particular con dicha sesión del navegador; si creas una app para computadoras o para celulares, deberías usar la base de datos disponible de la app. Asimismo, la app debería almacenar el token en una base de datos junto con el user_id para identificarla.

Consulta la nota sobre el tamaño de los tokens de acceso en el documento sobre estos tokens.

Hacer seguimiento del estado del inicio de sesión

Nuevamente, tu app debe almacenar el estado de inicio de sesión de una persona, pues esto ayuda a evitar tener que realizar llamadas adicionales al cuadro de diálogo de inicio de sesión. Sin importar el procedimiento que elijas, modifica la comprobación del estado de inicio de sesión para que se adapte a la selección.

Cerrar la sesión

Puedes cerrar la sesión de las personas de la app eliminando cualquier indicador de estado de inicio de sesión que hayas agregado, por ejemplo, eliminar la sesión que indica que una persona inició sesión. También deberías eliminar el token de acceso almacenado.

Cerrar la sesión de una persona no es lo mismo que revocar el permiso de inicio de sesión (eliminar una autenticación que se concedió con anterioridad), lo que puede hacerse de manera separada. En consecuencia, crea la app de forma tal que no fuerce de manera automática a las personas que cerraron sesión a volver al cuadro de diálogo de inicio de sesión.

Detectar cuando las personas desinstalan apps

Las personas pueden desinstalar las apps a través de Facebook.com sin necesidad de interactuar con la propia app. Para ayudar a que las apps detecten cuándo sucedió esto, les permitimos proporcionar una URL de devolución de llamada para autorizaciones canceladas, que enviará una notificación en el momento en que esto suceda.

Puedes activar una devolución de llamada a través del panel de apps.

Responder solicitudes para eliminar los datos de usuario

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