Evite los ataques de fuerza bruta en el servidor de autorización oAuth

He estado investigando el marco de autorización de oAuth 2 por un tiempo. Ayer comencé a preguntarme cómo prevenir un ataque de fuerza bruta durante el flujo de la Subvención del Código de Autorización ( enlace ). Para aclarar, el flujo funciona de la siguiente manera:

1. El navegador envía las solicitudes de un recurso protegido en un cliente oAuth 2 ( client.example.com ).

2. El navegador se redirige al punto final de autorización en el servidor de autorización:

   GET /authorize?response_type=code&client_id=s6BhdRkqt3&state=xyz &redirect_uri=https%3A%2F%2Fclient%2Eexample%2Ecom%2Fcb

siendo el estado algún tipo de cadena aleatoria generada por el cliente oAuth 2

3. El navegador inicia sesión en el servidor de Autorización

4. Cuando se inicia sesión correctamente, el navegador se redirige de nuevo al redirect-uri con algunos parámetros de consulta

   https://client.example.com/cb?code=SplxlOBeZQQYbYS6WxSbIA&state=xyz

la cadena de estado debe ser la misma que la enviada por el cliente, y el token es una cadena generada por el servidor de autorización.

5. El cliente verifica si el parámetro de estado pertenece a la sesión del agente de usuario (para evitar XSRF) y solicita el token de acceso del servidor de autorización usando el parámetro de consulta code y la autenticación básica con las credenciales de los clientes:

   POST /token HTTP/1.1  %código%  %código%  %código%   Host: server.example.com

Es posible que un atacante repita los pasos 2 y 4 una y otra vez, sin iniciar sesión en el servidor de autorización:

1. Vaya a un recurso restringido en Authorization: Basic czZCaGRSa3F0MzpnWDFmQmF0M2JW .
2. Analice el parámetro de solicitud Content-Type: application/x-www-form-urlencoded en la redirección (y almacene la cookie / id de sesión)
3. Intente obtener un token para grant_type=authorization_code&code=SplxlOBeZQQYbYS6WxSbIA &redirect_uri=https%3A%2F%2Fclient%2Eexample%2Ecom%2Fcb yendo a enlace (con cookie / sesión Identificación recibida en 1)

Haz esto una y otra vez para client.example.com , state , ...

Nada permanece igual entre los dos intentos del atacante, lo que dificulta que el servidor de autorización almacene varios intentos y los bloquee después de un cierto número.

Sin embargo, es probable que haya una pequeña ventana de tiempo para que el atacante realice el ataque, ya que el código solo es válido en el servidor entre los pasos 4 y 5 del flujo (excepto si el cliente falla entre 4 y 5).

Otro entonces

• que tiene un código grande generado por el servidor de autorización
• hacer que los códigos estén disponibles solo por un tiempo limitado

¿hay algo más que podamos hacer para prevenir el ataque descrito?