Ho progettato un servizio web REST che richiede l'autenticazione. Gestisce l'autenticazione in modo simile ai servizi Web Amazon, ovvero: l'utente ha un ACCESS_KEY
(ad esempio, 'abcd') e un SECRET_KEY
(ad esempio 'aabbcc'). Il SECRET_KEY
viene utilizzato per creare un TOKEN
: un SHA-1 che utilizza le informazioni sulla richiesta, ad esempio:
GET path HTTP/1.1
Date: Mon, 23 May 2005 22:38:34 GMT
ACCESS_KEY: abcd
TOKEN: SHA1(SECRET_KEY + ACCESS_KEY + Date + path)
Posso controllare TOKEN
nel server e autenticare la richiesta. Fino a questo punto, non penso che ci sia qualcosa di sbagliato nel modello di sicurezza.
La mia unica domanda è come fornire SECRET_KEY
quando si utilizza il servizio da una pagina web. Ho pensato di poterlo inviare come variabile JavaScript (la connessione è HTTPS) e utilizzare semplicemente tale variabile in una funzione JavaScript che aggiunge l'intestazione appropriata a ogni HTTPRequest
. L'autenticazione iniziale può essere eseguita utilizzando approcci basati su cookie standard (ad esempio, affidandosi a Django per gestire una sessione).
Quindi l'architettura ha il seguente aspetto:
- Sessione del sito Web: gestita da Django utilizzando la sicurezza standard basata sulle sessioni (
example.com
) - La sessione del sito Web riceve tramite HTTPS
SECRET_KEY
come variabile globale JavaScript, che viene utilizzata per aggiungere gli header appropriati a ogniHTTPRequest
. - Il
HTTPRequests
è fatto aapi.example.com
, che è ignaro della sessione di Django: si preoccupa solo di avere le intestazioni appropriate.
Credo che questo approccio sia sicuro, pur mantenendo un'API REST completamente stateless. Non uso l'autenticazione HTTP standard (base o digest) perché non voglio hackerare il problema "non puoi disconnetterti" e voglio mantenere l'API rigorosamente REST.
Hai commenti riguardo questo approccio? Se è difettoso, come realizzeresti i miei obiettivi?
Grazie!