Header Ads Widget

Ticker

6/recent/ticker-posts

Uso del flujo de dispositivos de OAuth para dispositivos que no admiten la interfaz de usuario


A medida que Internet crece y más dispositivos se interconectan, la autorización se vuelve cada vez más compleja.

Las primeras implementaciones de servicios en línea eran fáciles de autorizar ya que estaban vinculadas a los escritorios, pero la autorización moderna debe considerar diferentes entornos, desde aplicaciones móviles hasta escenarios de IoT . Muchos de nuestros nuevos dispositivos, como televisores inteligentes y altavoces controlados por voz, no tienen interfaces de usuario tradicionales como los navegadores web.

La creciente prevalencia de dispositivos con restricciones de entrada conduce a un atolladero sobre cómo los proveedores deberían realmente autorizar estos dispositivos. ¿Cuál es una forma segura de ingresar el nombre de usuario y la contraseña en sistemas que no admiten IU ?

Hoy veremos de dónde proviene este problema y qué podemos hacer para solucionarlo. Cubriremos tres flujos de OAuth únicos para ver cómo resuelven el problema en cuestión: el flujo de credenciales de contraseña del propietario del recurso o ROPC , el flujo de código OAuth y el flujo del dispositivo OAuth . Veremos cuál es la forma más segura de incorporar identidad en estos nuevos entornos para garantizar que incluso los dispositivos de su sala de estar mantengan un alto nivel de seguridad.

Este artículo sigue a una presentación de Jacob Ideskog de Curity en la Cumbre de la Plataforma de APIs Nórdicas 2017 ( Diapositivas ):

Identificando el problema

Para llegar a la raíz del problema, tomemos un caso hipotético. Supongamos que queremos transmitir música a un televisor desde una fuente de datos. En este caso, desde un proveedor de transmisión de música, llamaremos a Musicbox . Musicbox requiere autorización para todas las sesiones de transmisión y, en nuestra situación hipotética, esto también se aplica a nuestro televisor.

Para que Musicbox se transmita en nuestro televisor, tenemos algunas opciones. Podemos usar una aplicación creada para este propósito específico; esto es común en muchos televisores inteligentes modernos y ofrece lo que es esencialmente una superposición de navegador web que maneja la autorización. Para hacer esto, usaríamos un tipo de flujo llamado Flujo de Credenciales de Contraseña del Propietario de Recursos (ROPC).

Flujo de OAuth de ROPC

Permitir que las aplicaciones cliente almacenen las credenciales de los usuarios localmente es un riesgo.

En este enfoque, el flujo de ROPC hace que el propietario del recurso emita una POSTsolicitud con un cuerpo codificado en la URL del formulario que contiene las credenciales del usuario al servidor OAuth . Este servidor se encuentra en el nivel de servicio de transmisión por secuencias y utiliza esta credencial para otorgar acceso a los sistemas internos. Esto se hace generando un token OAuth , que luego se devuelve al televisor y se transmite al servicio de transmisión por cada solicitud. Este es un flujo de OAuth muy tradicional, pero tiene algunos problemas importantes en nuestro caso de uso.

Primero, existe una gran preocupación por la seguridad . La mayoría de los proveedores de transmisión no querrán que un televisor que utilice bases de código y sistemas patentados tenga las credenciales de inicio de sesión para todos sus usuarios que elijan utilizar la aplicación. El tema de la confianza es especialmente relevante para las aplicaciones cliente creadas en la API del servicio de transmisión que son desarrolladas por terceros. Incluso si la aplicación es oficial, esto crea un punto importante de falla que expande drásticamente el vector de ataque en la propia API, y casi invita a sofisticados ataques de token.

Lea también: OAuth 2.0: por qué es vital para la seguridad de IoT

Sin embargo, lo que es más grave es el hecho de que el flujo ROPC simplemente nunca se diseñó para esta aplicación. Si bien parece un ajuste perfecto, el flujo de ROPC está diseñado para sistemas heredados ; utilizarlo para televisores inteligentes es una aplicación incorrecta y, en realidad, funciona en contra de OAuth. Como dice Jacob:

“El flujo de recursos no está realmente destinado a esto ... En realidad, está ahí para resolver problemas heredados . Si estamos construyendo un nuevo sistema, nunca deberíamos usarlo. Es por eso que tiene antipatrones integrados ".

Flujo de código OAuth

El propósito de OAuth es no dar contraseñas a terceros, lo que haría este procedimiento. Considere que ignoramos ROPC y optamos por un flujo de código OAuth más regular , donde el navegador se usa para enviar una GETsolicitud y una página de autorización se usa como aviso.

En este caso, todavía nos encontramos con un solo hecho que no podemos evitar: todo este flujo estaba destinado a dispositivos inteligentes más capaces que nuestro televisor restringido. El navegador sería terriblemente lento e ingresar un nombre de usuario y contraseña con un control remoto es ineficaz. Como tal, incluso si estas fueran soluciones aceptables, resultarían en malas experiencias para el usuario .

Una cuestión de experiencia de usuario

control remoto

Vaya, los controles remotos antiguos no funcionan bien con QWERTY.

Incluso si pudiéramos ignorar los problemas técnicos inherentes a este problema, el hecho es que el uso de las soluciones a menudo resulta en frustración debido a las limitaciones en la entrada y la interacción . Utilizar un pequeño control remoto para ingresar un complicado par de nombre de usuario / contraseña y lidiar con cualquier mensaje adicional que pueda aparecer es, en última instancia, bastante complicado.

Las cosas empeoran si no hay ningún controlador. Imagínese que, en lugar de nuestro televisor inteligente, estamos utilizando un altavoz como un altavoz inteligente Alexa . En este caso, ya no tenemos una pantalla o un modo de entrada fácil, y nuestro problema se vuelve mucho más complejo.

Entonces, ¿cuál es nuestra solución? Afortunadamente, se está estandarizando un nuevo flujo de OAuth que podría ayudar aquí. En lugar del flujo de recursos o el flujo de código, dirijamos nuestra atención al flujo de dispositivos OAuth.

Lea también: Cómo controlar la identidad del usuario dentro de microservicios

Flujo de dispositivos OAuth

OAuth reconoció el problema inherente a la autorización mediante el uso de dispositivos restringidos y redactó un nuevo estándar conocido como OAuth Device Flow. El estándar, actualmente en borrador como “ draft-ietf-oauth-device-flow – 06 ”, está diseñado específicamente para dispositivos que no admiten UI , como sistemas sin navegador y con restricciones de entrada . Por lo tanto, debería ser un buen método para dispositivos como nuestro televisor inteligente o nuestro sistema controlado por voz.

El flujo se parece a las soluciones tradicionales de OAuth, pero se rompe de manera significativa en una etapa muy clave.

En esta solución, tenemos una API, el servidor OAuth y el televisor que solicita el contenido. El televisor comienza enviando una solicitud de autorización de dispositivo, pasando con él el alcance y la identificación de cliente del dispositivo solicitante. Desde aquí, el servidor OAuth responde con un código de dispositivo, un código de usuario y un URI de verificación. Esto también tiene un temporizador de expiración y un intervalo que limita la posibilidad de explotación en dicha comunicación.

De aquí en adelante, el flujo de OAuth se rompe en una nueva forma. El usuario visita el URI de verificación, ingresa los datos solicitados (generalmente el código de usuario) y autoriza la función del dispositivo. Durante este tiempo, se le dice al servidor OAuth que espere al usuario y que espere el código de usuario. Se inicia una cuenta atrás que automáticamente revocará la validez del código pasado si se supera el tiempo, dando a los datos un tiempo de caducidad por seguridad.

Durante el tiempo que el usuario ingresa el código, el dispositivo sondea constantemente el servidor OAuth en un intervalo establecido, y una vez que el servidor OAuth recibe las credenciales, se responde a este sondeo con un token de autorización. Este token luego se transfiere del dispositivo a la API para transmitir contenido.

También hazaña. Jacob Ideskog: Cómo manejar el procesamiento por lotes con OAuth 2.0

¿Cómo es esto diferente?

"[Esta discusión trata] sobre cómo podemos trabajar con dispositivos que no son tan inteligentes como estamos acostumbrados ... Realmente se trata de llevar la identidad a una nueva caja en la que no habíamos pensado antes".

Este flujo es diferente en algunos aspectos bastante significativos. En primer lugar, está el hecho evidente de que la autorización de este tipo se produce fuera de la banda del dispositivo. El dispositivo en sí, en este caso el televisor, no es el sistema de credenciales fluido que acepta información de inicio de sesión: el usuario utiliza un sistema externo , como su teléfono, computadora portátil, computadora, etc., para verificar la solicitud y obtener acceso.

Esto también significa que el acceso no se limita a ingresar físicamente la información de inicio de sesión; los inicios de sesión pueden ocurrir usando NFC, bluetooth y biometría , y el código solicitado se puede proporcionar usando tantas soluciones. Esto está limitado, por supuesto, a los métodos cercanos: OAuth no permite que esto se expanda fuera del campo cercano, ya que permitir el acceso desde fuera del país o fuera de la ciudad podría resultar en un vector de ataque amplio.

Este flujo también permite que los tokens de actualización soliciten sin problemas una reautorización, lo que significa que los usuarios realizan una sola solicitud y luego vuelven a solicitar esta autorización automáticamente sin tener que ingresar sus credenciales. Esto hace que todo el proceso de autorización y usuario no solo sea técnicamente más seguro y efectivo, sino también mejor en términos de experiencia del usuario; esto, por supuesto, fue una preocupación importante para otros flujos de código y, como tal, representa un avance significativo.

Consulte también: Desacoplar la identidad de usuario del diseño de API para crear microservicios escalables

Una solución de brechas

Configurar la autorización para dispositivos con interfaces de usuario limitadas presenta un desafío de UX interesante. El problema no desaparecerá, y hasta que todos los dispositivos que utilizan un servicio estén limitados por la política o por la realidad para admitir interacciones avanzadas y paquetes de software, el problema solo empeorará.

En última instancia, utilizar OAuth Device Flow es la mejor solución actual que tenemos: el borrador de la solución es eficaz y ofrece una amplia gama de opciones de autorización. Como vimos en la charla de Jacob, es un enfoque estandarizado sobre cómo iniciar sesión en un dispositivo no compatible con UX.

Vivimos en un mundo de servicios inteligentes, pero los dispositivos que usamos para interactuar con ellos a menudo son bastante tontos. ¿Qué piensas? ¿Es esta la mejor solución para este problema? ¿Qué otras soluciones pueden salvar eficazmente la brecha entre el servicio inteligente y el cliente restringido? ¡Háganos saber a continuación!

Recursos

  • OAuth para tu sala de estar, Jacob Ideskog. (Diapositivas)
  • OAuth para tu sala de estar, Jacob Ideskog. (Presentación)
  • Borrador de IETF: flujo de dispositivos OAuth 2.0 para dispositivos sin navegador y con restricciones de entrada

 

Publicar un comentario

0 Comentarios