segreto client in OAuth 2.0

Per utilizzare l'API di Google Drive, devo giocare con l'autenticazione utilizzando OAuth2.0. E ho qualche domanda su questo.

1. L'ID e il segreto del client vengono utilizzati per identificare qual è la mia app. Ma devono essere codificati se si tratta di un'applicazione client. Quindi, tutti possono decompilare la mia app ed estrarli dal codice sorgente. Significa che un'app difettosa può fingere di essere una buona app utilizzando l'ID client e il segreto dell'app buona? Quindi l'utente mostrerebbe una schermata che chiede di concedere l'autorizzazione a una buona app anche se in realtà viene richiesta da un'app cattiva? Se sì, cosa dovrei fare? O effettivamente non dovrei preoccuparmi di questo?

2. Nell'applicazione mobile, possiamo incorporare una visualizzazione web nella nostra app. Ed è facile estrarre il campo della password nella visualizzazione web perché l'app che chiede il permesso è in realtà un "browser". Quindi, OAuth nell'applicazione mobile non ha il vantaggio che l'applicazione client non ha accesso alle credenziali utente del fornitore di servizi?

Ho iniziato a scrivere un commento alla tua domanda ma poi ho scoperto che c'è troppo da dire, quindi ecco le mie opinioni sull'argomento nella risposta.

1. Sì, c'è una possibilità reale per questo e c'erano alcuni exploit basati su questo. Il suggerimento è di non mantenere segreta l'app nella tua app, c'è anche una parte nella specifica che le app distribuite non dovrebbero usare questo token. Ora potresti chiedere, ma XYZ lo richiede per funzionare. In tal caso non stanno implementando correttamente le specifiche e dovresti A non usare quel servizio (cosa improbabile) o B provare a proteggere il token usando alcuni metodi di offuscamento per rendere più difficile trovare o usare il tuo server come proxy.

   Ad esempio, c'erano alcuni bug nella libreria di Facebook per Android in cui passavano i token ai log, puoi saperne di più qui http://attack-secure.com/all-your-facebook-access-tokens-are-belong -per noi e qui https://www.youtube.com/watch?v=twyL7Uxe6sk . Tutto sommato sii particolarmente cauto nell'utilizzo di librerie di terze parti (in realtà il buon senso, ma se il dirottamento dei token è la tua grande preoccupazione, aggiungi un altro extra a cauto).

2. Ho parlato del punto 2 per un bel po 'di tempo. Ho persino eseguito alcuni accorgimenti nelle mie app per modificare le pagine di consenso (ad esempio cambiando lo zoom e il design per adattarli all'app) ma nulla mi ha impedito di leggere i valori dai campi all'interno della visualizzazione Web con nome utente e password. Pertanto sono totalmente d'accordo con il tuo secondo punto e lo trovo un grosso "bug" nelle specifiche OAuth. Il punto è che "L'app non ha accesso alle credenziali degli utenti" nelle specifiche è solo un sogno e dà agli utenti un falso senso di sicurezza ... Inoltre immagino che le persone di solito siano sospettose quando l'app chiede loro Facebook, Twitter, Dropbox o altre credenziali. Dubito che molte persone comuni leggano le specifiche OAuth e dicano "Ora sono al sicuro", ma invece usano il buon senso e generalmente non usano app di cui non si fidano.

Avevo la stessa domanda della domanda 1 qui, e ho fatto alcune ricerche di recente, e la mia conclusione è che è giusto non mantenere segreto il "segreto del cliente". Il tipo di client che non mantiene la riservatezza del client secret è denominato "client pubblico" nelle specifiche OAuth2. La possibilità che qualcuno malintenzionato possa ottenere il codice di autorizzazione e quindi il token di accesso è impedita dai seguenti fatti.

1. Il cliente deve ottenere il codice di autorizzazione direttamente dall'utente, non dal servizio

Anche se l'utente indica il servizio che si fida del client, il client non può ottenere il codice di autorizzazione dal servizio semplicemente mostrando l'ID del client e il segreto del client. Il client, invece, deve ottenere il codice di autorizzazione direttamente dall'utente. (Questo di solito viene fatto tramite il reindirizzamento URL, di cui parlerò più avanti.) Quindi, per il client dannoso, non è sufficiente conoscere l'ID client / segreto di cui l'utente ha fiducia. Deve in qualche modo coinvolgere o falsificare l'utente per dargli il codice di autorizzazione, che dovrebbe essere più difficile della semplice conoscenza dell'ID / segreto del client.

2. L'URL di reindirizzamento è registrato con l'ID / segreto client

Supponiamo che il client dannoso sia riuscito in qualche modo a coinvolgere l'utente e fargli fare clic sul pulsante "Autorizza questa app" nella pagina del servizio. Ciò attiverà la risposta di reindirizzamento dell'URL dal servizio al browser dell'utente con il codice di autorizzazione. Quindi il codice di autorizzazione verrà inviato dal browser dell'utente all'URL di reindirizzamento e il client dovrebbe essere in ascolto sull'URL di reindirizzamento per ricevere il codice di autorizzazione. (Anche l'URL di reindirizzamento può essere localhost e ho pensato che questo è un modo tipico in cui un "client pubblico" riceve il codice di autorizzazione.) Poiché questo URL di reindirizzamento è registrato nel servizio con l'id / segreto del client, il client dannoso non lo fa avere un modo per controllare dove viene fornito il codice di autorizzazione.

Risposta alla seconda domanda: le API di Google per motivi di sicurezza impongono che l'autenticazione / l'accesso non possa essere eseguito all'interno dell'app stessa (come le visualizzazioni web non sono consentite) e deve essere eseguito all'esterno dell'app utilizzando il browser per una migliore sicurezza, che è ulteriormente spiegato di seguito: https: //developers.googleblog.com/2016/08/modernizing-oauth-interactions-in-native-apps.html