Saltar al contenido

Por qué y cómo se usa OAuth en términos muy simples!

1 junio 2020

Cuando el usuario inicia sesión, las credenciales se envían y, si las credenciales coinciden correctamente, se almacena una sesión en el navegador como referencia. Piensa ¿En qué plataformas tienes que iniciar sesión? Facebook, Gmail, Twitter, Pinterest, tu suscripción a algún blog, netflix,etc…

El simple inicio de sesión que se muestra arriba no tiene nada que ver con cómo funciona OAuth, pero solo se hace mención para empezar el tuturial con una idea clara de con qué podemos comparar OAuth. Entonces es imporante saber cómo se usa OAuth.

La autorización delegada es dar permiso a las aplicaciones para acceder a los datos de los sistemas administrados por otra persona. ¡Implementar esto sin adquirir las credenciales de los usuarios es un problema y se conoce como el problema de autorización delegada!

Por ejemplo: Si  estás jugando en PUBG (que actualmente es un juego de tendencias), desea acceder a su lista de amigos y perfil de Facebook … ¿Confiarás en la aplicación y darás tus credenciales de Facebook sabiendo que la aplicación podrá hacer más que solo obtener la lista de amigos y el perfil? ¡Solo piensa en ello!

¿Qué es y cómo ayuda el OAuth?

OAuth (Open Authorization) es un estándar abierto para la autenticación y autorización basada en tokens en Internet. OAuth , permite que la información de la cuenta de un usuario final sea utilizada por servicios de terceros, como Facebook, sin exponer la contraseña del usuario.

Si busca OAuth en línea, lo que vería es que aparece OAuth2.0. Esto se debe a que OAuth 1.0 ahora está en desuso y rara vez se usa. Así que es sobre OAuth 2.0 lo que te debe interesar.

Protocolo OAuth 2.0

OAuth 2.0 está diseñado para fines de Autorización y no de Autenticación, por lo que es importante comprender la diferencia entre estos dos términos muy claramente.

Podrías buscar estos términos en Google y descubrir sus definiciones, pero después de leerlo, es posible que aún no tengas una idea clara. Entonces usaré este ejemplo para transmitir la idea:

¡Imagínese que está volando a París con su novia para unas vacaciones románticas! Cuando pase por el aeropuerto, los oficiales de seguridad / inmigración del aeropuerto verificarán su pasaporte y boleto para verificar si usted es la persona que dice ser (verifica su identidad). ¡Esto es autenticación!

Luego, cuando usted y su niña aborden el avión y si la tarjeta de embarque indica que usted es un pasajero de primera clase, los privilegios que obtendrá durante el vuelo serán más que un pasajero de clase económica. ¡Esto es autorización!

De manera inteligente, si consideramos una aplicación web real, el seguimiento de la identidad de la persona que usa la aplicación se maneja mediante autenticación y los privilegios que tiene la persona (por ejemplo: solo ver acceso ver y editar acceso ) se manejan por autorización.

Terminología OAuth 2.0

Estas terminologías son en su mayoría nombres dados a términos ya existentes, por lo que no es demasiado difícil de entender.

  • Propietario del recurso: el usuario de la aplicación, propietario de los datos que la aplicación desea obtener
  • Cliente: la aplicación
  • Servidor de autorización: sistema que se puede usar para solicitar y otorgar permisos
  • Servidor de recursos: el sistema que contiene los datos
  • Autorización: lo que prueba que el usuario ha dado permiso para acceder a los datos.
  • Redirigir Uri: el lugar al que se redirige al usuario cuando se le otorga permiso
  • Token de acceso: la clave utilizada para obtener los datos del servidor de recursos
  • Alcance: lo que define el nivel de permisos que tiene la aplicación para manipular los datos de los usuarios

OAuth flow

Si ha seguido la secuencia de pasos que se muestran a continuación (en cualquier aplicación móvil o web), donde otorga permiso para acceder a sus datos,  a través de los siguientes pasos:

Paso 1: iniciar el flujo

Cuando registre su aplicación en Facebook o en cualquier otro proveedor de OAuth2.0 , obtendrá una identificación de cliente y un secreto de cliente (el secreto de cliente debe almacenarse de forma segura y no ser objeto de injuria al público).

Cuando el usuario de PUBG hace clic en el botón ‘Iniciar sesión con Facebook ‘ en la aplicación, el usuario será redirigido a la página de inicio de sesión del proveedor OAuth2.0 (en este caso, la página de inicio de sesión de Facebook). Esto es posible mediante el envío de una solicitud HTTPS al punto final del servidor de autorización con el ID del cliente y algunos otros atributos como parámetros.

Paso 2: dar consentimiento

Después de que el usuario inicie sesión correctamente, se le pedirá al usuario que dé su consentimiento para permitir que PUBG acceda a los datos del usuario. (la lista de amigos y el perfil)

Paso 3: devolución de llamada

Si el usuario no da su consentimiento para acceder a sus datos, la devolución de llamada obligará a la app. a ser redirigida a la pantalla de inicio de sesión de la aplicación y el flujo finalizará.

Por otro lado, si el usuario da su consentimiento, la devolución de llamada dará el código de autorización para continuar el siguiente paso.

Paso 4: código de intercambio para un token de acceso

Una vez que obtenga el Código de autorización del paso anterior, puede enviarlo de vuelta al servidor de autorización y obtener el Token de acceso.

Paso 5: acceder a los datos

El token de acceso que se recibe se utiliza para obtener los datos necesarios para su aplicación, en el caso de PUBG, para acceder a la lista de amigos y al perfil de usuario

¿Por qué hay dos pasos para obtener el token de acceso (Primero obtener el código y luego enviar nuevamente el código para obtener el token de acceso)

Flujo de código de autorización (flujo del lado del servidor)

El flujo estándar.
Un usuario es redirigido al servidor de autorización (instancia de Drupal con oauth2_server instalado), donde inicia sesión y luego se le presenta un formulario de autorización (se omite si el cliente está configurado para hacerlo).
Una vez que se ha confirmado la autorización, el servidor de autorización vuelve a dirigir al cliente con un código de autorización.
Luego, el cliente realiza una solicitud de código de autorización con sus credenciales de cliente completas (clave de cliente y secreto de cliente), así como el código recibido, y se le
otorga un token de acceso (junto con su tiempo de vencimiento y un token de actualización).

Para mitigar posibles ataques CSRF, el módulo oauth2_server solicita que todas las solicitudes de autorización tengan un parámetro de estado, que el cliente verifica en redirect_url para asegurarse de que la solicitud realmente provenga del servidor. Si el estado no valida / coincide, el cliente DEBE descartar el token recibido.
Las pruebas de oauth2_server usan tokens drupal ( drupal_get_token / drupal_valid_token ) para generar valores basados ​​en la clave privada del sitio, pero se puede usar cualquier valor aleatorio.

Documentación adicional: https://labs.hybris.com/2012/06/01/oauth2-authorization-code-flow/

Flujo implícito (flujo del lado del cliente)

El flujo destinado a aplicaciones de JS puro. No se puede usar desde el interior de un lenguaje de servidor como PHP.
Un usuario es redirigido al servidor de autorización (instancia de Drupal con oauth2_server instalado), donde inicia sesión y luego se le presenta un formulario de autorización (se omite si el cliente está configurado para hacerlo).
Una vez que se ha confirmado la autorización, el servidor de autorización redirige al cliente con un token de acceso.
Como puede ver, la diferencia aquí es que no hay un código de autorización y una futura solicitud de concesión de código de autorización,
sino que se recibe inmediatamente un token de acceso.
Esto se debe a que para las aplicaciones JS una autorización_código no tiene sentido, ya que client_secret estaría expuesto al usuario.

El token de acceso se recibe en el redirect_url a través de una cadena de consulta «hash» especial,
que asegura que no se pase al lado del servidor (un script PHP no podría acceder a él).

Se describe un posible agujero de seguridad en: http://homakov.blogspot.com/2012/08/oauth2-one-accesstoken-to-rule-them-all.html
Si su servidor tiene varios clientes, una aplicación JS no puede sepa que el token que acaba de recibir se emitió para sí mismo y no para otro cliente (esta es la naturaleza problemática de los tokens de acceso ilimitados en OAuth2).
Por lo tanto, el token siempre debe considerarse inseguro, y el lado del servidor debe validarlo antes de usarlo para la autenticación haciendo una solicitud autorizada a oauth2 / tokens / $ yourtoken.
El punto final devuelve 404 si el token no se encontró o ha expirado.

Documentación adicional: https://labs.hybris.com/2012/06/05/oauth2-the-implicit-flow-aka-as-the-client-side-flow/

Una biblioteca JS útil para implementar el flujo implícito y hacer solicitudes después: https://github.com/andreassolberg/jso

Flujo de credenciales del cliente

No hay redireccionamiento al servidor, se realiza una solicitud POST directamente al punto final «oauth2 / token» con las credenciales del cliente
y se recibe un token de acceso. Consulte la descripción del tipo de concesión «Credenciales del cliente» para obtener más información.

Flujo de contraseña del propietario del recurso

No hay redireccionamiento al servidor, se realiza una solicitud POST directamente al punto final «oauth2 / token» con las credenciales de usuario
y se recibe un token de acceso. Consulte la descripción del tipo de concesión «Contraseña» para obtener más información.

Tipos de subvención

Los tipos de concesión son diferentes formas de otorgar un token de acceso basado en una solicitud POST al punto final «oauth2 / token».

  • Código de autorización
    Se utiliza para intercambiar un código de autorización para un token de acceso (y un token de actualización).Documentación adicional: https://labs.hybris.com/2012/06/01/oauth2-authorization-code-flow/
  • Token de actualización
    Se utiliza para intercambiar tokens de acceso vencidos por otros nuevos, con la ayuda de un token de actualización.Los tokens de acceso emitidos son por defecto de corta duración (caducan después de 1 hora).
    Por lo tanto, también se emite un token de actualización con una vida útil más larga (14 días), lo que
    permite a las aplicaciones intercambiar un token de acceso vencido por uno nuevo, sin rehacer la autorización.
    Si la configuración «always_issue_new_refresh_token» es verdadera, se emite un nuevo token de actualización cada vez
    que se utiliza uno existente . Esto permite que el cliente tenga siempre un token de actualización válido.
    De lo contrario, una vez que el token de actualización caduca, la autorización debe solicitarse nuevamente.Documentación adicional: https://labs.hybris.com/2012/06/05/oauth2-refreshing-an-expired-access-token/
  • Credenciales del cliente
    Se utilizan para autenticar al cliente (en lugar de solicitar la autorización del usuario).
    En este caso, los Servicios no saben quién es el usuario actual ($ user-> uid es 0).
    Usualmente se usa para tareas de administración específicas del cliente.Documentación adicional: https://labs.hybris.com/2012/07/09/oauth-the-client-credentials-flow/
  • Contraseña
    Se asemeja a un inicio de sesión de drupal. Acepta un nombre de usuario y contraseña, devuelve un token de acceso.
    Documentación adicional: https://labs.hybris.com/2012/06/11/oauth2-resource-owner-password-flow/

Consulte las pruebas del servidor OAuth2 para ver ejemplos de solicitudes que utilizan drupal_http_request ().