Encabezado de la serie de blogs de productos de seguridad de identidad de Okta

 

La autenticación con dispositivos compartidos presenta una serie de desafíos únicos. Algunos escenarios son específicos para la fuerza laboral de una organización, mientras que algunos casos de uso son específicos para el consumidor. En este artículo, me centraré en los escenarios del consumidor y exploraré los desafíos y las posibles opciones para abordar la autenticación de dispositivos compartidos de forma segura.

Oficina del Field CTO

Desafíos con la autenticación de dispositivos compartidos

Muchas organizaciones y servicios emplean quioscos y dispositivos compartidos para mejorar la experiencia del cliente, la eficiencia operativa a través del autoservicio y la escalabilidad con el crecimiento del consumidor. Algunos ejemplos notables son los quioscos implementados en los sistemas de punto de venta (POS) minoristas, centros de entretenimiento y eventos, hoteles, aeropuertos, bibliotecas y clínicas médicas.

En el escenario del consumidor, los principales desafíos son:

  • El usuario necesita proporcionar sus credenciales de autenticación en un dispositivo público. Esto aumenta el riesgo de exposición de credenciales y puede perjudicar la adopción por parte del consumidor.
  • La sesión del usuario puede permanecer activa después de que se aleja del sistema sin cerrar sesión explícitamente, lo que genera el riesgo de apropiación de la sesión.
  • La aplicación de la autenticación biométrica resistente al phishing, como las passkeys, no es factible.

Las aplicaciones a menudo manejan la autenticación de dispositivos compartidos de una manera bastante propietaria, como el uso de lectores RFID, documentos oficiales o escáneres de tarjetas de pago. Además, muchos sistemas solicitan la autenticación tradicional de ID de usuario y contraseña, como las computadoras en una biblioteca.

Autenticación desacoplada con el dispositivo compartido

Una mejor manera podría ser desacoplar la autenticación de la aplicación que se ejecuta en el dispositivo compartido. Si la autenticación se puede llevar a cabo utilizando un dispositivo de confianza, a menudo un smartphone o una tableta en posesión del usuario, algunos de los retos pueden abordarse sin problemas. Ejemplos de esos desafíos incluyen:

  • El usuario nunca necesita proporcionar credenciales o información de identificación a la aplicación que se ejecuta en los dispositivos compartidos.
  • La autenticación biométrica a prueba de phishing se puede usar fácilmente ya que el usuario se autentica desde un dispositivo personal.

Veamos un estándar de autenticación desacoplado prometedor: OAuth 2.0 Device Authorization Grant

Presentamos el flujo de autorización de dispositivo.

El flujo de autorización de dispositivos se concibió originalmente para proporcionar autenticación desacoplada a dispositivos con restricciones de entrada, como televisores inteligentes. A menudo, dichos dispositivos no vienen con un navegador de propósito general para permitir que un usuario se autentique utilizando un flujo federado seguro, o hacen que sea engorroso ingresar sus credenciales. El marco de autorización de dispositivos proporciona una forma de permitir que un consumidor use su dispositivo personal (computadora portátil, móvil o tableta) para realizar la autenticación en su lugar.   

Argumentando a favor del flujo de autorización del dispositivo

El flujo de autorización de dispositivos proporciona una solución elegante en el escenario de autenticación de dispositivos compartidos. La idea es la siguiente:

  • La aplicación crea una URL de inicio de sesión aleatoria y un código de usuario. También puede incrustar la URL y el código de usuario en un código QR. La aplicación luego muestra la información al usuario.
  • El usuario puede escanear el código QR o escribir manualmente el enlace de inicio de sesión en el navegador de su dispositivo.
  • Luego, completarían el flujo de autenticación en su dispositivo proporcionando sus credenciales. Para las aplicaciones confidenciales, el proceso de autenticación puede incluir factores resistentes al phishing como las claves de acceso.
  • Finalmente, ingresan el código de usuario.
  • Una vez que se completa el proceso de autorización, la aplicación del dispositivo compartido continuará con el token de autenticación recibido. 

El usuario nunca necesita proporcionar ninguna información de autenticación en el dispositivo compartido. En lugar de dar su consentimiento a un desafío de autorización (como con CIBA), realiza la autenticación de extremo a extremo en el dispositivo de confianza. 

El flujo de autorización del dispositivo se diseñó originalmente para dispositivos con restricciones de entrada, como televisores o interfaces de línea de comandos (CLI). Sin embargo, en los dispositivos compartidos, las credenciales del usuario no son seguras, lo que hace que el flujo sea un candidato ideal para la autenticación de dispositivos compartidos.

Así es como funciona el flujo de autorización de dispositivo OAuth 2.0:

 

Gráfico que muestra el flujo de autorización de dispositivo OAuth 2.0

 

Gestión de sesiones y cierre de sesión

Incluso si el flujo de autorización del dispositivo es adecuado para la autenticación de primera línea en dispositivos compartidos, la aplicación o el sistema aún necesita administrar las sesiones y los tokens. 

Los tokens deben tener un tiempo de vencimiento bajo y nunca almacenarse en almacenamiento persistente, a diferencia de los de los televisores o dispositivos inteligentes, donde normalmente se garantizan tokens de larga duración.

La aplicación también debe restablecer la sesión y borrar el token de acceso y el código del dispositivo inmediatamente después de que se cierre el navegador o la aplicación. 

La aplicación o el dispositivo debe rastrear la inactividad del usuario y agotarse dentro de un umbral corto. Al agotarse el tiempo, debe restablecer inmediatamente la sesión del usuario y borrar los tokens.

Opción de respaldo

¿Qué sucede si el usuario no lleva consigo un dispositivo personal adecuado para la autenticación? La aplicación también debe tener una opción de inicio de sesión de respaldo adecuada, como SMS o correo electrónico, y autenticación sin contraseña basada en OTP. Para que sea completa, la aplicación también puede permitir el inicio de sesión tradicional basado en contraseña, aunque con precaución y mensajes instructivos que se muestran al usuario.

Okta admite el flujo de autorización de dispositivos

Okta continúa liderando el espacio de Identity and Access Management al brindar soporte para el Device Authorization Grant Flow, una especificación de OAuth 2.0 (RFC 8628). 

Junto con la capacidad de Okta de admitir varios otros métodos de autenticación con y sin contraseña, puede implementar fácilmente un sistema de autenticación confiable para las aplicaciones que se ejecutan en un dispositivo compartido. El flujo de autorización del dispositivo ayuda a mejorar la experiencia del usuario y mejora significativamente la seguridad al desacoplar la autenticación del propio dispositivo compartido. Al ofrecer un proceso de integración optimizado a través de API y SDK, Okta facilita el aprovechamiento de este protocolo moderno. A medida que las empresas dependen cada vez más de los dispositivos no supervisados para las interacciones con los clientes, el enfoque pionero de Okta garantiza una experiencia de autenticación segura y sin fricciones para los consumidores.

El flujo de autorización de dispositivos, aunque originalmente se concibió para abordar la autenticación para dispositivos con restricciones de entrada, es una excelente herramienta para manejar la autenticación del consumidor desde dispositivos compartidos. Okta facilita la implementación de la autenticación de dispositivos compartidos de forma segura con soporte listo para usar para el flujo de autorización de dispositivos.

Lecturas adicionales

​​¿Qué es el flujo de autorización del dispositivo?

OAuth 2.0 Device Authorization Grant Specification

Okta Device Authorization Flow

Todos ganan con el flujo de dispositivos

Continúe con su recorrido de identidad