Ejemplos prácticos de autorización de un servicio RESTful?

Hay muchas preguntas (y respuestas) excelentes en S.O. sobre el tema de REST y seguridad. Muchos dicen "a los puristas no les gustará esto, pero bla, bla" ... y luego otros dicen "nunca deberías hacer eso, porque bla, bla".Ejemplos prácticos de autorización de un servicio RESTful?

Pero no he visto la solución que los "puristas" sugieren en la siguiente situación. Entonces mi pregunta es: ¿cuáles son las "soluciones RESTful puras" para el siguiente escenario?

El escenario simple ...

imaginar la construcción de una base de datos/sitio web que permite al usuario gestionar sus recetas favoritas. El sitio web expone una API RESTful para que los usuarios puedan consultar y manipular su lista desde un programa personalizado que desean escribir (que utiliza esta API).

Por lo tanto, el usuario "A" tiene 3 recetas favoritas con el ID "1", "2" y "3".

El usuario "B" tiene 2 recetas favoritas con el ID "4" y "5".

Tenemos que asegurarnos de que si el usuario A envía un comando DELETE al /Recipes/4, obtendrá una respuesta Forbidden (403).

lo que normalmente lo haría ...

Lo que haría normalmente es dar a ellos primero llaman a un método de autenticación, y los envían algún tipo de auth-token que es válido por 30 minutos más o menos. Normalmente, este token se pasa a través de una cookie.

¿Cuál es la solución pura?

¿Es la solución REST pura tener que pasarlo como una variable en la cadena de consulta? Are cookies the devil? ¿Debería el token ser utilizado como un segmento de la URL (a diferencia de un parámetro de cadena de consulta)? ¿Hay algo más que responda esta pregunta con claridad?

Fuente

2012-06-02 Timothy Khouri

Un poco pedantico aquí: Creo que en su caso querría dar un 403, no un 401. La autenticación es con un servicio, pero en su caso el usuario A está _ prohibido_ obtener la receta 4. Sé que no Responde la pregunta exactamente, pero vale la pena señalar. http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html muestra la diferencia. (La reautenticación no ayudará al usuario A a ver la receta 4, de ahí el 403.) –

Correcto - en realidad cualquiera de los dos es un problema ... primero 401 - como en, ¿está autorizado y luego en 403? - como en, ¿cuáles son sus "permisos"? "- que entra en debates de estado/sesión/usuario-contexto ... de cualquier manera, la pregunta permanece. ¡Gracias por la aclaración! –

Sí, ambos son importantes. La solución más simple es, por supuesto, auth básica sobre https. Creo que eso es "puro". ¿Estás buscando alternativas? –

pasar el token en la cabecera de autorización. Para eso está diseñado. Ver http://greenbytes.de/tech/webdav/draft-ietf-httpbis-p7-auth-12.html

Fuente

2012-06-02 12:26:55

Me gusta la idea, pero parece que usaría el encabezado Autenticación posiblemente ... Seguiré buscando para ver si esto es "correcto" :) –

@TimothyKhouri ¿Qué estás viendo que te hace pensar que estarías haciendo un uso indebido del encabezado de autenticación? –

Ese encabezado parece ser específico para Autenticación de Acceso Básico y Digestivo: http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.8 –

Una simple solución sin estado y sin cookies le daría a cada uno de sus usuarios un token idéntico.

Existen formas de generar esos tokens para que sean lo suficientemente escasos como para preocuparse por la seguridad.

p. Ej. https://www.grc.com/passwords.htm

suponga que tiene los usuarios A y B. generar un token X para el usuario A y un token Y para el usuario B.

lo tanto, el usuario A se usa algo como /X/Recipes/1

y el usuario B usará algo como /Y/Recipes/4

Es seguro porque el usuario A es el único que conoce su token y como he mencionado antes, la forma en que genera tokens puede asegurar que sea "imposible" que los demás adivinen ese token.

Así que si alguien más, como el usuario B usa algún otro token en la url, digamos /Z/Recipes/1, debería ser capaz de reconocer y devolver un mensaje de error correspondiente.

Puede dejar que el usuario entregue el token en la url, como mostré anteriormente, o incrustarlo en la solicitud HTTP como mensaje de Authentication.

Fuente

2012-06-02 02:48:52 xvatar

¿Quieres decir un token único, verdad? Si todos tienen tokens idénticos, entonces cualquiera puede eliminar cualquier cosa ... – evanmcdonnal

No me sigo ... Creo que la pregunta aún persiste: ¿cómo están entregando esa "contraseña"? ¿Es con cada solicitud en la cadena de consulta, publicación, cookie, etc. - Esta solución tiene las mismas preguntas. –

@TimothyKhouri ver mis actualizaciones arriba, hágamelo saber si eso responde a su pregunta .. – xvatar

Tratar el token de autenticación como recurso.

Se autentica mediante la obtención de un token de autenticación con los parámetros que son credenciales (autenticación básica sobre https, por ejemplo).

Salir por DELETE'ing el recurso token de autenticación que tienes al iniciar la sesión.

Fuente

2012-06-02 03:09:05 matb33

Correcto, pero cómo pasan el token es la misma pregunta. ¿Es a través de la cadena de consulta, el encabezado, etc, etc. Siento que he repetido este comentario 4 veces ahora - claramente esta es una pregunta que no ha sido (claramente) respondida. Además, ¿eso es válido/puro para que pasen el token a través de un encabezado o una cookie? –

A través del encabezado. Esto debería ser útil: http://stackoverflow.com/questions/549/the-definitive-guide-to-forms-based-website-authentication. Eso se aplica a cualquier enfoque, RESTful o no.Con un enfoque RESTful puro, el token de autenticación se trata como un recurso para que no sea un RPC extraño – matb33

Ejemplos prácticos de autorización de un servicio RESTful?

Respuesta

Cuestiones relacionadas