OAuth2.0 es un sistema de autorización de estándar abierto que se publicó en 2010, y corporaciones como Google y Twitter lo adoptaron rápidamente. Define cómo varios servicios pueden acceder de forma segura a los activos de datos (a través de la autenticación) sin revelar ninguna credencial. Esto a veces se denomina autorización delegada. Esto ayuda con la autorización de granularidad gruesa al proporcionar acceso limitado y regulado a ciertas API al crear aplicaciones. OAuth es particularmente ventajoso ya que se puede incluir de manera eficiente en las actividades de desaprovisionamiento de identidad, que ahora son un componente esencial de cada configuración B2B. Los flujos de OAuth son esencialmente métodos compatibles con OAuth para verificar los permisos y la información del propietario del recurso. Hay distintos protocolos para varios flujos de OAuth. Hay flujos de OAuth que permiten a los clientes proporcionar credenciales directamente a la aplicación a través de una pantalla de inicio de sesión de OAuth. Algunos marcos de back-end incluso ayudan a la validación sin la interacción del cliente. Antes de entrar en los muchos tipos de flujos de OAuth, repasemos los conceptos básicos. Fundamentos de OAuth El protocolo OAuth utiliza los siguientes roles: : esta entidad es la que otorga acceso al activo protegido. Por lo general, es el usuario. Propietario del recurso : el servidor de recursos es el servidor que contiene el recurso al que el propietario del recurso necesita acceder. Por lo general, expone una API y OAuth ayuda a otorgar acceso seguro a esta API. Servidor de recursos : esta es una aplicación que solicita acceso a recursos protegidos para el propietario del recurso que usa la aplicación. Cliente : este es el servidor a cargo de recopilar las credenciales del propietario del recurso y determinar si se le permite o no acceder a un recurso protegido. Si lo son, dan un token de acceso para permitir el acceso. Este es el motor principal que controla el flujo de OAuth. Servidor de autorización Tipos de flujo de OAuth Continuando, ¿qué tal si nos sumergimos en los tipos de flujo de OAuth que debe tener en cuenta antes de que comencemos a trabajar con su caso de uso específico? 1. Flujo de código de autorización En el flujo de código de autorización, debe transmitir el secreto de cliente de la aplicación que se intercambia por un código de autorización o token. Este flujo difiere de la mayoría de los otros flujos en que primero requiere una aplicación para iniciar el navegador para comenzar el flujo. Casos de uso Aplicaciones web y móviles del lado del servidor donde el código fuente no es público. ¿Cómo funciona este flujo de OAuth? La aplicación inicia un navegador y conecta al usuario con el servidor OAuth. El usuario ve la ventana emergente de autorización y da permiso a la solicitud de la aplicación. Se redirige al usuario a la aplicación con un código de autorización en la cadena de consulta. La aplicación cambia el código de autorización por un token de acceso. 2. Flujo de credenciales de clientes El flujo de credenciales de cliente permite que las aplicaciones pasen su secreto de cliente y su ID de cliente a un servidor de autorización para confirmar al usuario y devolver un token de autorización. Esto ocurre sin intervención del usuario. Casos de uso Aplicaciones de máquina a máquina (M2M) (como demonios, administraciones de back-end y CLI). En estas aplicaciones, el flujo de autorización confirma y otorga el consentimiento en segundo plano sin involucrar al usuario, porque el "usuario" es con frecuencia una tarea de máquina o administración. No parece apropiado mostrar un indicador de inicio de sesión o utilizar inicios de sesión sociales. ¿Cómo funciona este flujo de OAuth? La aplicación se autentica con el servidor de autorización de OAuth enviando el secreto del cliente y el ID del cliente. El servidor de autorización verifica el secreto del cliente y la identificación del cliente y devuelve un token de acceso a la aplicación. El token de acceso permite que la aplicación llegue a la API de destino con los detalles de usuario esperados. Flujo de contraseña del propietario del recurso En este flujo de OAuth, se solicita a los usuarios que envíen sus credenciales a través de un formulario, que luego se envía al backend y puede conservarse para uso futuro. Luego, se genera un token de acceso para el usuario. Por lo tanto, es importante que se pueda confiar completamente en la aplicación. Por lo tanto, este flujo generalmente no se recomienda. Casos de uso Aplicaciones de alta confianza, donde no se pueden utilizar otros flujos basados en redireccionamientos. ¿Cómo funciona este flujo de OAuth? El usuario hace clic en una opción de inicio de sesión en la aplicación e ingresa las credenciales en el formulario proporcionado por la aplicación. La aplicación almacena las credenciales y luego las pasa al servidor de autorización. El servidor de autorización valida las credenciales y luego devuelve un token de acceso (y una opción Refresh Token). Luego, la aplicación puede acceder a la API de destino con la información del usuario. Flujo implícito con publicación de formulario Este flujo utiliza OIDC (OpenID Connect) para realizar un inicio de sesión web con funciones como WS-FED (Web Services Federation) y SAML (Secure Assertion Markup language). OpenID Connect es una capa de identidad sencilla construida sobre el protocolo OAuth. Permite a los Clientes autenticar a los Usuarios de Identidad Final en función de la autenticación del Servidor de Autorización y acceder a la información de perfil básica sobre los Usuarios Finales de manera interoperable y similar a REST. OpenID Connect puede ser utilizado por clientes de varios tipos, incluidos clientes basados en web, móviles y JavaScript, para solicitar y recibir información sobre sesiones autenticadas y usuarios finales. El conjunto estándar es extensible, lo que permite a los participantes utilizar capacidades adicionales, como el cifrado de datos de identidad, el descubrimiento de proveedores de OpenID y cerrar sesión según sea necesario. La aplicación web utiliza el front-end para solicitar y recibir tokens sin necesidad de llamadas o secretos adicionales al back-end. No necesita usar, mantener, adquirir o asegurar secretos en su aplicación usando este enfoque. Casos de uso Aplicaciones que preferirían no gestionar los secretos localmente. Flujo híbrido Este método es útil para las aplicaciones que necesitan almacenar de forma segura los secretos de los clientes. Proporciona acceso instantáneo a un token de identificación al mismo tiempo que permite la recuperación continua de tokens de acceso y actualización adicionales. Esto es útil para las aplicaciones que requieren acceso inmediato a los datos del usuario, pero primero deben completar algún procesamiento antes de que se les conceda acceso a los recursos protegidos durante un período de tiempo prolongado. Casos de uso Aplicaciones que requieren un acceso rápido a los datos del usuario pero que también necesitan utilizar estos datos de forma continua. Flujo de autorización de dispositivos Puede usar este flujo para autenticar a los usuarios sin solicitar sus credenciales. Esto mejora la experiencia del usuario en dispositivos móviles, donde puede ser difícil ingresar las credenciales. Estas aplicaciones pueden iniciar el proceso de autorización y obtener un token proporcionando su ID de cliente al Flujo de autorización del dispositivo. Casos de uso Aplicaciones en línea que funcionan en dispositivos con restricciones de entrada y brindan autenticación sin fricciones usando credenciales guardadas en el dispositivo. Flujo de código de autorización con PKCE Cuando los clientes públicos (como las aplicaciones nativas y de una sola página) solicitan tokens de acceso, se producen varios problemas de seguridad adicionales que el flujo de código de autorización no puede gestionar por sí solo, incluidos los siguientes: Aplicaciones nativas Los secretos del cliente no se pueden almacenar de forma segura. La descompilación de la aplicación revela el secreto del cliente, que está vinculado a la aplicación y es el mismo para todos los usuarios y dispositivos. Se puede usar un esquema de URL personalizado (p. ej., MyApp://) para registrar la redirección, lo que posiblemente permita que las aplicaciones malintencionadas obtengan un código de autorización de su servidor de autorización. Aplicaciones de una sola página Los secretos de los clientes no se pueden almacenar de forma segura ya que el navegador tiene acceso a su fuente completa. Dadas estas circunstancias, OAuth 2.0 incluye una versión del flujo de código de autorización que emplea una clave de prueba para intercambio de código (PKCE). El flujo de código de autorización mejorado por PKCE proporciona un secreto producido por la aplicación que llama que puede ser confirmado por el servidor de autorización llamado . Además, la aplicación de la persona que llama genera un valor de transformación del verificador de código llamado y lo entrega a través de HTTPS para obtener un código de autorización. Un atacante malicioso solo puede interceptar el Código de autorización y cambiarlo por un token si el Verificador de código no está presente. Verificador de código Code Challenge Casos de uso Aplicaciones que deben servir a consumidores públicos desconocidos que pueden presentar riesgos de seguridad adicionales que el Auth Code Flow no maneja. Conclusión Como se habrá imaginado, los flujos de OAuth deben elegirse cuidadosamente para mejorar su caso de uso y abordar desafíos específicos. Por ejemplo, puede tener una sola aplicación que requiera tokens de acceso para muchos servidores de activos. Se requerirán varias llamadas para/aprobar. Los flujos de OAuth son un método para recibir tokens de acceso, y el flujo apropiado para su caso de uso se decide según el tipo de aplicación. Otras consideraciones a tener en cuenta son el nivel de confianza en la aplicación y la experiencia de usuario prevista. Hoy en día, tomar la decisión equivocada puede tener serias ramificaciones de seguridad y consistencia.
