Por qué deberías desaprobar el tipo de concesión de Credenciales de Propietario del Recurso (ROPC)
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 y debería ser desaprobado. En esta publicación, indicaremos por qué deberías evitar usar ROPC en tus aplicaciones.
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.