2011-09-30 16 views
15

ho trovato un bel paio di domande su questo argomento su SO, ma non abbiamo trovato nessuna risposta a questa domanda:RESTful API Authentication

Devo convalidare gli utenti con il proprio nome utente e password, o con una chiave API? E quali sono i pro e i contro di ciascun metodo.

Chiedo questo perché nella mia API ci sono un paio di metodi che vorrei bloccare e verificare che l'utente abbia accesso ad alcuni documenti o azioni. Sono un po 'riluttante ad autenticarsi facendo in modo che l'utente invii un'intestazione HTTP AUTH con il loro nome utente e password perché non è sicura e un po' più complicata per l'utente. D'altra parte, però, se uso una chiave API, qual è il punto in cui l'utente crea una password? Poiché non lo useranno più per accedere alle funzionalità dell'API.

UPDATE

Se altri lettori di questo sono curioso quello che ho finito per usare, ho deciso di copiare come Amazon fa il loro validazione (buona spiegazione here: https://www.ida.liu.se/~TDP024/labs/hmacarticle.pdf)

+2

Apprezzare l'AGGIORNAMENTO. Grazie. –

+0

Il collegamento è rotto, per favore considera di aggiornarlo. Link aggiornato: https://www.ida.liu.se/~TDP024/labs/hmacarticle.pdf –

+0

link: http://acaasia.blogspot.co.il/2013/04/designing-secure-rest-web- api-without.html – OhadR

risposta

7

è possibile utilizzare l'autenticazione HTTP over SSL e questo è abbastanza sicuro. Tuttavia rende un consumo di API un po 'difficile in quanto richiede la libreria client per supportare SSL. SSL può influire anche sulle prestazioni se ti aspetti troppe chiamate contemporaneamente.

L'opzione chiave API è altrettanto insicura dell'autenticazione HTTP senza SSL. Se non sei interessato alla sicurezza, la chiave API è la più semplice per i consumatori dell'API.

+0

Quindi, se si utilizza la route della chiave API, vale la pena fare in modo che l'utente effettui una password? Sembra che la chiave API eliminerebbe la maggior parte se non tutti gli scopi di avere una password – Obto

+0

@Obto nome utente possono essere generati in modo sequenziale e la password può essere generata in modo casuale. Più parti delle credenziali di autenticazione; più lungo e difficile è rompere la password. È davvero una questione di gusti. Una chiave API più lunga con parti sequenziali e casuali o un nome utente e una password separati. La chiave API non è generalmente leggibile dall'uomo e generata automaticamente (nel qual caso la password è ridondante). –

+0

Quindi, alla fine, sembra che si riduca davvero alle tue preferenze – Obto

5

Un buon metodo è quello di avere un metodo di accesso, prendendo il nome utente e la password (si spera su TLS). Dai loro un gettone in scadenza se riescono ad autorizzare; il resto delle loro chiamate API deve contenere questo token per avere successo.

+0

@HasanKhan bene chiaramente oAuth sta facendo qualcosa di sbagliato. – Ivo

+0

@Hasan Khan Si noti che il token * non * deve * essere memorizzato nello stato condiviso; potrebbe semplicemente essere determinato in modo deterministico usando un segreto lato server (ad esempio data hash con segreto, hash con hash segreto o timestamp crittografato in modo reversibile). Quindi è possibile utilizzare un archivio di stato che probabilmente ridurrà ad almeno migliaia di richieste al secondo senza problemi e scegliere un'opzione più performante se e quando necessario. –