In un articolo di novembre 2014 di Alex Bilbie, gli utenti di OAuth sono stati sconsigliati a fare inviare il client le sue credenziali ( client_id e client_secret ) quando si esegue Password proprietario risorsa concedere chiamate. L'idea, a quanto ho capito, è che il client sia in grado di aggiungere le sue credenziali alle sue richieste, quelle credenziali devono essere scritte nel suo codice sorgente (spesso HTML / JS) e quindi accessibili ai possibili attaccanti, che potrebbero quindi usarle per eseguire chiamate all'API impersonando il client.
In commenti di un altro post del blog , l'autore ha aggiunto:
If I can view source and copy the client credentials there’s nothing stopping me building my own app that can authenticate against your OAuth service and then call the API.
La soluzione proposta è che il client non deve chiamare direttamente l'API, ma piuttosto un proxy sottile che sarebbe responsabile per l'aggiunta delle credenziali del client alla richiesta e quindi per l'inoltro all'API.
Come novellino OAuth ingenuo, non capisco perché questo impedirebbe agli attaccanti di eseguire chiamate alla mia API. Se il cliente non deve aggiungere le sue credenziali alle sue richieste, nessuno lo fa. Poiché il proxy aggiunge automaticamente le credenziali, ogni richiesta inviata all'API viene quindi considerata come proveniente dal client autorizzato.
Qualcuno ha chiesto ad Alex Bilbie questa stessa domanda su Twitter. Ecco la sua risposta:
how would you secure the proxy? Can't the attacker just send a request to the proxy and have the secret happily filled in?
the point is that you’re hiding implementation details of your backend and therefore retaining more control
Sarei grato se qualcuno potesse elaborare questa risposta, dato che non riesco a vedere cosa potrei ottenere (per quanto riguarda la sicurezza) dal nascondere i dettagli di implementazione e allo stesso tempo rimuovere la necessità per un client di autenticarsi.