2012-03-04 7 views
14

Estoy buscando construir algunas aplicaciones móviles. Por lo tanto, estas aplicaciones 'hablarán' a mi servidor a través de JSON y a través de REST (por ejemplo, poner, publicar, etc.).¿Cómo manejan las personas la autenticación de api RESTful (tecnología independiente)

Si quiero asegurarme de que una aplicación de teléfono del cliente está tratando de hacer algo que requiera un cierto "permiso", ¿cómo las personas manejan esto?

Por ejemplo:

Nuestro sitio web vende cosas -> TV, el coche de, vestidos, etc. La API permitan a la gente a navegar por la tienda y comprar artículos. Para comprar, necesita para estar 'conectado'. Necesito asegurarme de que la persona que está usando su teléfono móvil es realmente ellos.

¿Cómo se puede hacer esto?

He echado un vistazo a cómo Twitter lo hace con su OAuth ... y parece que tienen una serie de valores en una SOLICITUD PARA ENCUESTAR? Si es así (y me gusta este enfoque), ¿es posible que pueda usar otro tercero como el sitio web para almacenar el nombre de usuario/contraseña (por ejemplo, Twitter o Facebook son los proveedores de OAuth) ... y todo lo que hago es recuperar de alguna manera los datos del encabezado personalizado ... y asegúrese de que existan en mi db .. else ... ¿conseguir que se autentiquen con su proveedor de OAuth?

¿O hay otra manera?

PS. Realmente no me gusta la idea de tener una clave API. Siento que se puede entregar con demasiada facilidad a otra persona, para usarla (lo cual no podemos correr el riesgo).

+0

Hay algunas excelentes respuestas a esta pregunta en: http://stackoverflow.com/questions/5511589/securing-an-api-ssl-http-basic-authentication-vs-signature, y http: // stackoverflow. com/questions/3358501/how-should-i-handle-authentication-in-my-rest-api. – David

Respuesta

9

Nuestro sitio web vende cosas -> TV, el coche de, vestidos, etc. La API permitan a la gente a navegar por los artículos de la tienda y compra. Para comprar, necesita para estar 'conectado'. Necesito asegurarme de que la persona que está usando su teléfono móvil es realmente ellos.

Si esto realmente es un requisito, entonces necesita almacenar identidades de usuario en su sistema. La forma más popular de rastreo de identidad es a través de nombre de usuario y contraseña.

que he tenido un vistazo a cómo Twitter lo hace con su OAuth .. y parece que tienen una serie de valores en un encabezado de la solicitud? Si es así (y me gusta este enfoque), ¿es posible que pueda usar otro tercero como el sitio web para almacenar el nombre de usuario/contraseña (por ejemplo, twitter o Facebook son los proveedores de OAuth) ... y todo lo que hago es de alguna manera recuperar los datos del encabezado personalizado ...y asegúrese de que exista en my db .. else ... haga que se autentiquen con su proveedor OAuth?

Usted está confundiendo dos tecnologías diferentes aquí, OpenID y OAuth (no se sienta mal, muchas personas se disparan en esto). OpenID le permite diferir el rastreo de identificación y autenticación a un proveedor , y luego aceptar estas identidades en su aplicación, como el aceptador o . OAuth, por otro lado, permite que una aplicación (consumidor) acceda a datos de usuario que pertenecen a otra aplicación o sistema, sin comprometer la seguridad básica de otras aplicaciones. Podrías defender a OAuth si quisieras que los desarrolladores de terceros accedan a tu API en nombre de tus usuarios (lo cual no es algo que hayas declarado que quieres hacer).

Para sus requisitos establecidos, definitivamente puede echar un vistazo a la integración de Open ID en su aplicación. Hay muchas bibliotecas disponibles para la integración, pero como pidió una respuesta agnóstica, no voy a enumerar ninguna de ellas.

¿O hay otra manera?

Por supuesto. Puede almacenar los id de usuario en su sistema y usar la autenticación basic o digest para proteger su API. La autenticación básica requiere sólo una (fácilmente computarizada) encabezado adicional en sus peticiones:

Authorization: Basic QWxhZGRpbjpvcGVuIHNlc2FtZQ== 

Si utiliza ya sea básica o la autenticación implícita a continuación, asegúrese de que sus puntos finales de API están protegidas con SSL, ya que de lo contrario las credenciales de usuario pueden ser fácilmente olieron por el aire. También podría ir a la identificación del usuario y, en su lugar, autenticar al usuario de manera efectiva al pagar a través de la información de la tarjeta de crédito, pero eso es una decisión.

3

Como los servicios RESTful utilizan llamadas HTTP, puede retransmitir en HTTP Basic Authentication por razones de seguridad. Es simple, directo y ya es compatible con el protocolo; y si no desea una seguridad adicional en el transporte, puede usar SSL. Los productos bien establecidos como IBM Websphere Process Server utilizan este enfoque.

La otra forma es construir su propio marco de seguridad de acuerdo a las necesidades de su aplicación. Por ejemplo, si desea que su servicio solo sea consumido por ciertos dispositivos, necesitará quizás enviar un token codificado como un encabezado sobre el cable para verificar que la solicitud provenga de una fuente autorizada. Amazon tiene una forma interesante de hacerlo, puedes verificarlo here.

+1

definitivamente no use autenticación básica de HTTP sin SSL, ya que el nombre de usuario y la contraseña se enviarán en texto sin formato. Lea más aquí: http://security.stackexchange.com/questions/988/is-basic-auth-secure-if-done-over-https – mkirk

+0

Creo que construir su propio marco de seguridad solo debe usarse como último recurso, hay muchos buenos marcos existentes que se han probado y probado. – ryanp102694

Cuestiones relacionadas