API (Activar configuración de OAuth): Control de configuración de flujo Código de autorización y credenciales

Nombre de control

Aplicaciones conectadas: API (Activar configuración de OAuth): Configuración de flujo Código de autorización y credenciales

Configuración recomendada

Active el flujo Código de autorización y credenciales.

No requerir o anular la selección de Requerir secreto para flujo de servidor web y Requerir secreto para flujo de token de actualización.

Descripción general de control

Este control configura los requisitos de seguridad específicos para el "Flujo Código de autorización y credenciales", determinando si un secreto de cliente debe validarse basándose en si la aplicación es un "Cliente privado" (lado del servidor) o un "Cliente público" (navegador/móvil).

Riesgo de seguridad si no está configurado

Requerir incorrectamente un secreto para clientes públicos fuerza la codificación de credenciales en código de inicio donde se roban fácilmente, mientras que no requerir un secreto para clientes privados permite a los atacantes intercambiar códigos interceptados sin necesitar la clave privada de la aplicación.

Escenarios de amenazas

Un atacante descompila una aplicación móvil para extraer un secreto de cliente codificado o intercepta un código de autorización desde una aplicación del lado del servidor y la intercambia con éxito por un token de acceso de alto privilegio porque no se requería ningún secreto para el intercambio.

Intervalo de puntuaje de CVSS estimado

Crítico (9,0 a 10,0).

Consideraciones de impacto de riesgo

La configuración incorrecta lleva al compromiso de las credenciales de cliente o la activación del secuestro de sesiones no autorizado, lo que da como resultado un acceso persistente y no autenticado a datos confidenciales.

Mayor riesgo cuando

Cuando el flujo se utiliza para integraciones de alto privilegio que carecen de PKCE (Clave de prueba para intercambio de códigos) como defensa secundaria o cuando los secretos se almacenan en repositorios del lado del cliente de texto sin formato.

Bajo riesgo cuando

Cuando "Clientes privados" aplican estrictamente secretos almacenados en bóvedas seguras del lado del servidor y "Clientes públicos" utilizan PKCE para proteger el intercambio sin necesidad de un secreto compartido vulnerable.

Consideraciones de negocio e integración

La implementación de esto correctamente requiere una clara distinción arquitectónica entre aplicaciones dirigidas por backend y dirigidas por frontend para asegurarse de que se aplica la política "Secreto" apropiada sin romper el apretón de manos de autenticación.

Remediación recomendada

Para clientes privados/del lado del servidor, seleccione "Requerir secreto para flujo de servidor web" y "Requerir secreto para flujo de token de actualización"; Para clientes públicos/móviles, anule la selección de estas opciones e implemente PKCE en su lugar.

Directrices de revisión del estado de seguridad

Security Health Review destaca que la seguridad de un secreto depende completamente de la capacidad del cliente para protegerlo y exige que ningún secreto compartido se exponga nunca al navegador o entorno móvil.