Quando si tratta di autenticazione API, questi sono i tre modelli più usati (in ordine casuale):
-
Le credenziali vengono inviate con ogni risposta.
-
Le credenziali vengono inviate una volta per generare una chiave di accesso. La chiave di accesso viene quindi inviata ad ogni richiesta.
-
Le credenziali vengono inviate una sola volta e quindi una sessione (facendo affidamento sui cookie) viene utilizzata per evitare l'autenticazione ripetitiva. Poiché una delle proprietà di REST è che è stateless , questo non dovrebbe essere considerato come REST e vinto " essere discusso in questa risposta.
Il primo ha un vantaggio della semplicità: non devi occuparti della chiave di accesso aggiuntiva, della sua generazione (dovrebbe usare generatore di numeri pseudo casuali crittograficamente sicuro ), la sua convalida e la sua invalidazione (per quanto tempo il client deve rimanere inattivo affinché la chiave diventi obsoleta?).
L'inconveniente, d'altra parte, è l'impatto in termini di prestazioni. Invece di verificare le credenziali una volta, dovresti verificarle ad ogni richiesta, il che significa anche che probabilmente non puoi usare PBKDF2 con un livello elevato numero di round, poiché richiede troppa potenza della CPU e rallenta enormemente l'API).
Nota che nel primo caso invierai le credenziali tramite l'intestazione Authorization di HTTP. Nel secondo caso, l'intestazione Authorization non deve essere utilizzata per inviare la chiave di accesso, poiché non è il suo scopo. Includere la chiave di accesso nell'URI sembra essere una pratica comune, anche se si traduce in URI lunghi e criptici e nella contaminazione dei log HTTP.
Should those be the same end user credentials different for every user or should they be sort of "app credentials" for accessing services?
Non dovresti usare la password utente. Se lo fai, significa che lo hai archiviato, in qualche modo, da qualche parte, in testo normale, ed è una pratica molto, molto brutta.
Esistono due modi per utilizzare un'API:
-
Utilizzo per utente. Questo è spesso il caso in cui l'API di terze parti è accessibile tramite JavaScript sul lato client. Ad esempio, se il tuo sito web consente a un utente di visualizzare l'elenco dei suoi amici da un altro sito web, caricando l'elenco tramite JavaScript chiamando questa altra API del sito web, di solito avrai un utilizzo per utente.
In questo caso, ci sarà un'associazione tra l'account API e l'account utente, in modo che ogni utente possa accedere all'API utilizzando un ID client specifico generato a caso e la chiave di accesso corrispondente (crittograficamente sicura generata casualmente). L'API dovrebbe fare affidamento sulla chiave di accesso come mezzo di autenticazione, ma in ogni caso dovrebbe ricevere o richiedere la password dell'utente originale.
-
Utilizzo per applicazione. Questo è spesso il caso in cui tu , e non i tuoi utenti, utilizzano l'API di terze parti. Ad esempio, se hai bisogno di accedere ad alcuni dati finanziari, generare i rapporti e poi vendere tali rapporti agli utenti (dato che ogni utente pagatore avrà lo stesso rapporto), sei in questo caso.
Qui avrai un singolo ID cliente e la chiave di accesso corrispondente. Dovrai memorizzarli in modo sicuro sul tuo server e in nessun caso condividerli con i tuoi clienti.