Autenticazione client e autenticazione utente

11

Attualmente sto esaminando i protocolli di autenticazione che funzionano bene con l'API REST, in java. C'è qualcosa di fondamentale che non capisco: leggo molto materiale sul protocollo OAuth, SSL, autenticazione HTTP di base, digest ecc. E in tutti ci sono significati apparentemente diversi del termine "cliente". Nella maggior parte dei casi, dalla mia comprensione, questo termine indica l'applicazione web o il browser. Ma in alcuni, ad esempio l'autenticazione HTTP di base, questo termine si riferisce all'utente stesso.

Non capisco esattamente come può un'istanza di un'applicazione web essere o deve essere autenticata. So che ci sono certificati coinvolti nel processo, ma, a mio avviso, si occupano solo di trasferire in modo sicuro il messaggio al server e di impedire gli attacchi di replay e MITM. In OAuth, ci deve essere un token nel certificato, dopo uno scambio di nome utente + password, ma poiché il nome utente e la password appartengono all'utente stesso, a quanto ho capito, dov'è la parte che autentica il client?

Esistono alcuni protocolli che utilizzano chiavi private e pubbliche sia dal lato server che lato client, il che assicura che il client sia "chi dice di essere". Ma queste chiavi devono essere applicate ad ogni istanza di questa web app? Non ho capito bene.

In quali casi, comunque, avremo bisogno dell'autenticazione client? Non è sufficiente per autenticare l'utente e prendersi cura dell'integrità del messaggio?

    
posta rita potter 04.04.2013 - 15:45
fonte

2 risposte

8

Il client è un concetto di rete: i dati vengono trasportati tra due macchine, il server e il client . Il cliente è colui che avvia la conversazione; il server è quello che è seduto tutto il giorno, in attesa che i client si connettano.

L'utente è l'entità biologica (presunta umana) che controlla il cliente. L'autenticazione riguarda il server, assicurandosi che tutto ciò che riceve provenga da un utente specifico. Tuttavia, il server non sta parlando all'utente (l'essere umano) ma al client (il computer dell'utente). Quando un server autentica l'utente tramite un cookie HTTP , viene autenticato veramente il client : poiché il valore del cookie è stato precedentemente inviato a un cliente specifico, solo quel client può mostrare il valore esatto del cookie. Il server quindi assume che un determinato client è sotto il controllo esclusivo del suo presunto proprietario umano, e quindi ritiene che l'utente umano sia stato coinvolto.

La distinzione tra cliente e utente diventa evidente quando la macchina dell'utente viene sovvertita (ad es. infettata da malware). La macchina inizierà a fare cose al di fuori del controllo dell'utente umano.

Per fare un'analogia, se hai un cane e quel cane mi morde, allora farò causa a tu , non al cane, perché il cane dovrebbe essere sotto il tuo controllo. Anche se il cane contrae rabbia (spiegando il suo comportamento rivendicativo), è ancora una tua responsabilità. In questo senso, autenticare il cane è buono come autenticarti (almeno agli occhi dei miei avvocati) e spetta a te assicurarti che il tuo cane sia davvero sotto il tuo controllo esclusivo.

Con le applicazioni Web e "API", l'immagine può diventare più complessa, perché il server può anche comportarsi come un client rispetto a un altro server. Quel server secondario potrebbe voler assicurarsi dell'identità del primo server o dell'utente umano che ha avviato l'intero processo o entrambi. La terminologia può essere fonte di confusione se vengono riutilizzati gli stessi termini.

Quando si utilizzano coppie di chiavi pubbliche / private, il proprietario della chiave privata (la macchina che contiene la chiave privata) lo utilizza per eseguire alcuni calcoli che si collegano a un altro calcolo che coinvolge la chiave pubblica. Ad esempio, con firme digitali , il proprietario della chiave privata genera una firma su un determinato messaggio ( una sequenza di byte); la firma può essere verificata utilizzando la chiave pubblica. Le firme digitali sono un buon strumento per l'autenticazione: calcolando una firma su una sfida inviata da un verificatore, il proprietario della chiave privata dimostra a quel verificatore la sua padronanza della chiave privata. Il verificatore ottiene quindi la garanzia che sta realmente parlando a "chiunque controlli la chiave privata corrispondente a una determinata chiave pubblica". La parte interessante del processo è che il verificatore non ha bisogno di conoscere la chiave privata per questo, quindi è possibile verificare una firma senza avere il potere di generare firme.

    
risposta data 04.04.2013 - 16:09
fonte
4

In OAuth, ci sono tre parti, il proprietario della risorsa (l'utente), il client (l'autenticazione con e il server delle risorse (il server che effettivamente convalida le credenziali dell'utente). Il client è l'applicazione web perché vuoi che il server delle risorse verifichi (e possibilmente fornisca dettagli su) il proprietario della risorsa (utente) che sta tentando di accedere.

È importante autenticare il client per diverse modalità di OAuth perché i dettagli sull'utente e possibilmente anche le autorizzazioni per utilizzare l'account dell'utente sul server di risorse verranno concessi all'applicazione Web (client).

L'uso dei termini è fonte di confusione poiché il client spesso è sinonimo di utente, ma nel caso di OAuth, è proprio come scelgono la terminologia.

In altri sistemi, la distinzione tra client e utente può significare se il computer da cui si effettua la connessione viene verificato o se la persona che lo utilizza. Alcuni meccanismi di autenticazione sono progettati per verificare l'hardware piuttosto che gli utenti. Un sistema di computer, ad esempio, potrebbe avere un certificato privato condiviso da più utenti che verifica che il client utilizzato sia un dato computer, ma non fornirebbe dettagli sull'utente di quel computer.

    
risposta data 04.04.2013 - 15:59
fonte

Leggi altre domande sui tag