page - generar token facebook

Facebook OAuth 2.0 "código" y "token" (9)

Básicamente, como una extensión de la respuesta de Lix , la ruta del código de acceso permite a un propietario del recurso (es decir, el usuario de Facebook) revocar la autorización para su agente de usuario (es decir, su navegador), por ejemplo, al cerrar sesión sin revocar la autorización de un cliente fuera de línea (es decir Su aplicación). Si esto no es importante, entonces no hay necesidad de usar la ruta del código de acceso.

Además, el código de acceso se proporciona para garantizar que el token proporcionado a un servidor esté realmente registrado para el propietario del recurso (es decir, el usuario de Facebook) y no para el agente de usuario (o un intermediario).

Esto parece similar a la cuestión de elegir el flujo de concesión de código de autorización implícito frente a. De hecho, esto es lo que parece un punto de vista opuesto ?! .

Además, como Drew mencionó ,

Cuando el token de acceso caduque, los intentos de usarlo fallarán y se deberá obtener un nuevo token de acceso mediante un token de actualización.

Otra pieza es el token de actualización, pero no veo que se explique demasiado bien en los documentos de FB. Si estoy en lo cierto, el subsidio implícito (el token directo) debería ser muy efímero, pero eso está por hacerse cumplir y FB.js parece ocultar mucho de eso (este no lo he buscado tan profundamente) .

Si estoy en lo correcto, el code%20token es una optimización que permite que el Agente de usuario tenga un token y permite que el servidor inicie el proceso de intercambio de tokens en una sola solicitud (ya que todo lo que se considera sobre Red IO es caro, especialmente para un Agente de usuario).

¿Por qué necesita un "código" y un "token" en el flujo de autenticación de Facebook OAuth2 como se describe aquí: https://developers.facebook.com/docs/authentication/ ?

Si mira la referencia del diálogo OAuth ( https://developers.facebook.com/docs/reference/dialogs/oauth/ ), parece que solo usa el token para obtener información sobre el usuario, y si especifica el response_type parámetro response_type como token o code,token , luego obtienes el token la primera vez.

¿Por qué necesita obtener un "código" y luego usar el código para obtener un "token" en lugar de obtener el token directamente?

Supongo que estoy malinterpretando algo básico sobre cómo funciona OAuth, pero parece que evitas por completo la solicitud de https://graph.facebook.com/oauth/access_token si obtienes el token la primera vez con el cuadro de diálogo.

De la especificación OAuth 2.0 :

El código de autorización proporciona algunos beneficios de seguridad importantes, como la capacidad de autenticar al cliente y la transmisión del token de acceso directamente al cliente sin pasarlo a través del agente de usuario del propietario del recurso, exponiéndolo potencialmente a otros, incluido el propietario del recurso. .

Entonces, básicamente, la razón principal es limitar el número de actores que obtienen el token de acceso.

La respuesta "token" está destinada principalmente a clientes que viven en el navegador (por ejemplo, cliente de JavaScript).

La confusión surgió porque el usuario en nombre propio y no la aplicación cliente se autentica en contra del servidor de autorizaciones (es decir, Facebook). Es muy fácil de asegurar la aplicación del cliente (con https) y luego el usuario-agente (navegador).

Aquí está la formulación original de IETF-oauth ( tools.ietf.org/html/… ):

3.4. Código de Autorización

Un código de autorización representa el resultado intermedio de un proceso de autorización de usuario final exitoso y lo utiliza el cliente para obtener acceso y token de actualización. Los códigos de autorización se envían al URI de redirección del cliente en lugar de tokens para dos propósitos.

Los flujos basados en navegador exponen parámetros de protocolo a atacantes potenciales a través de los parámetros de consulta de URI (referencia de HTTP), la memoria caché del navegador o las entradas del archivo de registro y pueden reproducirse. Para reducir esta amenaza, se pasan códigos de autorización de corta duración en lugar de tokens y se intercambian por tokens a través de una conexión directa más segura entre el cliente y el servidor de autorización.
Es mucho más simple autenticar clientes durante la solicitud directa entre el cliente y el servidor de autorización que en el contexto de la solicitud de autorización indirecta. Esto último requeriría firmas digitales.

Préstamo descarado de la documentación de Salesforce :

Código de Autorización

Un código de autorización es un token de corta vida que representa la concesión de acceso del usuario, creado por el servidor de autorización y pasado a la aplicación del cliente a través del navegador. La aplicación cliente envía el código de autorización al servidor de autorización para obtener un token de acceso y, opcionalmente, un token de actualización.

Token de acceso El token de acceso es utilizado por el cliente para realizar solicitudes autenticadas en nombre del usuario final. Tiene una vida útil más larga que el código de autorización, generalmente del orden de minutos u horas. Cuando el token de acceso caduque, los intentos de usarlo fallarán y se deberá obtener un nuevo token de acceso mediante un token de actualización.

Recibe un token cuando el usuario inicia sesión. Pero es posible que desee cambiar el token cuando realice otras acciones. Publicación EG como su aplicación / página o publicación como usuario con offline_access .

Respuesta) Necesita / desea tanto el código como el token para mayor seguridad.

Según Nate Barbettini, queremos el paso adicional de cambiar el código de autenticación para el token de acceso, porque el código de autenticación se puede usar en el canal frontal (menos seguro) y el token de acceso se puede usar en el canal posterior (más seguro) .

Por lo tanto, el beneficio de seguridad es que el token de acceso no está expuesto al navegador y, por lo tanto, no puede ser interceptado / capturado desde un navegador. Confiamos más en el servidor web, que se comunica a través de canales secundarios. El token de acceso, que es secreto, puede permanecer en el servidor web y no estar expuesto al navegador (es decir, a los canales frontales).

Para más información, mira este fantástico video:

OAuth 2.0 y OpenID Connect (en inglés sencillo) https://youtu.be/996OiexHze0?t=26m30s (Comenzar 26 minutos)

Se debe a que el token de acceso se otorga a un cliente AUTENTICADO (aplicación de terceros) que utiliza un secreto compartido que solo FB y el cliente conocen. La única forma en que el usuario puede solicitar directamente el token de acceso es conociendo el secreto compartido, que haría público el secreto y podría conducir a un ataque de hombre en el medio. Además, aunque FB puede garantizar una conexión segura con el usuario, FB no puede garantizar que la entrega del token al cliente sea segura. Sin embargo, FB (y OAuth2) requieren una conexión segura entre el cliente y FB. El token de acceso está vinculado al ID público del cliente (generalmente hash), lo que significa que solo la aplicación cliente original puede usarlo para solicitar el token porque el secreto se envía junto con el código de autorización para obtener el token de acceso.

Si observa el flujo del tipo de código de autorización OAuth , sí, hay dos pasos actuarios:

1. <user_session_id, client_id> => authorization_code 2. <client_id, redirect_uri, authorization_code, client_secret> => access_token, refresh_token

En el paso 1: el usuario le dice al Servidor OAuth que "Quiero autenticar este cliet (id_cliente) para acceder a mi recurso. Aquí está mi autenticación (user_session_id o qué más)"

En el paso 2: el cliente (client_id) le dice al servidor OAuth que "Tengo la autorización de usuario (authorization_code), por favor dame un token de acceso para acceso posterior. Y esta es mi autenticación (client_id y client_secret)"

Verá, si omitimos el paso 2, entonces no hay garantía para la autenticación del cliente. Cualquier cliente puede invocar el paso 1 con un client_id diferente y obtener un token de acceso para ese client_id en lugar del propio. Es por eso que necesitamos step2.

Si realmente desea combinar los pasos 1 y 2, puede hacer algo como esto:

<client_id, redirect_uri, client_secret> => access_token, refresh_token

Utilizamos este enfoque en nuestra Plataforma Open Api, y todavía no hemos encontrado ningún problema de seguridad.

Por cierto, en realidad existe un tipo de concesión implícita , es decir:

<client_id, redirect_uri> => access_token, refresh_token

En general, se aplica a la aplicación solo para el cliente que no tiene servidor back-end. En ese caso, el servidor OAuth debe asegurarse de que el URI de redirección pertenezca a ese cliente (lo mismo con el registro redirect_uri, por ejemplo)

Tomemos un ejemplo simple para diferenciar el código de autenticación frente al token de acceso.

Usted como usuario desea probar una nueva aplicación de Facebook llamada Highjack. Entonces haces clic en la aplicación y la aplicación Highjack. le pide que inicie sesión en su cuenta de Facebook. Cuando hayas terminado, Facebook genera un código de autenticación para ti.

Este código luego se pasa al servidor Highjack que usa su propia identificación de cliente FB, FB secret y su código de autenticación para obtener un token de acceso.

En el ejemplo anterior, el código de autenticación lo confirma porque un usuario es un usuario de FB válido. Pero el segundo paso dice "usted como usuario de FB está dando acceso a la aplicación Highjack para ciertos recursos".

Si la aplicación Highjack quería una concesión implícita (es decir, un token de acceso directo), el token de acceso también sería visible para usted desde que se intercambiara con el navegador. Esto significa que ahora puede llamar a todas las API de Facebook en nombre de Highjack utilizando el token de acceso. (Solo puede usar el token de acceso para obtener su información personal, pero Facebook no tiene forma de saber quién llama a sus API).

Como tenemos 2 partes (You y Highjack) que se autentican con Facebook, tenemos este mecanismo doble.