¿Por qué en OAuth 2.0 se requiere que no se pueda adivinar el token de actualización?

  

... ya que cuando el cliente desea obtener un token de acceso utilizando el tipo de concesión refresh_token, DEBE enviar un ID de cliente y una clave secreta en el cuerpo de la solicitud ...

Según RFC 6749 esta declaración no es del todo cierta. El token de actualización es la única información que un cliente necesita para obtener un nuevo token de acceso.

Sin embargo, este es solo el caso para clientes públicos como se define en la sección 2.1 de la especificación. Podría imaginar la identificación del cliente y el secreto del cliente como una especie de licencia para consumir una API para proporcionar ciertos servicios a su cliente. Pero necesita un permiso especial de cada cliente para consumir sus recursos de la API. El token de acceso es la representación de este permiso. Sin embargo, no otorgaría su licencia para consumir la API a un cliente. Este sería el caso en muchas aplicaciones de navegador y dispositivos móviles.

Refresh_tokens se generan opcionalmente junto con access_tokens por el servicio de autorizaciones. El access_token generalmente es de corta duración (en comparación) y se usa únicamente para obtener acceso a cualquier recurso requerido. Una vez que el Access_token ha expirado naturalmente, entonces el refresh_token se usa con el servidor de autorización para obtener otro access_token .

Normalmente, refresh_tokens tiene una vida útil mucho más larga enlace para el ejemplo indica que algunos refresh_tokens no caducan

Esto significa que un atacante tiene mucho tiempo para adivinar el token de actualización y luego lo usa para obtener access_tokens .

Si un atacante también requiere la ID del cliente y la clave secreta, la clave de actualización está agregando una capa adicional de complejidad al ataque, elevando la barra de manera efectiva. Si fuera fácil de adivinar, entonces no tendría sentido usarlo, ya que no agrega protección adicional y, de hecho, posiblemente da la falsa impresión de más seguridad

El requisito de un secreto de cliente implica que el servidor de autorización confía en el cliente y, por lo general, solo un servidor de autorización puede confiar en los servicios del lado del servidor.

En términos generales, no desea que los clientes potencialmente poco confiables, como los dispositivos móviles o el navegador web, tengan tokens de actualización. Es por esto que OAuth 2 flujo implícito no admite tokens de actualización.