¿Cómo asegurar los servicios web RESTful?

Tengo que implementar servicios web RESTful seguros . Ya hice algunas investigaciones con Google pero estoy atascado.

Opciones:

TLS (HTTPS) +

• HTTP básico (pc1oad1etter)
• HTTP Digest
• OAuth de dos patas
• un enfoque basado en cookies
• certificados de cliente (Tom Ritter y aquí )
• Solicitudes firmadas mediante HMAC y una vida útil limitada

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

Encontré otro artículo muy interesante sobre la autenticación basada en REST .

Asegure su API REST ... de la manera correcta

Hay otro método muy seguro. Son certificados de cliente. ¿Sabe cómo los servidores presentan un certificado SSL cuando se comunica con ellos en https? Bueno, los servidores pueden solicitar un certificado 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 sin troyanos).

Usted carga la clave pública de los certificados de cliente de certificado (y el certificado (s) de sus firmantes, si es necesario) en su servidor web, y el servidor web no aceptará conexiones de nadie excepto de las personas que tienen las claves privadas correspondientes para los certificados. conoce. Se ejecuta en la capa HTTPS, por lo que es posible que incluso pueda 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 certificado de los clientes, lo que le permite omitir los pasos de "hacer que entren en la oficina" y "cargar certificados en el servidor".

¿Dolor de cuello? Absolutamente. ¿Bueno para todo? ¡No! ¿Muy seguro? Sip.

Sin embargo, depende de 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 permitir que cualquiera se registre y se conecte.

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

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

Si elige entre las versiones de OAuth, elija OAuth 2.0.

Los tokens de portador de OAuth solo deben usarse con un transporte seguro.

Los tokens de portador de OAuth 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 se proteja contra la repetición.

Si bien es cierto que si alguien intercepta su token de portador puede hacerse pasar por usted al llamar a la API, hay muchas formas de mitigar ese riesgo. Si otorga a sus tokens un período de vencimiento prolongado y espera que sus clientes almacenen los tokens localmente, tiene un mayor riesgo de que los tokens sean interceptados y mal utilizados que si les da a sus tokens un vencimiento corto, requiere que los clientes adquieran nuevos tokens para cada sesión, y aconsejar a los clientes que no conserven los tokens.

Si necesita proteger las cargas útiles que pasan por varios participantes, entonces 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 los clientes para llamadas API y se usan ampliamente (con HTTPS) para proteger las API públicas de Google, Facebook y muchos otros servicios.