Autorizar solicitudes REST

Question

Estoy trabajando en un servicio REST que tiene algunos requisitos:

1. Tiene que ser seguro.
2. Los usuarios no deberían poder falsificar solicitudes.

Mi solución actual propuesta es tener un encabezado de Autorización personalizado que tenga este aspecto (esta es la misma forma en que funcionan los servicios web de Amazon):

Authorization: MYAPI username:signature

Mi pregunta es cómo formar la firma. Cuando el usuario inicia sesión en el servicio, se le proporciona una clave secreta que debe poder usar para firmar las solicitudes. Esto evitará que otros usuarios envíen solicitudes en su nombre, pero no evitará que falsifiquen solicitudes.

La aplicación que utilizará este servicio es una aplicación para iPhone, así que pensé que podríamos tener una clave pública incrustada en la aplicación con la que podamos hacer una firma adicional, pero esto significa que tendremos que tener dos firmas, una para la clave de usuario y otra para la clave de la aplicación?

Cualquier consejo sería muy apreciado, me gustaría entenderlo bien la primera vez.

Answer 1

Creo que la forma más sencilla de hacer esto correctamente sería utilizar la autenticación de clientes HTTPS. El sitio de Apple tiene un tema sobre este tema.

Editar: para manejar la autorización, crearía un recurso separado (URI) en el servidor para cada usuario, y solo permitiría que ese usuario (autenticado) manipule este recurso.

Editar (2014): Apple cambió su software de foro en los últimos seis años; el hilo está ahora en https://discussions.apple.com/thread/1643618

Answer 2

La respuesta es simple: no se puede hacer. Tan pronto como envíe una solución al usuario final, él o ella siempre puede atacar el servidor con el que se está comunicando. La versión más común de este problema es hacer trampa con listas de alta puntuación en juegos Flash. Puede hacer que sea más difícil incrustando algún tipo de cifrado en el cliente y ofuscando el código ... Pero todo el código compilado y ofuscado siempre puede ser descompilado y no confuso. Es solo una cuestión de cuánto tiempo y dinero está dispuesto a gastar y de la misma manera para el atacante potencial.

Por lo tanto, su preocupación es no cómo intentar evitar que el usuario envíe datos erróneos a su sistema. Es cómo evitar que el usuario dañe su sistema. Debe diseñar sus interfaces para que todos los daños causados ??por datos defectuosos solo afecten al usuario que los envía.

Answer 3

¿Qué hay de malo con Autenticación del resumen HTTP ?

Answer 4

Hay una mejor discusión de esto aquí:

Mejores prácticas para asegurar un API / servicio web REST