Header Ads Widget

Ticker

6/recent/ticker-posts

Flujo de token asistido: la respuesta a la integración de OAuth en aplicaciones de una sola página


 OAuth es un estándar de Internet increíblemente popular para otorgar acceso a aplicaciones y servicios web a la información disponible en otros sitios web. Aunque la implementación es compleja, la premisa es simple: le dices a un sitio web que deseas acceder a sus datos, inicias sesión con los detalles del usuario y listo, pero sin algún tipo de protocolo el proceso sería mucho más complicado. .

Existe un inconveniente en la versión principal actual de OAuth , y es cada vez más evidente con la tendencia reciente hacia la creación de aplicaciones de una sola página (SPA). El problema es que diseñar una solución de OAuth segura y sin problemas es difícil sin un backend que haga el trabajo pesado y, por definición, las aplicaciones de una sola página no tienen una ...

En este artículo, seguiremos al arquitecto de soluciones de Curity, Daniel Lindau , mientras presenta la solución para el uso de OAuth en aplicaciones de una sola página en nuestra Cumbre de API de Austin en Texas, 2018.

Flujo implícito: el status quo de OAuth en aplicaciones de una sola página

El método actual de elección para manejar la delegación de OAuth en aplicaciones de una sola página utiliza el flujo implícito, también conocido como flujo del lado del cliente .

Es simple, simplemente redirija el navegador al servidor de autorización , donde el usuario se autentica directamente y le da acceso a la aplicación, antes de regresar a la aplicación con un token de acceso incrustado en la URL. Luego, el servicio puede analizar la URL del token y comenzar a usarlo inmediatamente.

No hay duda de que este es un enfoque complicado. Los redireccionamientos son intrínsecamente contrarios a la intuición si el objetivo es crear una aplicación de una sola página . Además, debe diseñar una arquitectura en la que la aplicación pueda reanudar la ejecución sin problemas una vez que haya terminado con todos los redireccionamientos. Luego, está la cuestión de almacenar su precioso token de acceso de forma segura.

Daniel dice que Curity normalmente trabaja con desarrolladores que no están tan familiarizados con OAuth; no conocen exactamente las mejores prácticas para almacenar y usar estos tokens. Por tanto, es importante promover una alternativa más infalible.

El iFrame: un ataúd para su delegación de OAuth

Una solución obvia a todos los problemas causados ​​por un flujo implícito impulsado por redirecciones es ocultar su implementación de OAuth dentro de un iFrame , un marco en línea.

Exactamente como suena, guardar su OAuth en un iFrame es un poco como ponerlo en un ataúd. La razón es que un iFrame mantiene su flujo de OAuth y el resto de su aplicación separados, lo que puede dificultar la comunicación entre los dos.

Otro problema con el uso de iFrames, que los ataúdes no sufren exactamente, es que se puede acceder a ellos desde varios lugares . En aras de una autorización segura, probablemente deba diseñarlo de manera que solo se pueda acceder al marco desde la página activa.

Entonces, ¿cuál es la solución?

Lea también: Uso del flujo de dispositivos OAuth para dispositivos que no admiten la interfaz de usuario

Flujo de token asistido: integración de iFrame bien

Curity ha creado soluciones OAuth para las distintas necesidades y limitaciones de sus clientes de diversas formas. Si bien cada caso fue ligeramente diferente, un denominador común fue el uso de iFrames, pero se tomaron precauciones para evitar los problemas asociados.

La creación de integraciones de OAuth similares una y otra vez le dio al equipo una idea brillante: ¿por qué no estandarizar el proceso de delegación de OAuth dentro de un iFrame?

Así nació Assisted Token Flow . Es un borrador de especificación integrado en OAuth, lo que quiere decir que usa todo lo que es hoy OAuth, pero agrega nuevos flujos y puntos finales para facilitar el uso en aplicaciones de una sola página.

El protocolo utiliza iFrames para la comunicación entre la página principal y el servidor OAuth, lo que evita los molestos redireccionamientos que comentamos anteriormente, y la funcionalidad postMessage de JavaScript para la comunicación entre el marco en sí y la página principal.

Una adición muy bienvenida de nuevos puntos finales permitió a los desarrolladores eliminar parámetros OAuth innecesarios , agilizando todo el proceso de delegación. Esta es una característica importante, ya que hace que las interacciones página-iFrame sean mucho más fáciles de seguir.

El resultado es un flujo en el que solo el client_idparámetro debe comunicarse entre el iFrame, la página principal y el servidor de autorización; cualquier otro parámetro es opcional.

En el caso de que se utilicen otros parámetros, el protocolo Assisted Token Flow también ofrece validación de parámetros dentro de la implementación, en el lado del servidor OAuth, que reduce cualquier exceso de ida y vuelta entre la aplicación y el servidor de autorización.

Consulte también: ¿Por qué no puedo enviar JWT sin OAuth?

Subvenciones de tokens con flujo de tokens asistido

La belleza de usar un estándar para la integración de OAuth es que cada implementación usa el mismo flujo de trabajo, en este caso, con un diseño simple pero efectivo.

Veamos cómo se otorgan los tokens con Assisted Token Flow cuando el usuario ya está autenticado frente a cuando el usuario aún no se ha autenticado.

Flujo de token asistido para un usuario autenticado

Con Assisted Token Flow, el flujo de trabajo para un usuario ya autenticado es extremadamente sencillo:

  1. La aplicación requiere acceso a los datos en un servidor de recursos externo.
  2. La página abre un iFrame oculto y lo apunta al servidor OAuth con solo el client_idparámetro.
  3. El servidor OAuth envía una página HTML casi vacía al iFrame, que incluye un postMessagescript con el resultado de la transacción.
  4. La página se carga en el iFrame y postMessagese realiza, enviando un mensaje de éxito junto con el token de acceso a la página principal.

En comparación con el núcleo de OAuth , la principal ventaja aquí es que Assisted Token Flow no exige la inclusión de un parámetro de alcance (o cualquier otro parámetro más allá client_id, para el caso); si el cliente especifica ámbitos, el usuario los concede. Si el cliente no especifica un parámetro de alcance, se le pedirá al usuario que otorgue todos los alcances disponibles para el cliente.

Flujo de token asistido para un usuario desconocido

El flujo de token asistido para un usuario que aún no se ha autenticado es igualmente fácil, con algunos pasos adicionales:

  1. La aplicación requiere acceso a los datos en un servidor de recursos externo.
    La página abre un iFrame oculto y lo apunta al servidor de recursos con solo el client_idparámetro.
  2. El servidor OAuth envía una página HTML más detallada al iFrame, que incluye un postMessagescript que solicita a la página principal los detalles de inicio de sesión.
  3. El iFrame se hace visible para la autenticación del usuario  (por ejemplo, como un cuadro de diálogo de nombre de usuario / contraseña) y el usuario inicia sesión.
  4. Luego, la aplicación recupera los datos según sea necesario según los pasos para un usuario autenticado.

Nuevamente, Assisted Token Flow muestra el beneficio de no necesitar ningún parámetro adicional, mientras que también muestra cómo se puede hacer una integración OAuth simple cuando se cuida el aspecto iFrame.

Precauciones de seguridad en el flujo de tokens asistido

Como mencionamos anteriormente, existen pocas restricciones de seguridad evidentes al usar OAuth en aplicaciones de una sola página. Dos de los problemas más importantes son la seguridad del propio iFrame, así como el almacenamiento de tokens de acceso.

Estas son las precauciones que Assisted Token Flow ha tomado contra tales vulnerabilidades:

seguridad de iFrame

Existe un enfoque de doble cañón para mantener seguros los iFrames: para empezar, el cliente está registrado en el servidor OAuth en un dominio en particular (que se aplica con encabezados HTTP y políticas de seguridad de contenido) y, en segundo lugar, el dominio se especifica en el postMessagepara evitar el acceso externo al token.

Almacenamiento de tokens

En cuanto al almacenamiento de tokens, en realidad solo hay dos opciones:, localStoragecomo está escrito en JavaScript, o almacenamiento de cookies. Curity recomienda el almacenamiento de cookies , ya que permite que el token de acceso se almacene con un dominio, ruta y tiempo de caducidad, por lo que todas las interacciones con el punto final enviarán un token de acceso para que el servidor OAuth actúe.

Más consejos de OAuth: cómo manejar el procesamiento por lotes con OAuth 2.0

Conclusión: el flujo de tokens asistido facilita OAuth en aplicaciones de una sola página

Assisted Token Flow hace que OAuth sea fácil, especialmente para aquellos que han tenido problemas para encontrar una forma elegante pero segura de usarlo en aplicaciones de una sola página.

Se encarga de los iFrames y el almacenamiento de tokens, crea un punto final nuevo y ligero con un solo parámetro obligatorio e incluso valida los parámetros por usted. Lo mejor de todo es que la mayor parte de esto se logra del lado del servidor , por lo que el desarrollador no tiene que preocuparse por todos los aspectos básicos de su implementación.

El resultado es un protocolo OAuth que es mucho más fácil de usar, pero no sacrifica ninguna funcionalidad.

¿Y qué tan fácil es? Aquí hay una implementación de JQuery de 8 líneas donde Curity configura el origen y client_id , inicia la biblioteca y listo:

var settings = {
	clientId: "client-assisted-example",
	autoPrepareJqueryAjaxForOrigins: ['https://example.com'],
};

var assistant = curity.token.assistant(settings);

$(document).ready(function () {
	assistant.loginIfRequired();
});

 

Publicar un comentario

0 Comentarios