Garantisce il flusso di OAuth 2 per l'applicazione client o mobile

Question

Garantisce il flusso di OAuth 2 per l'applicazione client o mobile

#1 da (1 voti)
#2 da (1 voti)

6

Sto implementando un'API e un'app Web sul lato client, che dovrebbero comunicare tramite un'API e utilizzare OAuth 2 per l'autenticazione.

Non riesco a superare la mia confusione su quale sia il modo giusto per autenticare gli utenti (ad esempio senza importanti problemi di sicurezza).

Ho raccolto quanto segue:

Idealmente, dovresti esporre un modulo web sul server API che accetta nome utente e password e reindirizza con un codice di autorizzazione, da scambiare sul lato client per un token di accesso token di accesso.
L'approccio che ho descritto è considerato ingombrante, quindi OAuth 2 offre un flusso implicito in cui l'app lato client effettua una richiesta contenente un client_id e le credenziali dell'utente, che raccoglie. Riceve un token di accesso.
Gli strumenti di autenticazione sembrano essere cauti nel consentire solo il passaggio di client_id e invece richiede l'inclusione di client_secret .
In base al punto precedente, come sviluppatore potresti dover incorporare il client_secret nell'applicazione distribuibile, rendendolo così pubblico.
Alcuni peer con una comprensione di OAuth 2 mi hanno detto che non è raro che gli sviluppatori incorporino il client_secret nelle loro distribuzioni e che alcuni servizi di alto profilo (presumibilmente Twitter) lo facciano altrettanto bene.
Se aggiungi un proxy tra il client e il server OAuth 2 per aggiungere client_secret alle richieste, non migliora la sicurezza poiché è simile a ignorare del tutto client_secret .
L'unica preoccupazione per la sicurezza che ho potuto trovare relativa all'inclusione di client_id e client_secret nel client è che un utente malintenzionato può implementare il proprio client che, se fornito delle credenziali dell'utente, può agire per conto dell'utente. Questo non sembra un probabile attacco, poiché il phishing è simile e offre maggiori vantaggi.

Le seguenti domande sono ancora senza risposta per me:

Qual è la differenza tra il flusso di credenziali del cliente e il flusso della password del proprietario della risorsa ? Quale dovrei preferire? Le risposte a questa domanda do non darmi una chiara comprensione della differenza.
Ci sono problemi di sicurezza importanti nell'uso del flusso implicito o è fattibile?
È possibile incorporare client_secret sicuro?
- In caso contrario, qual è l'alternativa? Devo ancora richiedere client_id o consentire l'utilizzo di client "pubblici" (non registrati)

api client-side oauth secret-sharing

posta Gabriele Cirulli 31.07.2016 - 13:07

fonte

2 risposte

1

Non è sicuro salvare il segreto del client sul cellulare, quindi lavorerò sulla domanda 3.

Non ho una soluzione, ma spiegherò un'alternativa che potrebbe mitigare il rischio di salvare un client_secret in un dispositivo mobile.

Un'alternativa che si può fare sarebbe l'uso delle credenziali di installazione invece delle credenziali del client. Le credenziali del cliente avranno una relazione genitore con le credenziali di installazione.

Client Credentials 1
Installation credentials 1
Installation Credentials 2 ....

L'idea è di utilizzare un back-end del canale di sicurezza per il back-end per generare credenziali di installazione. Avrai bisogno di creare un servizio, dove ricevi le credenziali APP e restituisci un ID di installazione. Inoltre, il proprietario dell'applicazione mobile dovrà creare un servizio in cui l'utente richiede una credenziale di installazione.

In sostanza,

APP per dispositivi mobili - > BackEnd (App per dispositivi mobili di proprietà) - > BackEnd (proprietario OAuth)

Questa soluzione non risolve il tuo problema, ma riduce il rischio di rivelare segreti. Otterrai le credenziali di installazione e potrai utilizzarlo sul tuo flusso OAuth. Se qualcuno ottiene il segreto, può impersonare solo un singolo utente. L'attacco non verrà ridimensionato.

risposta data 04.08.2016 - 15:14

fonte

Leggi altre domande sui tag api client-side oauth secret-sharing

JWT vs certificati client Dove dovrei memorizzare un token di aggiornamento

score 1 · Accepted Answer

In primo luogo, chiariamo una cosa: OAuth2 è un'autorizzazione quindi tieni questo a mente.

Successivamente, prova a definire le cose ulteriormente:

Proprietario risorse

Queste sono le credenziali che usi quando vuoi concedere l'accesso a qualcosa come Snapchat che vuole accedere tramite FB.

Client Credientals

Si tratta di credenziali che identificano un client, ad esempio un'app moblie o un'applicazione in-browser. E. non è possibile utilizzare l'accesso Snapchat approvato con accesso Instantgram approvato.

Exmaple

Accedi a Snapchat tramite FB.
Tieni reindirizzato a FB per autenticare e / o autorizzare Snapchat. L'app richiede una concessione di accesso per accedere alla tua risorsa (profilo FB I.E).
Tu approvi e Snapchat invia la sovvenzione a FB, che fornisce Snapchat un token di accesso, che può essere utilizzato per accedere all'elenco dei tuoi amici.

Problemi di sicurezza attorno al flusso implicito

Ci sono rilevanti problemi di sicurezza. Puoi vederlo discusso qui su SO e qui su Thread Safe. In generale, è una pratica praticabile e devi solo tenere conto di alcune (le quali dovrebbero già essere in mente) le migliori pratiche di sicurezza.

Infine, alle chiavi incorporate

Ti suggerisco di no. Ti indirizzo a questo blog post di stormpath su questa esatta preoccupazione. Questo è principalmente intorno a JWT ma si applica a Oauth2.