Creo que la pregunta aquí debería responderse más desde una perspectiva de marketing que desde una perspectiva de seguridad.
En general, diría que es probable que Google use una clave API relativamente simple para facilidad de uso / accesibilidad, para facilitar que la mayoría de los desarrolladores implementen sus servicios (y ganen dinero con eso).
Amazon probablemente tenga más preocupaciones sobre el uso de su API y utiliza un sistema diferente de claves públicas y secretas. El uso de una clave secreta agrega una cierta protección y no puede considerarse directamente como seguridad por ofuscación (mientras que técnicamente la mayor parte de la seguridad es básicamente una forma de ofuscación).
Para responder a su pregunta en el comentario:
En realidad tengo curiosidad por entender por qué alguien querría hacer que el servicio público (lucrativo) sea difícil de usar. Aparte de la complejidad, ¿qué otras ventajas tiene la firma de VS usando una clave?
Dos razones vinieron a mi mente acerca de esto:
La primera es probablemente que da una sensación de seguridad y esto puede ser una razón para que las empresas elijan un servicio más difícil de implementar que un servicio fácil de implementar. Porque se considera "más seguro". Esto plantea la cuestión de si las características de seguridad en realidad están agregando una capa adicional de seguridad o si simplemente complican las cosas innecesariamente.
La segunda es probablemente que puede agregar seguridad extra . Cuando, por ejemplo, usamos un servicio que cobra dinero por cada solicitud y la única autenticación es una clave. Luego, si la clave se filtra, cualquiera puede usar esa API usando mi clave y así me cobrarán. Un ejemplo de una capa de seguridad adicional es una lista blanca de IP en combinación con la clave. Esto mitigó al menos el problema de que cualquiera puede hacer mal uso de mi clave. SSL (HTTPS) agrega una capa de cifrado a la comunicación entre el servidor y el cliente (posiblemente mitigando los ataques de intermediarios). Otras características o medidas posibles pueden ser DNSSEC, cifrado personalizado, marcos de tiempo, caducidad de la clave / credencial, etc., todo esto agrega seguridad real para mitigar diferentes ataques.
Para los proveedores, es (como a menudo con seguridad) una consideración constante entre facilidad de uso y seguridad. Ellos considerarán cosas como:
- ¿Hasta dónde podemos y debemos ir, sin volvernos paranoicos?
- ¿Hasta dónde debemos ir para proteger los servicios (datos) que ofrecemos?
- ¿Todavía es aceptable para los desarrolladores si vamos tan lejos?