web services - tutorial - ¿Cómo asegurar servicios web RESTful?
servicio rest (3)
Tengo que implementar servicios web RESTful seguros. Ya investigué un poco usando Google pero estoy estancado.
Opciones:
TLS (HTTPS) +
- HTTP Basic (pc1oad1etter)
- HTTP Digest
- OAuth two-legged
- un enfoque basado en cookies
- certificados de cliente (Tom Ritter y here )
- Solicitudes firmadas utilizando HMAC y una vida útil limitada
¿Hay más opciones posibles a considerar? Si OAuth, ¿qué versión? ¿Incluso importa? Según lo que he leído hasta ahora, OAuth 2.0 con tokens de portador (es decir, sin firmas) parece insecure .
Encontré otro artículo muy interesante sobre la autenticación basada en REST .
HTTP Basic + HTTPS es un método común.
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).
Cargue la clave pública de certificados cert client (y sus certificados de firmante, si es necesario) en su servidor web, y el servidor web no aceptará conexiones de nadie, excepto las personas que tienen las claves privadas correspondientes para los certs sabe sobre. 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''.
Dolor en 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 se registren y se conecten.
De todos modos, puede que no sea la solución que está buscando (probablemente no sea para ser sincero), pero es otra opción.
Si elige entre versiones de OAuth, vaya con OAuth 2.0.
Los tokens portadores de OAuth solo deben usarse con un transporte seguro.
Los tokens de portador de OAuth son tan seguros o inseguros como el transporte que encripta 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 maneras 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 que pasan por múltiples participantes, necesita algo más que HTTPS / SSL, ya que HTTPS / SSL solo cifra 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 se usan ampliamente (con HTTPS) para asegurar API públicas de Google, Facebook y muchos otros servicios.