Español

oauth
flujo implícito
código de autorización
PKCE

Flujo implícito vs. Flujo de código de autorización: ¿Por qué el flujo implícito está muerto?

¿Por qué existe un "flujo de código de autorización" en OAuth 2.0 cuando ya tenemos el "flujo implícito"? Vamos a profundizar en los detalles de estos dos tipos de concesión y descubrir por qué debes evitar usar el flujo implícito.

Darcy Ye

Developer

1/3/2024

Deja de perder semanas en la autenticación de usuarios

Lanza aplicaciones seguras más rápido con Logto. Integra la autenticación de usuarios en minutos y concéntrate en tu producto principal.

Comenzar

El flujo de código de autorización y el flujo implícito son dos de los tipos de concesión más comúnmente utilizados en OAuth 2.0, permitiendo una autorización de usuario segura y eficiente para aplicaciones web. Ambos flujos implementan un proceso de autorización que permite a los usuarios conceder acceso a las aplicaciones sin exponer sus credenciales directamente. El flujo implícito se desarrolló inicialmente para abordar las limitaciones del navegador, pero con la llegada de las tecnologías web modernas, el flujo de código de autorización se ha convertido en la elección preferida para muchos desarrolladores debido a sus características de seguridad mejoradas.

En este artículo, exploraremos las diferencias entre estos dos tipos de concesión y explicaremos por qué debes evitar usar el flujo implícito en favor del flujo de código de autorización.

¿Qué es OAuth 2.0?

Antes de profundizar en los detalles de estos dos tipos de concesión, primero entendamos qué es OAuth 2.0 y por qué es esencial para las aplicaciones web modernas.

Cuando la gente habla de OAuth, usualmente nos referimos a OAuth 2.0, conocido como "Autorización Abierta", es un protocolo establecido que permite a los sitios web o aplicaciones utilizar recursos de otros servicios web en nombre de un usuario. Sucedió a OAuth 1.0 en 2012 y desde entonces se ha convertido en el estándar ampliamente aceptado para la autorización digital. OAuth 2.0 está diseñado para proporcionar acceso controlado a los usuarios, permitiendo a las aplicaciones cliente permisos específicos para interactuar con recursos que representan al usuario, todo sin revelar los detalles de inicio de sesión del usuario.

Aunque se utiliza principalmente en entornos web, el marco de OAuth 2.0 también se extiende a diversas formas de clientes. Esto incluye aplicaciones basadas en navegador, aplicaciones web del lado del servidor, aplicaciones nativas o móviles e incluso dispositivos interconectados, detallando el enfoque para gestionar el acceso delegado en estas plataformas. Introduce el concepto de "tipos de concesión" para definir el proceso de autorización entre la aplicación cliente, el usuario y el servidor de autorización. Estos tipos de concesión se utilizan para determinar cómo la aplicación cliente puede obtener un token de acceso para acceder a los recursos del usuario. Los tipos de concesión más comunes en OAuth 2.0 son:

Código de autorización: Ideal para todos los tipos de aplicaciones, especialmente aplicaciones web del lado del servidor, donde la aplicación cliente puede intercambiar un código de autorización por un token de acceso y gestionar los tokens de forma segura.
Implícito: Un flujo simplificado, diseñado para aplicaciones basadas en navegador, sin un componente de servidor seguro. Fue creado para entregar rápidamente tokens a las aplicaciones clientes. Pero ahora está en gran medida obsoleto debido a preocupaciones de seguridad.
Credenciales de contraseña del propietario del recurso: Este tipo permite a la aplicación cliente solicitar y recibir directamente un token de acceso enviando las credenciales del usuario (nombre de usuario y contraseña). Debido al hecho de que la aplicación cliente tiene acceso directo a las credenciales del usuario, este tipo de concesión también se considera obsoleto y debe evitarse bajo todas las circunstancias.
Credenciales del cliente: Utilizado para la comunicación máquina a máquina donde la aplicación en sí es el cliente. Implica que la aplicación se autentique con el servidor de autorización y solicite un token de acceso para acceder a sus propios recursos o a los de otro servicio.

¿Qué es el flujo implícito?

El flujo implícito es un flujo simplificado de OAuth 2.0 donde el token de acceso se devuelve directamente al cliente en el URI de redirección, sin un paso adicional para intercambiar un código de autorización por un token. Fue diseñado originalmente para aplicaciones web que no podían realizar solicitudes del lado del servidor al punto final del token debido a restricciones del navegador.

¿Cómo funciona el flujo implícito?

El usuario hace clic en un botón o enlace en la aplicación cliente para iniciar el proceso de autenticación.
La aplicación cliente redirige al usuario al servidor de autorización para autenticarse, incluyendo el ámbito de acceso deseado.
El servidor de autorización solicita a los usuarios iniciar sesión y conceder permiso a la aplicación cliente.
Tras una autenticación y autorización exitosas, el servidor de autorización redirige el navegador del usuario de vuelta al URI de redirección especificado por el cliente, con el token de acceso incluido en el fragmento de la URL.
La aplicación cliente extrae el token de acceso del fragmento de la URL y lo usa para acceder a los recursos del usuario en el servidor de recursos.

Riesgos de seguridad con el flujo implícito

El flujo implícito tiene varias vulnerabilidades de seguridad:

Exposición del token: El token de acceso se devuelve directamente al cliente en el fragmento de la URL, que puede ser fácilmente interceptado por partes maliciosas. Esto expone el token de acceso a potenciales robos y usos indebidos.
Ataques CSRF: El flujo implícito es susceptible a ataques de Cross-Site Request Forgery (CSRF), donde sitios web maliciosos pueden engañar a los usuarios para conceder acceso no autorizado a sus cuentas.

Debido a estas preocupaciones de seguridad, el flujo implícito ya no se recomienda para aplicaciones web modernas. En su lugar, el flujo de código de autorización con PKCE (Prueba de Clave para Intercambio de Código) es la opción preferida para una autorización de usuario segura.

¿Qué es el flujo de código de autorización?

El flujo de código de autorización, por otro lado, es un flujo de OAuth 2.0 más seguro que separa el proceso de autorización en dos pasos: la aplicación cliente primero obtiene un código de autorización del servidor de autorización, luego intercambia el código por un token de acceso. Este flujo fue diseñado inicialmente para aplicaciones web del lado del servidor que pueden almacenar de forma segura las credenciales del cliente y gestionar los tokens de acceso. Con la introducción de la extensión PKCE, el flujo de código de autorización ahora se puede usar en aplicaciones basadas en navegador también.

¿Cómo funciona el flujo de código de autorización para clientes privados con componente del lado del servidor?

El usuario hace clic en un botón o enlace en la aplicación cliente para iniciar el proceso de autenticación.
La aplicación cliente redirige al usuario al servidor de autorización para autenticarse con el ámbito de acceso deseado.
El servidor de autorización solicita a los usuarios iniciar sesión y conceder permiso a la aplicación cliente.
Tras una autenticación y autorización exitosas, el servidor de autorización devuelve un código de autorización al cliente.
La aplicación cliente intercambia de forma segura el código de autorización por un token de acceso haciendo una solicitud de servidor a servidor al punto final del token usando sus credenciales de cliente.
El servidor de autorización valida el código de autorización y las credenciales del cliente y devuelve un token de acceso al cliente.
La aplicación cliente usa el token de acceso para acceder a los recursos del usuario en el servidor de recursos.

¿Cómo funciona el flujo de código de autorización para clientes públicos con PKCE?

El usuario hace clic en un botón o enlace en la aplicación cliente para iniciar el proceso de autenticación.
La aplicación cliente genera un verificador de código y un desafío de código.
La aplicación cliente redirige al usuario al servidor de autorización para autenticarse con el desafío de código.
El servidor de autorización almacena el desafío de código para su verificación posterior.
El usuario se autentica y aprueba el acceso a la aplicación cliente.
El servidor de autorización devuelve un código de autorización al cliente.
La aplicación cliente intercambia el código de autorización por un token de acceso haciendo una solicitud de servidor a servidor al punto final del token usando el verificador de código.
El servidor de autorización valida el código de autorización y el verificador de código contra el desafío de código almacenado.
El servidor de autorización devuelve un token de acceso al cliente.
La aplicación cliente usa el token de acceso para acceder a los recursos del usuario en el servidor de recursos.

Aprende más sobre el flujo PKCE.