La especificación de OAuth 2.1 ha sido planificada. Exploremos las principales diferencias entre OAuth 2.0 y OAuth 2.1 y cómo se adoptaron en Logto.
Desde que OAuth 2.0 (RFC 6749) salió en 2012, el mundo de las aplicaciones web y móviles ha cambiado mucho. La gente se está trasladando de las computadoras de escritorio a los dispositivos móviles, y las aplicaciones de una sola página (SPAs) ahora están de moda. También hemos visto surgir un montón de nuevos frameworks y tecnologías web. Con todos estos cambios, los desafíos de seguridad también han aumentado. Para mantenerse al día con las últimas tecnologías web, se han lanzado continuamente nuevos RFCs como Proof Key for Code Exchange (PKCE) para mejorar OAuth 2.0. Se ha vuelto crucial agrupar todas las mejores prácticas para los requisitos de seguridad de hoy en día, y por eso viene OAuth 2.1.
En el próximo OAuth 2.1, el Grupo de Trabajo de OAuth tiene como objetivo consolidar todas las mejores prácticas y recomendaciones de seguridad en un único documento. En Logto, nos mantenemos en sintonía con los últimos estándares y mejores prácticas de OAuth. En este artículo, exploraremos las principales diferencias entre OAuth 2.0 y OAuth 2.1 y cómo se adoptaron en Logto.
Uno de los cambios más significativos en OAuth 2.1 es que Proof Key for Code Exchange (PKCE) ahora es obligatorio para todos los clientes OAuth que utilizan el flujo de Código de Autorización. PKCE es una extensión de seguridad que previene los ataques de interceptación de códigos de autorización. Es especialmente útil para aplicaciones móviles y de una sola página (SPAs) donde el secreto del cliente no puede ser almacenado de manera segura.
Los clientes de OAuth se pueden clasificar en dos tipos diferentes según su capacidad de almacenar secretos de manera segura:
Clientes confidenciales: Estos clientes pueden almacenar secretos de manera segura, como las aplicaciones web renderizadas en el servidor y los servidores web. Todas las solicitudes relacionadas con la autorización se realizan desde el lado del servidor, y el riesgo de exponer el secreto del cliente es bajo.
Clientes públicos: Estos clientes no pueden almacenar secretos de manera segura, como las aplicaciones móviles y las SPAs. El secreto del cliente se puede extraer fácilmente del código del lado del cliente, y es difícil protegerlo de los atacantes.
Para los clientes públicos, PKCE es una medida de seguridad indispensable. Garantiza que el código de autorización solo puede ser intercambiado por el cliente que inició la solicitud de autorización.
PKCE funciona generando un verificador de código aleatorio y un desafío de código basado en el verificador de código. El verificador de código se envía al servidor de autorización, y el desafío de código se utiliza para verificar el verificador de código cuando se intercambia el código de autorización por un token de acceso.
En OAuth 2.1, PKCE se vuelve obligatorio para todos los clientes OAuth que emplean el flujo de Código de Autorización, independientemente de su estado de confidencialidad, ya sean confidenciales o públicos. Este ajuste fundamental asegura una protección universal contra posibles ataques de interceptación de códigos de autorización.
En Logto, el flujo de validación de PKCE se activa automáticamente tanto para clientes públicos como confidenciales.
Para las SPAs y aplicaciones móviles, PKCE es una medida de seguridad indispensable para proteger el flujo de código de autorización en Logto. Cualquier solicitud de autorización que carezca de un desafío de código será rechazada de inmediato por el servidor de autorización de Logto.
Con respecto a los clientes confidenciales (aplicaciones web tradicionales), para una mayor compatibilidad con sistemas heredados, Logto sigue permitiendo la omisión del desafío de código en la solicitud de autorización. Sin embargo, recomendamos encarecidamente a los clientes confidenciales que adopten PKCE incorporando el desafío de código en la solicitud de autorización, siguiendo las prácticas de los clientes públicos.
Un URI de redirección (Identificador Uniforme de Recursos) es un endpoint o URL específico al cual el servidor de autorización redirige al usuario después del proceso de autenticación y autorización.
Durante el flujo de OAuth, la aplicación cliente incluye un URI de redirección como parte de la solicitud de autorización inicial. Una vez que el usuario completa el proceso de autenticación, el servidor de autorización genera una respuesta que incluye un Código de Autorización y redirige al usuario de vuelta al URI de redirección especificado. Cualquier desviación del URI de redirección original resultará en una filtración de código o token.
La coincidencia exacta de la cadena de los URIs de redirección se introdujo por primera vez en la sección 4.1 de OAuth 2.0 Security Best Current Practices. Esta práctica asegura que el URI de redirección debe coincidir exactamente con el registrado en el servidor de autorización. Cualquier desviación del URI de redirección registrado resultará en una respuesta de error.
Hemos recibido numerosas solicitudes de la comunidad con respecto a la implementación de coincidencias de comodines para los URIs de redirección. Aunque las coincidencias de comodines pueden ofrecer conveniencia a los desarrolladores que gestionan múltiples subdominios o rutas, particularmente con un gran número de subdominios aleatorios, también introduce riesgos de seguridad como ataques de redirección abierta. Para una ilustración práctica de los peligros que suponen la falta de validación del URI de redirección, consulta nuestra publicación en el blog Un resumen rápido sobre la seguridad en OAuth.
En consonancia con los estrictos estándares de seguridad de OAuth 2.1, Logto utiliza la coincidencia exacta de cadenas de los URIs de redirección. Esta decisión prioriza la seguridad del flujo de OAuth. En lugar de utilizar coincidencias de comodines, alentamos a los desarrolladores a registrar todos los URIs de redirección potenciales con el servidor de autorización de Logto. Esto asegura una validación exhaustiva de los URIs de redirección y ayuda a mitigar posibles vulnerabilidades de seguridad.
El flujo de concesión implícita en OAuth 2.0 se diseñó para SPAs donde el token de acceso se devuelve directamente en el fragmento de la URL después de que el usuario se autentica. Este método era conveniente porque evitaba un paso adicional de intercambio de tokens, permitiendo que el cliente recibiera el token directamente.
Sin embargo, esta conveniencia tiene sus desventajas. El token de acceso puede exponerse a partes no autorizadas a través del historial del navegador, encabezados de referencia u otros medios, lo que facilita la ocurrencia de brechas de seguridad, especialmente cuando los tokens de acceso siguen siendo válidos por períodos prolongados. Por ejemplo, si una solicitud de autorización es interceptada por una parte maliciosa, esta puede fácilmente extraer el token de acceso del fragmento de la URL e hacerse pasar por el usuario.
En el OAuth 2.0 Security Best Current Practices, se establece claramente que:
Los clientes NO DEBEN usar la concesión implícita (tipo de respuesta "token") u otros tipos de respuesta que emitan tokens de acceso en la respuesta de autorización.
Por lo tanto, el flujo implícito ha sido oficialmente eliminado de la especificación de OAuth 2.1.
En Logto, el flujo de código de autorización con PKCE es el único flujo compatible para las SPAs y las aplicaciones móviles. El flujo de código de autorización proporciona una forma más segura de obtener tokens de acceso al intercambiar el código de autorización.
La concesión de credenciales del propietario de los recursos (ROPC) permite que el cliente intercambie el nombre de usuario y la contraseña del usuario por un token de acceso. Se introdujo por primera vez en la especificación de OAuth 2.0 como una manera de apoyar aplicaciones heredadas como la autenticación básica HTTP o aplicaciones nativas heredadas que no podían usar los flujos de tokens de OAuth más seguros.
El tipo de concesión ROPC se ha marcado como no recomendado en la especificación de OAuth 2.0 debido a sus riesgos de seguridad. Las credenciales del usuario se exponen a la aplicación cliente, lo que puede llevar a posibles brechas de seguridad. La aplicación cliente puede almacenar las credenciales del usuario, y si el cliente es comprometido, las credenciales del usuario pueden ser expuestas a los atacantes.
Más adelante, en la sección 2.4 de las OAuth 2.0 Security Best Current Practices, se enfatizó aún más la prohibición del tipo de concesión ROPC como NO DEBE ser usado. Como resultado, el tipo de concesión ROPC ha sido eliminado de la especificación de OAuth 2.1.
Debido a los altos riesgos de seguridad asociados con el tipo de concesión ROPC, Logto nunca lo ha soportado. Si aún estás utilizando el flujo directo de credenciales de usuario en tus aplicaciones heredadas, recomendamos encarecidamente migrar a un método más seguro, como el flujo de código de autorización o la concesión de credenciales de cliente. Logto ofrece varios SDK y tutoriales para ayudarte a integrar estos flujos de OAuth seguros en tus aplicaciones sin esfuerzo.
Entendemos que los desarrolladores pueden querer diseñar u hospedar su propia interfaz de inicio de sesión de usuario para ofrecer la mejor experiencia de producto. En Logto, ofrecemos una gama de opciones de personalización de la experiencia de inicio de sesión (SIE), incluyendo configuraciones de marca y CSS personalizado. Además, tenemos varios proyectos en curso, como la función de traer tu propia interfaz de usuario y el inicio de sesión directo, para ofrecer más flexibilidad a los desarrolladores de integrar su propia interfaz de inicio de sesión mientras se mantiene la seguridad del flujo de OAuth.
OAuth 2.1 es la última actualización del protocolo OAuth, orientada a abordar los desafíos de seguridad actuales mientras se adaptan a las necesidades modernas de aplicaciones web y móviles. El grupo de trabajo de OAuth está actualizando y refinando activamente OAuth 2.1 para garantizar que cumpla con los últimos estándares de seguridad y mejores prácticas. El último borrador, OAuth 2.1 11, se lanzó en mayo de 2024, marcando un progreso significativo hacia su finalización. Con la amplia adopción en el horizonte, recomendamos encarecidamente que todos sigan las mejores prácticas descritas en OAuth 2.1 para mejorar la seguridad y mejorar la experiencia del usuario.