web services - services - ¿Cómo implemento el inicio de sesión en un servicio web RESTful?

servicios rest ejemplo (6)

Como ya señaló S.Lott, tenemos dos cosas dobladas aquí: inicio de sesión y autenticación

La autenticación está fuera de alcance aquí, ya que esto se discute ampliamente y existe un acuerdo común. Sin embargo, ¿qué necesitamos realmente para que un cliente se autentique con éxito contra un servicio web RESTful? Bien, algún tipo de token, vamos a llamarlo token de acceso.

Cliente) Entonces, todo lo que necesito es un token de acceso, pero ¿cómo obtenerlo de manera REST?
Servidor) ¿Por qué no simplemente crearlo?
Cliente) ¿Cómo viene?
Servidor) Para mí, un token de acceso no es más que un recurso. Por lo tanto, crearé uno para usted a cambio de su nombre de usuario y contraseña.

Por lo tanto, el servidor podría ofrecer el recurso URL "/ accesstokens", para POSTING el nombre de usuario y la contraseña, devolviendo el enlace al recurso recién creado "/ accesstokens / {accesstoken}". Alternativamente, puede devolver un documento que contiene el token de acceso y un href con el enlace del recurso:

<access-token id="{access token id goes here; e.g. GUID}" href="/accesstokens/{id}" />

Lo más probable es que en realidad no cree el token de acceso como un subrecurso y, por lo tanto, no incluya su href en la respuesta.
Sin embargo, si lo hace, ¿el cliente podría generar el enlace en su nombre o no? ¡No!
Recuerde, los servicios web realmente RESTful unen los recursos de una manera que el cliente puede navegar por sí mismo sin la necesidad de generar ningún enlace de recursos.

La última pregunta que probablemente tenga es si debe ENVIAR el nombre de usuario y la contraseña como un formulario HTML o como un documento, por ejemplo, XML o JSON, depende ... :-)

Estoy construyendo una aplicación web con una capa de servicios. La capa de servicios se construirá utilizando un diseño RESTful. La idea es que en algún momento en el futuro podamos construir otras aplicaciones (iPhone, Android, etc.) que usen la misma capa de servicios que la aplicación web. Mi pregunta es esta: ¿cómo implemento el inicio de sesión? Creo que tengo problemas para pasar de un diseño basado en verbos más tradicional a un diseño basado en recursos. Si estuviera compilando esto con SOAP, probablemente tendría un método llamado Login. En REST debería tener un recurso. Tengo dificultades para entender cómo debería construir mi URI para iniciar sesión. Debería ser algo como esto:

http://myservice/ {username}? p = {contraseña}

EDITAR: la aplicación web front-end utiliza el marco ASP.NET tradicional para la autenticación. Sin embargo, en algún momento del proceso de autenticación, necesito validar las credenciales proporcionadas. En una aplicación web tradicional haría una búsqueda en la base de datos. Pero en este escenario estoy llamando a un servicio en lugar de hacer una búsqueda en la base de datos. Entonces necesito algo en el servicio que validará las credenciales proporcionadas. Y además de validar las credenciales proporcionadas, probablemente también necesite algún tipo de información sobre el usuario después de que se hayan autenticado con éxito, como su nombre completo, su ID, etc. Espero que esto aclare la pregunta.

¿O no estoy pensando en esto de la manera correcta? Siento que estoy teniendo dificultades para describir mi pregunta correctamente.

Corey

Desde bastante ha cambiado desde 2011 ...

Si está abierto a utilizar una herramienta de terceros, y se desvía ligeramente de REST ligeramente para la interfaz de usuario web, considere http://shiro.apache.org .

Shiro básicamente le proporciona un filtro de servlet para autenticación y autorización. Puede utilizar todos los métodos de inicio de sesión enumerados por @ S.Lott, incluida una autenticación basada en formularios simples.

Filtra las URL restantes que requieren autenticación, y Shiro hará el resto.

Actualmente estoy usando esto en mi propio proyecto y hasta ahora ha funcionado bastante bien.

Aquí hay algo más en lo que las personas pueden estar interesadas. https://github.com/PE-INTERNATIONAL/shiro-jersey#readme

Gran pregunta, bien planteada. Realmente me gusta la respuesta de Patrick. Yo uso algo como

- / users / {username} / loginsession

Con POST y GET siendo manejados. Entonces publico una nueva sesión con credenciales y puedo ver la sesión actual como un recurso a través de GET.

El recurso es una sesión de inicio de sesión, y puede tener un token de acceso o código de autenticación, vencimiento, etc.

Por extraño que parezca, mi llamador MVC debe presentar un token de clave / portador a través de un encabezado para demostrar que tiene el derecho de intentar y crear nuevas sesiones de inicio de sesión dado que el sitio MVC es un cliente de la API.

Editar

Creo que algunas otras respuestas y comentarios aquí están resolviendo el problema con un secreto compartido fuera de banda y solo se autentica con un encabezado. Eso está bien en muchas situaciones o para llamadas de servicio a servicio.

La otra solución es enviar un token, OAuth o JWT o de otro modo, lo que significa que el "inicio de sesión" ya se ha realizado por otro proceso, probablemente una interfaz de usuario de inicio de sesión normal en un navegador que se basa en un formulario POST.

Mi respuesta es por el servicio que se encuentra detrás de esa interfaz de usuario, suponiendo que desea iniciar sesión y la administración de autenticación y de usuario se coloca en un servicio REST y no en el código MVC del sitio. ES el servicio de inicio de sesión de usuario.

También permite que otros servicios "inicien sesión" y obtengan un token que expira, en lugar de utilizar una clave precompartida, así como también scripts de prueba en una CLI o un cartero.

He enfrentado el mismo problema antes. El inicio de sesión no se adapta bien al diseño basado en recursos.

La forma en que generalmente lo manejo es tener el recurso de inicio de sesión y pasar el nombre de usuario y la contraseña en la cadena de parámetros, básicamente haciendo

GET en http://myservice/login?u= {username} & p = {password}

La respuesta es algún tipo de sesión o cadena de autenticación que luego se puede pasar a otras API para su validación.

Una alternativa para hacer GET en el recurso de inicio de sesión es hacer un POST, REST los puristas probablemente ya no me quieran :), y pasar los creds en el cuerpo. La respuesta sería la misma.

Lo primero que debe entender acerca de REST es que es un acceso a recursos basado en tokens. A diferencia de las formas tradicionales, el acceso se concede en función de la validación de tokens. En palabras simples, si tiene el token derecho, puede acceder a los recursos. Ahora hay muchas otras cosas para la creación y manipulación de tokens.

Para su primera pregunta, puede diseñar una API Restfull. Las credenciales (nombre de usuario y contraseña) se pasarán a su capa de servicio. Capa de servicio luego valida estas credenciales y otorga un token. Las credenciales pueden ser simples nombre de usuario / contraseña o pueden ser certificados SSL. Los certificados SSL usan el protocolo OAUTH y son más seguros.

Puede diseñar su URI de la siguiente manera: URI para http://myservice/some-directory/token > http://myservice/some-directory/token ? (Puede pasar Credentilals en este URI para Token)

Para usar este token para el acceso a los recursos, puede agregar esto [Authorization: Bearer (token)] a su encabezado http.

El token puede ser utilizado por el cliente para acceder a diferentes componentes de su capa de servicio. También puede cambiar el período de caducidad de este token para evitar el uso indebido.

Para su segunda pregunta, una cosa que puede hacer es otorgar token diferente para acceder a diferentes componentes de recursos de su capa de servicio. Para esto puede especificar un parámetro de recurso en su token y un gran permiso basado en este campo.

También puede seguir estos enlaces para obtener más información: http://www.codeproject.com/Articles/687647/Detailed-Tutorial-for-Building-ASP-NET-WebAPI-REST

http://www.vinaysahni.com/best-practices-for-a-pragmatic-restful-api

Usted no "inicia sesión". Usted "autentica". Mundo de la diferencia

Tienes muchas alternativas de autenticación.

Autenticación de HTTP Basic, Digest, NTLM y AWS S3

HTTP básico y autenticación implícita. Esto usa el encabezado HTTP_AUTHORIZATION . Esto es muy lindo, muy simple. Pero puede generar mucho tráfico.
Autenticación de nombre de usuario / firma. A veces se llama autenticación "ID y KEY". Esto puede usar una cadena de consulta.
?username=this&signature=some-big-hex-digest

Esto es lo que usan lugares como Amazon. El nombre de usuario es el "id". La "clave" es un resumen, similar al utilizado para la autenticación HTTP Digest. Ambas partes tienen que acordar el resumen para proceder.
Algún tipo de autenticación basada en cookies. OpenAM , por ejemplo, se puede configurar como un agente para autenticarse y proporcionar una cookie que tu servidor web RESTful puede usar. El cliente se autentica primero y luego proporciona la cookie con cada solicitud RESTful.