OAuth2 - Concessione di credenziali password proprietario risorse

Question

OAuth2 - Concessione di credenziali password proprietario risorse

#1 da (10 voti)
#2 da (4 voti)
#3 da (1 voti)

19

La specifica OAuth2 descrive il tipo di concessione e il flusso di autorizzazione delle credenziali della password del proprietario della risorsa qui . Comprendo che solo le applicazioni client "affidabili" possono utilizzare questa concessione, ad esempio l'applicazione client "ufficiale" per iPhone o Android tramite l'API di back-end.

La mia domanda è: come posso garantire che le richieste provenienti da fonti che sostengono di essere questa applicazione client possano essere attendibili? Ad esempio:

Ho registrato la mia app Android sul mio server OAuth2 con l'id client_id di android_app con accesso al tipo di concessione di password (cioè credenziali password proprietario risorse).
Poiché l'app per Android è un'applicazione client, quindi ho pensato che non sia affidabile mantenere il segreto del cliente "segreto" e quindi non averlo assegnato. La configurazione dell'app contiene client_id e grant_type e l'endpoint di autenticazione.
Un utente decompila / decomprime / desoffuce la mia app e trova il client id e l'endpoint

Che cosa impedisce loro di fare richieste di autenticazione a quell'endpoint con il client id? Prenderò in considerazione l'assegnazione al client di un client_secret, ma sembra che non risolverà il problema perché un utente potrebbe trovarlo solo nell'app.

authentication oauth

posta sf13579 27.07.2014 - 19:29

fonte

3 risposte

Leggi altre domande sui tag authentication oauth

Troncamento dell'output di SHA256 a 128 bit Quanto è cattivo Spectre?

score 10 · Answer 1

Queste sono davvero due domande.

Come posso garantire che le richieste provenienti da fonti che affermano di essere l'applicazione client possano essere attendibili?

Non puoi. The specifica dice :

The resource owner password credentials grant type is suitable in cases where the resource owner has a trust relationship with the client [...]

Il proprietario della risorsa (alias utente) deve decidere se si fida del client, non del server di autorizzazione. Se l'utente decide di affidarsi a un'app di terze parti al punto che inserisce la sua password semplice, non è possibile rilevare automaticamente se l'app di terze parti è affidabile.

Che cosa impedisce loro di fare richieste di autenticazione a quell'endpoint con l'id del client? Considererei l'assegnazione al client di un client_secret, ma sembra proprio che abbia vinto risolve il problema perché un utente potrebbe trovarlo nell'app.

OAuth2 distingue tra clienti riservati e pubblici . I clienti riservati sono "in grado di mantenere la riservatezza delle loro credenziali" , ad esempio un'applicazione web che accede a un altro sul lato server.

Le applicazioni native (come un'app per Android) sono citate esplicitamente come client pubblici:

A native application is a public client installed and executed on the device used by the resource owner. Protocol data and credentials are accessible to the resource owner. It is assumed that any client authentication credentials included in the application can be extracted. [...]

Pertanto un segreto client non aggiungerà sicurezza a un'applicazione nativa nella maggior parte dei casi d'uso.

score 4 · Answer 2

Come posso garantire che le richieste provenienti da fonti che affermano di essere l'applicazione client possano essere attendibili?

Non puoi.

Per citare un'altra SO risposta :

The thing is though, in mobile, the application is already trusted, once the user has installed the application he has chosen to trust it [...] Ultimately I don't think that it's possible to completely protect users from an application once they've decided to trust it by installing it.

Che cosa impedisce loro di fare richieste di autenticazione a quell'endpoint con l'ID client?

Niente.

Puoi concentrarti solo sulla protezione del nome utente / password dei tuoi utenti, ad esempio:

non memorizzarli nella tua app.
istruisci i tuoi utenti con spiegazioni chiare su dove trovare le tue app ufficiali e perché non dovrebbero fidarsi di altre app che chiedono le loro credenziali.

Una piccola spiegazione:

Per accedere alle risorse, un'app deve ottenere un token di accesso (e eventualmente un token di aggiornamento facoltativo).

Per ottenere il token di accesso, una prima richiesta include il nome utente e la password deve essere inviata all'endpoint. Nota: client_id e client_secret sono obbligatori solo per i client riservati o per qualsiasi cliente che ha emesso credenziali client.

Quindi l'app dannosa non può accedere a nessuna risorsa finché non ottiene il nome utente e la password, altrimenti non sarà in grado di ottenere un token di accesso. Anche se utilizza l'identità della tua app ufficiale.

score 1 · Answer 3

L'esempio fornito è in realtà un pessimo esempio per il motivo esatto che hai menzionato: un utente malintenzionato può semplicemente estrarre il client segreto e impersonare il client.

La sicurezza di questa sovvenzione si basa sulla capacità di proteggere il segreto del cliente. Inoltre, si basa sul modo in cui il canale può essere protetto, in modo tale che un utente malintenzionato non possa creare un uomo nel mezzo ed estrarre il segreto dalla richiesta. Se riesci a proteggerli entrambi, ti trovi in una situazione abbastanza buona, ma questo è davvero difficile da fare per le app mobili.

Per rispondere alla tua domanda: davvero non puoi. Puoi attenuare alcuni di questi problemi:

utilizzando ID client e segreti univoci per ogni istanza dell'applicazione, ma ciò complica seriamente la gestione
oppure puoi archiviare i segreti in un negozio di ferramenta fidato, ma il protocollo richiede la parola chiave segreta
oppure è possibile modificare il protocollo per utilizzare un identificatore client basato su token come l'utilizzo di un token JWT o SAML firmato dal client secret, in questo modo viene trasmessa una dichiarazione di breve durata firmata dal segreto anziché il segreto, ecc.

Aggiungi tutti quelli insieme e hai un modo abbastanza solido per identificare il cliente, ma sicuramente non è infallibile e ha sicuramente i suoi svantaggi: la gestibilità è una PITA, come si fa lo scambio segreto iniziale ?, ecc.