Qual è il punto dei token di autenticazione sui servizi REST

Question

Qual è il valore dell'utilizzo di un token di autenticazione quando si utilizza un servizio web REST invece di inviare un nome utente, una password su HTTPS/Crittografia ogni volta che si effettua una richiesta?

Comprendo che, ad esempio, OAUTH presenta alcuni vantaggi in quanto non è necessario distribuire la password a terze parti, è possibile passare un token a terze parti fidate che non si desidera condividere il nome utente/password..etc

Ma oltre a questi vantaggi speciali sopra i quali non ho certamente bisogno nel mio caso, perché dovrei usare i token invece di inviare username/password ogni volta.

Questo potrebbe rendere la vita facile per il cliente e non è necessario inviare il nome utente/password ogni volta. Bene, ma ora il cliente deve ricordare il mio token e inviarmi il token ad ogni richiesta. Quindi, invece di ricordare/inviare nome utente/password ora farà lo stesso per i token! Quindi il codice di implementazione del client non ottiene di meno.

Quindi qual è il valore reale qui?

Answer 1

E 'davvero dipende dallo scenario -. È difficile dire senza sapere di più sull'API - ma l'utilizzo dei "token di autenticazione" è tutt'altro che universale, hai ragione che molte API non hanno bisogno (e non li usano). Molte API richiedono semplicemente una chiave API da inviare ad ogni richiesta (spesso tramite HTTPS per evitare che vengano intercettate), o richiedono una chiave API per identificare l'utente e anche una firma digitale con una "chiave segreta" per dimostrare l'identità dell'utente (vedi When working with most APIs, why do they require two types of authentication, namely a key and a secret?).

Nomi utente/password non sono spesso utilizzato nelle API pubbliche perché non sono abbastanza flessibili e non forniscono abbastanza "separazione" tra l'identità dell'utente e l'identità dell'applicazione. Per esempio. ti registri come sviluppatore per utilizzare l'API di Flickr e creare un'app per iPhone che utilizza tale API: vorresti davvero che il nome utente/password dello sviluppatore fossero integrati nell'app? Cosa succede se cambi la tua password in seguito? Che cosa succede se vuoi sviluppare 5 app e tenere traccia dell'utilizzo per loro separatamente ed essere in grado di chiudere qualsiasi app in qualsiasi momento senza influire sugli altri?

Tuttavia, per i casi in cui si desidera veramente identificare solo un utente umano, non un'applicazione (ad esempio un back-end API privato che servirà solo le proprie applicazioni, non un'API pubblica), nella maggior parte degli scenari non lo faccio Non vedo nulla di sbagliato in ciò che hai suggerito, ad es. nome utente/password su HTTPS con ogni richiesta.Oh, a proposito, i token di autenticazione hanno il vantaggio di essere "restrittivi" (possono scadere in un dato momento, possono essere limitati solo a determinate azioni, ecc.), Ma ovviamente questo è utile solo in scenari molto specifici.

ANCHE: Come ha sottolineato l'utente "Dan" sopra, quando si progetta un'API che richiede l'invio del nome utente/password ad ogni richiesta (o con qualsiasi richiesta in realtà, anche se è solo la richiesta di accesso), fare attenzione a come si fa esso. Se utilizzi una tecnica supportata dai browser per impostazione predefinita (ad es. Autenticazione base HTTP), ti stai impedendo di esporre in tutta sicurezza l'API agli utenti di più domini (ad esempio, molto probabilmente la tua API non può mai essere chiamata in modo sicuro direttamente dal browser , cioè dal codice AJAX/Flash/Silverlight).

Questo è un argomento complesso che non può essere spiegato completamente qui, ma ricorda che se l'API si basa su eventuali credenziali di sicurezza che il browser può ricordare e quindi "silenziosamente" si inserisce in ogni richiesta (ad es. , cookie), quindi NON è sicuro abilitare l'accesso tra domini a quell'API utilizzando qualsiasi tecnica cross-domain (CORS, JSONP, crossdomain.xml, ecc.).

Answer 2

Il modo migliore in cui posso rispondere è quello di indirizzarvi alla pagina this che descrive la sicurezza REST. Appartiene al wiki di restlet, non a Jersey, ma può essere applicato a Jersey e sono entrambe implementazioni REST.

Questo viene estratto dal collegamento ho fornito:

"Per la maggior parte della resistenza, il server può presentare al cliente un token di autorizzazione livello di applicazione, un valore opaco che il server possa verificare appartiene all'utente destra autenticato .

• Tale pegno dovrebbe essere difficile per un terzo di calcolare, ad esempio, un MD5 o SHA1 hash server salata della credenziale di identificazione dell'utente.

• per sconfiggere XSRF, Thi Il token a livello di applicazione deve essere trasmesso per mezzo del fatto che l'utente-agente non ritorna automaticamente ad ogni richiesta. Ad esempio, può essere inviata nel codice HTML di un modulo come un campo nascosto, e restituito tramite POST nell'entità forma codificata "