2011-01-27 19 views
78

Tengo que implementar seguro RESTful web services. Ya investigué un poco usando Google pero estoy estancado.¿Cómo asegurar los servicios web RESTful?

Opciones:

TLS (HTTPS) +

¿Hay opciones más posibles a tener en cuenta? Si OAuth, ¿qué versión? ¿Incluso importa? De lo que he leído hasta ahora OAuth 2.0 con tokens de portador (es decir, sin firmas) parece ser insecure.

He encontrado otro artículo muy interesante en REST based authentication.

Secure Your REST API... The Right Way

Respuesta

54

Hay otro método, muy seguro. Son certificados de cliente. ¿Sabes cómo los servidores presentan un certificado SSL cuando te contactas en https? Los servidores bien pueden solicitar un cert de un cliente para que sepan que el cliente es quien dicen ser. Los clientes generan certificados y se los entregan a través de un canal seguro (como ingresar a su oficina con una llave USB, preferiblemente una llave USB no troquelada).

se carga la clave pública de los certificados de cliente cert (y el certificado (s) de su firmante, si es necesario) en su servidor web y el servidor web no aceptará conexiones desde cualquier excepto las personas que tener las claves privadas correspondientes para los certs que conoce. Se ejecuta en la capa HTTPS, por lo que incluso puede omitir por completo la autenticación a nivel de aplicación como OAuth (según sus requisitos). Puede abstraer una capa y crear una Autoridad de certificación local y firmar Solicitudes de certificación de los clientes, lo que le permite omitir los pasos 'hacerlos entrar en la oficina' y 'cargar certificados en el servidor'.

¿Duele el cuello? Absolutamente. ¿Bueno para todo? Nop. ¿Muy seguro? Sip.

Sin embargo, confía en que los clientes mantengan sus certificados seguros (no pueden publicar sus claves privadas en línea), y generalmente se usa cuando vende un servicio a clientes en lugar de dejar que nadie se registre y se conecte.

De todos modos, no puede ser la solución que está buscando (que probablemente no es para ser honesto), pero es otra opción.

+0

De acuerdo, ahora estoy confundido cuál es mejor, este enfoque u [otra respuesta] (http://stackoverflow.com/a/4819214/1197317). ¿Podrías elaborar? : D – BornToCode

+0

Su respuesta sería perfecta para los maestros pero es confusa para los novatos. ¿Puede proporcionarnos información detallada o enlaces para leer? –

+0

Si los certificados son autofirmados, ¿sigue siendo "muy seguro"? – Joyce

17

HTTP Basic + HTTPS es un método común.

+0

TLS es imprescindible, por supuesto. Gracias por traer esto! –

+2

No creo que http digest te dé nada más que http basic si ambos están sobre https. – pc1oad1etter

+2

Le invitamos a que agregue información útil sobre los beneficios del resumen de HTTP sin el tono, seriamente. – pc1oad1etter

6

Si elige entre versiones de OAuth, vaya con OAuth 2.0.

tokens OAuth al portador se deben utilizar solamente con un transporte seguro.

tokens OAuth al portador son tan seguros o inseguros como el transporte que cifra la conversación.HTTPS se encarga de proteger contra los ataques de repetición, por lo que no es necesario que el token de portador también evite la repetición.

Si bien es cierto que si alguien intercepta el token de su portador, pueden hacerse pasar por usted al llamar al API, hay muchas formas de mitigar ese riesgo. Si le das a tus tokens un período de vencimiento largo y esperas que tus clientes almacenen los tokens localmente, tienes un mayor riesgo de que los tokens sean interceptados y mal utilizados que si le das a tus tokens una caducidad corta, requieren que los clientes adquieran nuevos tokens para cada sesión, y aconsejar a los clientes que no persistan los tokens.

Si necesita proteger las cargas útiles que pasan por múltiples participantes, entonces necesita algo más que HTTPS/SSL, ya que HTTPS/SSL solo encripta un enlace del gráfico. Esto no es culpa de OAuth.

Los tokens de portador son fáciles de obtener para los clientes, fáciles de usar para las llamadas API y son ampliamente utilizados (con HTTPS) para asegurar API públicas de Google, Facebook y muchos otros servicios.

Cuestiones relacionadas