2010-10-05 13 views
7

Estoy trabajando en una API REST que será utilizada por los desarrolladores que escriben aplicaciones móviles. Los usuarios podrán usar servicios de terceros (Google, Twitter, etc.) para autenticarse, esto es manejado principalmente por OAuth (dependiendo del servicio en cuestión). Usamos OAuth de 2 patas entre la aplicación cliente y el servidor API (donde la clave/secreto del consumidor es específico de la aplicación, el desarrollador la obtiene de nuestro sitio cuando la aplicación se registra allí).Cómo implementar una API REST sin estado

Mi problema es cómo manejar el seguimiento de la autenticación del usuario de forma apátrida. No tengo las credenciales de los usuarios para enviar en cada solicitud. Podría crear un session_id único cuando un usuario inicie sesión y luego lo requiera en cada solicitud a la API REST. ¿Hay alguna otra solución a mi problema? ¿Usar un session_id único para identificar al usuario causa problemas desde una perspectiva de API REST sin estado?

+2

Todavía estoy digiriendo este buen artículo de John Wilander. Tal vez pueda ayudarte también. http://appsandsecurity.blogspot.com/2011/04/rest-and-stateless-session-ids.html – RayLuo

Respuesta

10

Descargo de responsabilidad: No soy de todos modos un experto en seguridad.

No lo llame session_ID. Llámalo un token de autenticación y pásalo por el encabezado HTTP de Autorización usando tu propio esquema de autenticación. Vea el Google AuthSub para un ejemplo.

No use este token de autenticación para nada que no sea identificar al usuario y determinar si está autorizado a realizar la solicitud. No asocie ningún estado al token y no recupere las preferencias del usuario en función de él.

+0

Gracias por la entrada – Andreas

+1

Solo para verificar mi comprensión de esto, el token de sesión todavía requiere el estado de sesión en el lado del servidor ? Es decir, el servidor controla la vida útil de la sesión y el token deja de ser válido después de un tiempo de espera de sesión en el servidor. Estoy buscando una manera de lograr un objetivo similar sin tener el concepto de una "sesión" en el servidor. – Aron

+1

Esto es también lo que realmente no entiendo. Todo el mundo habla de seguridad y apatridia, pero una sesión para el usuario debe llevarse a cabo en el servidor de todos modos. – Gambo