Rischio di mantenere OAuth2 client_secret nell'applicazione

3

Come esercizio, sto sviluppando un'applicazione desktop con cui gli utenti devono accedere a un servizio web. Un caso d'uso logico per OAuth2 si direbbe, ma sto iniziando a dubitare della sua utilità. Sto cercando l'autenticazione a due vie , che lascia le credenziali client , implicite e password del proprietario della risorsa disponibili .

Poiché vorrei che gli utenti fossero in grado di accedere direttamente all'applicazione (non tramite un browser e un URI di reindirizzamento), il flusso implicito si riduce come opzione. Gli altri due flussi richiedono che vengano inviati client_id e client_secret , e ho letto molte volte che non è sicuro memorizzare client_secret all'interno dell'applicazione desktop.

La mia domanda è questa: quanto è pericoloso questo davvero? Quanto è facile per gli avversari decompilare le applicazioni (desktop) e calcolare il client_secret ? Potrei considerare di accettare il rischio, in modo da poter utilizzare il flusso delle credenziali del client di OAuth2 , perché rotolare il mio schema di autenticazione probabilmente sarebbe ancora meno sicuro.

P.S. Qualcuno ha menzionato l'utilizzo del flusso implicito e l'avvio temporaneo di un server Web su localhost come URI di reindirizzamento per aggirare un browser, ma ciò sembra eccessivo se non insicuro. Qualche idea?

    
posta Stijn Frishert 02.02.2015 - 11:29
fonte

1 risposta

1

Esamina il processo OAuth per le applicazioni lato client .

Il tuo flusso OAuth dovrebbe essere simile a questo:

  1. Accesso utente
  2. La tua API restituisce un token di accesso per quell'utente
  3. L'applicazione desktop memorizza il token utente
  4. Le richieste future inviano il token e l'API lo utilizza per autenticare l'utente

Non è possibile proteggere realisticamente una chiave segreta globale nella propria applicazione, né è necessario.

    
risposta data 02.02.2015 - 16:10
fonte

Leggi altre domande sui tag