He diseñado un servicio web REST que requiere autenticación. Maneja la autenticación de manera similar a los servicios web de Amazon, a saber: el usuario tiene un ACCESS_KEY (por ejemplo, 'abcd') y un SECRET_KEY (por ejemplo, 'aabbcc'). El SECRET_KEY se usa para crear un TOKEN : un SHA-1 usando la información de solicitud, por ejemplo:
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)
Puedo verificar el TOKEN en el servidor y autenticar la solicitud. Hasta este punto, no creo que haya ningún problema con el modelo de seguridad.
Mi única pregunta es cómo proporcionar el SECRET_KEY al usar el servicio desde una página web. Pensé que podría enviarlo como una variable de JavaScript (la conexión es HTTPS) y simplemente usar esa variable en una función de JavaScript que agregue el encabezado apropiado a cada HTTPRequest . La autenticación inicial se puede realizar utilizando enfoques estándar basados en cookies (por ejemplo, confiar en Django para manejar una sesión).
Entonces, la arquitectura se ve como:
- sesión del sitio web: manejada por Django usando seguridad basada en sesión estándar (
example.com) - La sesión del sitio web recibe a través de HTTPS el
SECRET_KEYcomo una variable global de JavaScript, que se utiliza para agregar los encabezados adecuados a cadaHTTPRequest. - Los
HTTPRequestsestán hechos paraapi.example.com, lo cual es ajeno a la sesión de Django: solo le importa tener los encabezados apropiados.
Creo que este enfoque es seguro, al tiempo que mantiene una API REST completamente sin estado. No uso la autenticación HTTP estándar (básica o compacta) porque no quiero piratear el problema "no se puede cerrar sesión" y quiero mantener la API REST. Estrictamente.
¿Tiene algún comentario con respecto a este enfoque? Si es defectuoso, ¿cómo lograría mis objetivos?
¡Gracias!