Autenticación de servicio RESTful

Question

Según la especificación REST, se supone que el servicio es apátrida; pero luego se vuelve difícil habilitar la autenticación. Algunas de las cosas que he leído decían que "hacer que REST tenga estado no es el fin del mundo". Pero ese no es el punto, el punto es seguir las especificaciones y ser consistente.

Entonces, estoy haciendo esta pregunta aquí con la esperanza de que alguien pueda guiarme en la dirección correcta. Estoy trabajando con Spring MVC para crear un servicio REST. No tengo puntos de vista Es un verdadero servicio REST que consume/produce JSON. Necesito tener un mecanismo de autenticación (y autorización en el camino) para esta aplicación que es sin estado y sigue la especificación REST. El cliente se escribirá en JavaScript (Backbone.js, CoffeeScript) y aceptará el nombre de usuario/contraseña de un Usuario. Luego publicará esa información en el servidor.

¿Cómo puedo lograr autenticación autenticada sin estado (y autorización) en una aplicación basada en Spring?

autenticación implícita sobre SSL - ¿Es este el camino a seguir?

Answer 1

La administración de sesiones es diferente de la administración del estado.

El lado del servidor durante el intercambio de información puede generar un token y cada vez que el cliente realiza una llamada tendrá que agregar ese token a la cabeza o para que su servidor pueda analizar y decidir si puede permitir llamar para continuar

El servidor no necesita mantener ningún estado para verificar la validez de ese token que se puede hacer utilizando algún algoritmo.

Answer 2

¿Has visto cómo funciona Spring Security? Utilicé Spring Security y pude agregar encabezados de autorización HTTP personalizados desde el cliente en la solicitud REST. Esto se extrae del lado del servidor, el usuario solicitante se autentica y es posible autorizar el acceso a recursos específicos.

Answer 3

Puede utilizar autenticación básica o implícita sobre SSL, ninguna de las cuales implica nada significativo sobre el estado. También puede haber una cookie enviada por el servidor, que su cliente deberá enviar de vuelta cuando realice más solicitudes (I cree que el código Javascript manejará todo eso por usted). Existen otros mecanismos de autenticación posibles, pero son más complejos y no necesariamente adecuados. (La otra clave propia sin estado es SSL autenticada por el cliente, pero eso requiere que el navegador tenga instalado un par de llaves SSL del cliente y que el servidor sepa qué significa esa identidad y es bastante más complejo de implementar)

En el lado del servidor, use Spring Security ya que eso hace que sea bastante fácil manejar todo esto. Funciona bien con Spring MVC.