Evita gli attacchi di forza bruta sul server di autorizzazione oAuth

Ho esaminato il framework di autorizzazione oAuth 2 per un po 'di tempo. Ieri ho iniziato a chiedermi come prevenire un attacco di forza bruta durante il flusso di concessione del codice di autorizzazione ( link ). Per chiarire, il flusso funziona come segue:

1. Il browser invia richieste per una risorsa protetta su un client oAuth 2 ( client.example.com ).

2. Il browser viene reindirizzato all'endpoint di autorizzazione sul server di autorizzazione:

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

con lo stato è una sorta di stringa casuale generata dal client oAuth 2

3. Il browser si collega al server di autorizzazione

4. Quando si accede correttamente, il browser viene reindirizzato a redirect-uri con alcuni parametri di query

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

la stringa di stato deve essere la stessa inviata dal client e il token una stringa generata dal server di autorizzazione.

5. Il client verifica se il parametro di stato appartiene alla sessione dell'agente utente (per impedire XSRF) e richiede il token di accesso dal server di autorizzazione utilizzando il parametro di query code e l'autenticazione di base con le credenziali dei client:

   POST /token HTTP/1.1  %codice%  %codice%  %codice%   Host: server.example.com

È possibile che un utente malintenzionato ripeta più e più volte i passaggi 2 e 4, senza effettuare effettivamente l'accesso al server di autorizzazione:

1. Vai a una risorsa riservata su Authorization: Basic czZCaGRSa3F0MzpnWDFmQmF0M2JW .
2. Analizza il parametro di richiesta Content-Type: application/x-www-form-urlencoded nel reindirizzamento (e memorizza l'ID cookie / sessione)
3. Prova a ottenere un token per grant_type=authorization_code&code=SplxlOBeZQQYbYS6WxSbIA &redirect_uri=https%3A%2F%2Fclient%2Eexample%2Ecom%2Fcb andando al link (con cookie / sessione id ricevuto in 1)

Fai questo più e più volte per client.example.com , state , ...

Niente rimane uguale tra due tentativi dell'attaccante, il che rende difficile per il server delle autorizzazioni memorizzare un numero di tentativi e bloccare dopo un certo numero.

Tuttavia, vi è probabilmente una piccola finestra temporale per l'attaccante per eseguire l'attacco, poiché il codice è valido solo sul server tra i passaggi 4 e 5 nel flusso (tranne se il client si blocca da qualche parte tra 4 e 5).

Altro quindi

• con un codice di grandi dimensioni generato dal server di autorizzazione
• rendendo i codici disponibili solo per un periodo di tempo limitato

C'è qualcos'altro che possiamo fare per prevenire l'attacco descritto?