concessione di password senza client secret?

7

Non riesco a decidere cosa fare per ottenere un token di accesso da un'app mobile.

Sono sicuro che questo è stato trattato prima, ma non riesco a trovarlo.

Ho abilitato le credenziali del proprietario delle risorse concesse sul mio server oauth2. La concessione richiede l'id del cliente, il segreto e il nome utente e la password di un utente.

Se non desidero memorizzare il mio segreto del client nella mia app per dispositivi mobili, è sicuro inviare SOLO ID client e emettere un token di accesso se il valore dell'ID client memorizzato nel record utente corrisponde all'ID client inviato da un'app mobile ?

Qual è la migliore pratica per questo caso d'uso?

    
posta Moon 06.10.2015 - 10:55
fonte

2 risposte

3

Ci sono molti problemi con quello che stai cercando di fare ...

Informazioni generali

OAuth2 nel modo "tradizionale" non è pensato per essere usato su qualcosa di diverso da un browser web. Ciò significa che se hai un'applicazione desktop o un'applicazione mobile, non devi utilizzare OAuth2 "tradizionale" per l'autenticazione. Con "tradizionale", intendo quello in cui viene reindirizzato al sito Web del provider per inserire il nome utente / password, quindi reindirizzato con un token che verrà utilizzato dal client e così via.

Ora iniziamo la spiegazione ... La documentazione di OAuth2 può essere un po 'confusa all'inizio. Quello a cui si riferiscono come client è quello che di solito chiamiamo server quando stiamo sviluppando un'applicazione web. C'è 3 parti in OAuth2:

  1. Fornitore di servizi: Google, Facebook, ecc.
  2. Client (server web, applicazione desktop, applicazione mobile che comunica con il fornitore di servizi)
  3. Utente (l'applicazione utilizzata dall'utente fisico)

Il problema con l'applicazione mobile e desktop è che il client e l'utente sono la stessa cosa e risiedono sul computer client. Mai sentito il detto "non c'è un lato client di sicurezza"? Questo vale più o meno qui.

Problema 1: il segreto del client

Hai ragione a non voler mettere il tuo cliente segreto nell'app mobile perché la tua app può essere "decompilata" e l'hacker recupererà il segreto del tuo cliente. Una volta che ce l'hanno, possono creare la propria applicazione e impersonare la tua app.

Problema 2: nome utente / password

Non utilizzare OAuth2 "tradizionale" su un'applicazione mobile / desktop. Il problema qui è come inserisci il nome utente / password e come recuperi il token che il fornitore di servizi fornisce all'utente dopo che ha effettuato l'accesso. Esaminiamo il modo possibile per farlo funzionare in modo sicuro ...

Tentativo fallito 1 : chiedi al tuo utente di inserire nome utente / password direttamente attraverso l'interfaccia.
Motivo per essere cattivo : Congratulazioni, hai appena rubato l'accesso a Facebook di tutti i tuoi utenti.

Tentativo fallito 2 : apri un browser con la pagina del provider.
Motivo per non essere bravo : come ottenere il token dal browser adesso? Non c'è modo di ottenerlo (a meno che tu non abbia un'applicazione dannosa che legge costantemente ciò che si trova nel browser dell'utente)

Tentativo fallito 3 : apri un browser falso per attirare l'utente a fornirti le sue informazioni di accesso.
Motivo per essere cattivo : Uguale al tentativo n. 1 . L'applicazione mobile può andare a schermo intero e controllare tutto ciò che vedi in modo da non fidarti di loro. L'applicazione desktop può aprire una nuova finestra che potrebbe imitare il browser, ecc.

Il fatto difficile è che non c'è modo di far funzionare OAuth2 "tradizionale" senza un browser sicuro che funge da "utente" e un server web https che funge da "client".

OAuth2 non è mai stato progettato per fornire l'autenticazione, ma piuttosto solo l'autorizzazione. C'è una grande differenza tra i due. Il protocollo OAuth2 è stato "hackerato" per renderlo in grado di fornire anche l'autenticazione (controlla OpenId). L'unico problema con questo "hack" è che funziona solo nel browser web come spiegato in precedenza.

Una vera soluzione

Se vuoi continuare a utilizzare OAuth2 / OpenID per il tuo login e vuoi farlo in modo sicuro, sarà un po 'diverso da quello che hai immaginato. L'utilizzo di OAuth2 per l'accesso è comunque una buona idea in quanto consente agli utenti di non ricordare altro nome utente / password.

  1. Avrai bisogno di un server in cui verranno archiviati l'ID e il segreto del tuo cliente. La tua app mobile si connetterà a questo server per inviare il token.

  2. Quando si richiede il login, reindirizzare l'utente alla pagina Web del fornitore di servizi in un browser. In alternativa, l'utente può accedere direttamente al tuo sito Web https per effettuare il reindirizzamento. La pagina web del fornitore di servizi è l'unico posto in cui inserire le informazioni di accesso.

  3. Crea una pagina web https in cui l'utente sarà in grado di vedere il token dopo aver effettuato l'accesso utilizzando il fornitore di servizi.

  4. Chiedi all'utente di copiare questo token nella tua applicazione. La tua applicazione quindi invia il token al tuo server. Il server aggiunge l'ID client e il client secret e lo inoltra al fornitore di servizi.

Il tuo utente può ora utilizzare il suo login "facebook" per accedere alla tua applicazione e non c'è alcun modo per la tua applicazione di rubare i suoi dati di accesso o per un hacker per rubare il segreto del tuo cliente.

Nota aggiuntiva

Il caso degli attacchi di phishing e OAuth2 quando viene utilizzato al di fuori di un browser Web è interessante, ma sarebbe l'argomento di un'altra domanda.

    
risposta data 06.10.2015 - 21:18
fonte
-1

Credo che ci sia una conversazione pertinente qui link ma non proprio un rispondi al problema.

Se sei preoccupato di non codificare a fondo il segreto nell'app e quindi problemi con la ricompilazione, allora una soluzione potrebbe essere quella di utilizzare un server secondario per archiviare in modo sicuro il segreto che può essere scaricato con un nome utente / password diversi che chiedi all'utente cioè che il flusso vada:

  1. chiedi all'utente di fornire nome utente e / o password

  2. usa queste credenziali per accedere a un servizio sicuro che restituisce il segreto

  3. usa il segreto come previsto (non archiviare localmente!)

È molto più lavoro e gestione, ma fornisce una soluzione sicura per il problema segreto hardcoded.

    
risposta data 06.10.2015 - 11:42
fonte

Leggi altre domande sui tag