Stavo leggendo qui che quando si passa un client_id e un client_secret a un server di autorizzazione,
The parameters can only be transmitted in the request-body and MUST NOT be included in the request URI.
Should the server not provide an access token to the client if these parameters are in the request uri instead of the body?
Questo probabilmente ha senso per educare i programmatori (se non ottengono un token di accesso, allora impareranno a farlo nel modo giusto), ma non renderebbe il sistema più sicuro se fosse sotto attacco. Se l'ID del client e il segreto del client sono stati rubati, l'utente malintenzionato potrebbe impersonare il client e ottenere un token di accesso valido inviando una richiesta corretta (con l'ID e il segreto nel corpo del messaggio).
What are the possible dangers of posting these parameters in the request uri?
Se utilizzi https per comunicare con il tuo endpoint e ti fidi del tuo fornitore di token di accesso, il pericolo sarebbe probabilmente ridotto.
L'ID e il segreto del client possono essere visualizzati nella cronologia del browser se li invii direttamente dal browser e potrebbero essere sottratti tramite javascript dannoso, che a mio avviso sarebbe il più grande rischio. (Ma tieni presente che se affidi browser javascript con il tuo ID client e segreto, allora sono già non sicuri ...)
L'id e il segreto potrebbero anche essere rubati dall'altra parte della connessione, poiché vengono visualizzati nei registri del server Web del server a cui viene inviato, ma poiché si inviano le credenziali del client a un provider che già li ha, e chi spera sa come mantenere i suoi sistemi sicuri, penserei che questo non era un probabile punto di compromesso.
Se usi HTTP non criptato, l'id del client e il segreto potrebbero finire nei registri di cache e proxy. Se qualcuno che annusa il tuo traffico può vedere l'URL è solo midly rilevante; dal momento che per farlo deve guardare la richiesta, e quindi potrebbe anche vedere l'id e il segreto se sono stati inviati nel corpo della richiesta.