Por qué deberías desaprobar el tipo de concesión de Credenciales de Propietario del Recurso (ROPC)

Introducción#

El tipo de concesión de Credenciales de Propietario del Recurso (ROPC), también conocido como tipo de concesión de contraseña, es un flujo de OAuth 2.0 que permite a una aplicación intercambiar el nombre de usuario y la contraseña de un usuario por un token de acceso. Se introdujo por primera vez en la especificación de OAuth 2.0 como una forma de apoyar aplicaciones heredadas, como la autenticación básica HTTP o aplicaciones nativas heredadas que no podían usar los flujos de tokens OAuth más seguros.

Sin embargo, el tipo de concesión ROPC presenta varios riesgos de seguridad y ha sido marcado como un NO DEBE ser utilizado en las mejores prácticas de seguridad de OAuth 2.0.

Recientemente, hemos recibido varias preguntas de nuestros clientes solicitando orientación o soporte para implementar el tipo de concesión ROPC. En esta publicación, explicaremos por qué deberías evitar usar el tipo de concesión ROPC, especialmente para tus aplicaciones nuevas.

Tipo de concesión ROPC vs. flujo de código de autorización#

Cómo funciona el tipo de concesión ROPC#

El tipo de concesión ROPC es un flujo simple que intercambia el nombre de usuario y la contraseña del usuario por un token de acceso. La aplicación cliente recoge las credenciales del usuario directamente y las envía directamente al servidor de autorización. El servidor de autorización luego valida las credenciales y emite un token de acceso al cliente.

Cómo funciona el flujo de código de autorización#

En contraste, el flujo de código de autorización es el flujo recomendado de OAuth 2.0 para aplicaciones web. Implica múltiples pasos y redirecciones entre la aplicación cliente, el servidor de autorización y el navegador del usuario. El flujo de código de autorización es más seguro porque no expone las credenciales del usuario a la aplicación cliente.

Las principales diferencias entre el tipo de concesión ROPC y el flujo de código de autorización es que el ROPC expone las credenciales del usuario a la aplicación cliente, mientras que el flujo de código de autorización no lo hace. Las credenciales del usuario deben mantenerse confidenciales dentro del servidor de autorización. Siempre que una aplicación cliente solicite un recurso en nombre del usuario, debería redirigir al usuario al servidor de autorización para autenticar y autorizar la aplicación cliente. Esto mantiene una cantidad mínima de datos de autorización en el lado de la aplicación cliente.

Riesgos de seguridad del tipo de concesión ROPC#

1. Exposición de credenciales de usuario#

Como mencionamos anteriormente, el tipo de concesión ROPC expone las credenciales de usuario a la aplicación cliente. Esto es un riesgo de seguridad significativo porque la aplicación cliente puede almacenar o registrar las credenciales de usuario y obtener reautorización sin que el usuario lo sepa.

Especialmente en una aplicación cliente pública como una aplicación móvil o una aplicación de página única, la aplicación cliente puede ser fácilmente inyectada o revertida para extraer las credenciales del usuario. Ni una aplicación móvil ni una aplicación de página única que se ejecuta en el navegador del usuario pueden mantener secretos de forma confidencial. Por lo tanto, no pueden autenticar al usuario sin exponer las credenciales del usuario.

Incluso si el propietario del recurso tiene una relación de confianza con la aplicación cliente, la aplicación cliente desempeña un papel de intermediario en todo el proceso de autenticación, que podría ser comprometido por otro actor malicioso. El actor malicioso puede robar las credenciales del usuario y hacerse pasar por el usuario para acceder a los recursos del usuario.

Hay múltiples formas de robar las credenciales del usuario, dependiendo de la postura de seguridad de la aplicación cliente, como keyloggers, ataques de phishing o malware. Sin mencionar que las credenciales del cliente se transmiten a través de la red en cada solicitud de autorización. Esto aumenta aún más el riesgo de interceptación de credenciales.

Imagínate si tienes múltiples aplicaciones que usan el tipo de concesión ROPC, el riesgo potencial de exposición de credenciales se multiplica.

2. ROPC no soporta el consentimiento del usuario#

El tipo de concesión ROPC no soporta el consentimiento del usuario. Cuando la aplicación cliente recoge las credenciales del usuario directamente, el usuario no tiene la oportunidad de revisar y aprobar el acceso de la aplicación cliente a sus recursos. Esto es una violación de la privacidad y confianza del usuario.

Los usuarios deberían tener el derecho de decidir qué aplicación cliente puede acceder a sus recursos y por cuánto tiempo. Especialmente para aplicaciones de terceros, un mecanismo de consentimiento del usuario es esencial para proteger los datos del propietario del recurso y es esencial para cumplir con regulaciones de protección de datos como GDPR.

3. ROPC no soporta autenticación multifactor#

La autenticación multifactor (MFA) es una implementación de seguridad que requiere que el usuario proporcione dos o más factores de verificación para acceder a sus recursos. Añade una capa extra de seguridad al proceso de autenticación. El tipo de concesión ROPC no soporta MFA. En cambio, restringe el proceso de autenticación a un solo factor, y la solicitud de token se basa únicamente en las credenciales del usuario. Es imposible implementar mecanismos de autenticación basados en desafíos como OTP por SMS, OTP por correo electrónico o WebAuthn con el tipo de concesión ROPC.

ROPC no es compatible con aplicaciones modernas#

El tipo de concesión ROPC fue diseñado para soportar aplicaciones heredadas que no pueden soportar sistemas modernos de IAM, inicio de sesión único (SSO) o identidades federadas.

1. ROPC no es compatible con SSO#

El inicio de sesión único (SSO, por sus siglas en inglés) es una arquitectura de autenticación moderna que permite a los usuarios iniciar sesión una vez y acceder a múltiples aplicaciones sin esfuerzo.

Un IdP centralizado juega un papel crucial en la arquitectura de SSO. Gestiona la sesión de autenticación del usuario y emite tokens a las aplicaciones cliente. Las aplicaciones cliente no necesitan recoger las credenciales del usuario directamente, y las credenciales del usuario se mantienen confidencialmente dentro del IdP.

El tipo de concesión ROPC no soporta SSO. Requiere que la aplicación cliente recoja las credenciales del usuario directamente, lo que rompe la arquitectura SSO. No es compatible con sistemas modernos de SSO como OpenID Connect (OIDC) o SAML.

2. ROPC no es compatible con identidades federadas#

Similar a la arquitectura de SSO, las identidades federadas permiten a los usuarios utilizar su identidad existente para acceder a múltiples aplicaciones de terceros. Un usuario puede vincular múltiples cuentas sociales como Google, Facebook o Twitter a un IdP centralizado, y usar estas cuentas sociales para autenticarse con las aplicaciones cliente. Todas las identidades federadas son gestionadas por el IdP, y las aplicaciones cliente no conocen los detalles de autenticación del usuario en segundo plano.

El tipo de concesión ROPC, en cambio, requiere que la aplicación cliente recoja las credenciales del usuario directamente. Limita la capacidad de la aplicación cliente para soportar identidades federadas y expone los datos de identidad del usuario a la aplicación cliente.

Conclusión#

El tipo de concesión de Credenciales de Propietario del Recurso (ROPC) es un flujo de OAuth 2.0 heredado que presenta riesgos de seguridad significativos y debería ser desaprobado. Expone las credenciales del usuario a la aplicación cliente, no soporta mecanismos de seguridad modernos como MFA o SSO. Recomendamos encarecidamente evitar el uso del tipo de concesión ROPC para tus aplicaciones. Si tienes sistemas de autenticación heredados que dependen del tipo de concesión ROPC, considera migrar a flujos de OAuth 2.0 más seguros como el flujo de código de autorización o el flujo de credenciales de cliente.

Contáctanos si necesitas ayuda integrando servicios de autentificación y autorización de usuarios seguros en tus aplicaciones, o migrando desde un sistema de autenticación basado en contraseñas heredado a un flujo de OAuth 2.0 más seguro. Estamos aquí para ayudarte a construir aplicaciones seguras y modernas.