Perché è richiesto in OAuth 2.0 che il token di aggiornamento non possa essere indovinato?

... since when the client wants to obtain an access token using the refresh_token grant type, it MUST send a client ID and a secret key in the body of the request...

Secondo RFC 6749 questa affermazione non è completamente vera. Il token di aggiornamento è l'unica informazione di cui un client ha bisogno per ottenere un nuovo token di accesso.

Tuttavia, questo è solo il caso per i client pubblici come definito nella sezione 2.1 della specifica. Potresti immaginare l'ID cliente e il segreto del cliente come una sorta di licenza per consumare un'API per fornire determinati servizi ai tuoi clienti. Ma è necessario un permesso speciale di ogni cliente per consumare le proprie risorse dall'API. Il token di accesso è la rappresentazione di questa autorizzazione. Tuttavia, non darebbe la licenza per consumare l'API a un cliente. Questo sarebbe il caso in molte applicazioni per browser e dispositivi mobili.

Refresh_tokens sono facoltativamente generati insieme a access_tokens dal servizio di autorizzazione. Il access_token di solito è di breve durata (in confronto) ed è utilizzato esclusivamente per ottenere l'accesso a qualsiasi risorsa richiesta. Quando il Access_token è naturalmente scaduto, il refresh_token viene utilizzato con il server di autorizzazione per ottenere un altro access_token .

Generalmente refresh_tokens ha una vita molto più lunga link per esempio afferma che alcuni refresh_tokens non scadono

Ciò significa che un utente malintenzionato ha molto tempo per indovinare il token di aggiornamento e quindi utilizzarlo per ottenere access_tokens .

Se un utente malintenzionato richiede anche l'ID client e la chiave segreta, la chiave di aggiornamento aggiunge un ulteriore livello di complessità all'attacco, alzando effettivamente la barra. Se fosse facilmente ipotizzabile, non avrebbe senso utilizzarlo in quanto non aggiunge alcuna protezione aggiuntiva e in effetti dà forse la falsa impressione di maggiore sicurezza

Il requisito di un segreto del client implica che il client sia considerato affidabile dal server di autorizzazione e in genere solo i servizi sul lato server possono essere considerati affidabili da un server di autorizzazione.

In generale, non si desidera che i clienti potenzialmente inaffidabili come i dispositivi mobili o il browser Web dispongano di token di aggiornamento. Ecco perché OAuth 2 flusso implicito non supporta i token di aggiornamento.