¿Por qué necesitamos la seguridad del servicio REST si tenemos HTTPS?

Me refiero a este excelente artículo http://www.thebuzzmedia.com/designing-a-secure-rest-api-without-oauth-authentication/ que habla de amazon como seguridad para el servicio web. Sin embargo, me hicieron una pregunta en el equipo sobre por qué la necesitamos si ya usamos HTTPS. No pude responder ya que realmente me parece que pueden estar en lo cierto, aunque el instinto me dice lo contrario.

¿También hay lugares al proporcionar servicios REST donde HTTPS puede no funcionar? ¿Te gustan los sitios web de terceros?

Si alguien tiene experiencia en la seguridad de los servicios web a través de las redes públicas, arroje algo de luz con su experiencia.

Gracias por adelantado.

EDITAR: Para aclarar, no estoy hablando de autenticación de usuario, sino más de autenticación de cliente. Se puede suponer que la autenticación del usuario es texto sin formato a través de HTTPS + REST.

Mi preocupación es que esto todavía permite que cualquiera pueda usar el servicio web sin que mi cliente acceda a él, ya que todo es texto simple, aunque a través de HTTPS el punto final del cliente aún puede usar mi servicio web sin la aplicación del cliente.

¿Por qué necesitamos darle a Gmail, o cualquier otro sitio con cuentas de usuario, nuestro nombre de usuario y contraseña si ya está usando HTTPS? La respuesta es la misma que la respuesta a su pregunta.

HTTPS proporciona, ante todo, una conexión cifrada entre el servidor y el cliente.

La confianza inherente en HTTPS se basa en las principales autoridades de certificación que vienen preinstaladas en el software del navegador (esto equivale a decir "Confío en la autoridad de certificación (por ejemplo, VeriSign / Microsoft / etc.) Para decirme en quién debo confiar").

A menos que el servidor otorgue a cada usuario un certificado , el servidor no puede confiar en el cliente sin algún otro método de autenticación.

HTTPS es muy bueno para prevenir escuchas y ataques de "hombre en el medio". Como encripta todo el tráfico para una sesión.

Pero como la mayoría de las personas están usando los certificados predeterminados que vienen con su navegador y no tienen idea de cómo crear su propio certificado personal o configurar el navegador para usarlo.

Esto hace que HTTPS sea bastante inútil para la autenticación de usuarios que no sea proteger un diálogo de autenticación de escuchas, etc.

HTTPS se trata de asegurar el canal, no probar quién es la persona que llama o las muchas otras cosas que debe tener en cuenta. La autenticación, la autorización y el cifrado de la capa de transporte son solo una pequeña parte de lo que debe tener en cuenta. Muchas de las vulnerabilidades conocidas relacionadas con las aplicaciones web se aplican mucho a las API REST. Debe tener en cuenta la validación de entrada, el craqueo de sesión, los mensajes de error inapropiados, las vulnerabilidades internas de los empleados, etc. Es un gran tema.

Robert

Puede adoptar el enfoque de los certificados SSL del cliente y separar la seguridad de la API. El gran inconveniente de este enfoque es la sobrecarga de la operación, que se volverá costosa a medida que más y más clientes consuman su API.

En cualquier caso, la autenticación básica HTTP está bien para la gran mayoría de los servicios de consumo público.