Oauth2 vs APIKey en una comunicación de servidor a servidor

La clave API / el secreto del cliente tiene más sentido para la comunicación servicio a servicio, que parece ser tu escenario desde lo que recopilo (tu backend a su servicio API).

Habiendo dicho eso, OAuth 2 tiene un flujo de concesión de credenciales de cliente , que puede hacer algún tipo de Autenticación basada en clave API / secreto de cliente / certificado: consulte con su proveedor externo para ver si lo admiten.

Por lo general, OAuth 2 está asociado con el flujo de concesión de código de autorización , lo cual es bueno cuando el agente de usuario es un navegador, ya que fue para lo que fue diseñado, pero no es apropiado para un servicio a otro.

Este es un tema interesante y hay un par de cosas a considerar. Primero tenemos que llegar al proveedor de API, no solo al consumidor.

¿Quién?

La consideración principal es la autenticación frente a la "identidad" y los permisos. Refresco:

• Identidad = Quien dice que eres
• Autenticación = Quién eres realmente
• Permisos = Lo que puedes hacer

Echa un vistazo a esta publicación para obtener más detalles sobre la identificación de la API y los permisos.

Si bien, en este caso, los permisos pueden ser implícitos (donde, en virtud de estar autenticados, puede usar la API), considere esto: como proveedor de una API para un servicio con el nivel de sensibilidad que requieren los pagos, quiero para saber que el consumidor es quiénes dicen que son .

Pasar una clave de API solo confirma que tienes la clave de API: no demuestra que estés autorizado para acceder a la API.

Ahora, tener un Token de acceso de OAuth inicialmente se puede ver de la misma manera, sin embargo, el RFC de OAuth

  

El servidor de autorización DEBE autenticar al cliente siempre que      posible.

OAuth lo habilita al proporcionar el token de actualización, como usted dijo, junto con un URI de redireccionamiento registrado. También sugiere un token de alcance mínimo para todas las solicitudes iniciales y de autenticación.

Esto le da al proveedor de API mucho más control, más visibilidad y, por lo tanto, más confianza en que su API no se ha comprometido.

OAuth también juega muy bien con los permisos. Si la compañía de la pasarela de pago decidiera extender la autenticación para requerir permisos a GET y POST, esto sería menos trabajo y más seguro que si tuviera que intentar vincular una clave a los permisos.

Exposición

Una consideración secundaria pero relevante es qué hacer si la clave API está expuesta.

Sé que quiero poder confiar en la clave, sin embargo, podría haber sido violada. Por lo tanto, también incluyo en la lista blanca la IP de los clientes ... Las IP pueden cambiar, dependiendo de la configuración, y también pueden ser falsificadas ... ¿Cómo puedo saber si la clave se está utilizando de manera infalible o no?

Si la clave API se vuelve a emitir después de la violación, puede ser más fácil para alguien determinar posibles nuevas claves una vez que se conoce la clave inicial. Esto significa que el algoritmo de generación de la clave de los proveedores también puede necesitar un ajuste.

Si se le emitió un token de acceso que de alguna manera quedó expuesto, una vez que se actualice, el usuario no autorizado no podrá volver a autorizarse. Puedo registrarlos, registrar esta solicitud errónea y trabajar con el consumidor para diagnosticar la causa raíz.

Resumen

La clave de la API solo estaba destinada a servir como un form de ID. Como tales, son básicamente mal utilizados cuando se implementan como una medida de seguridad primaria.

Si los consumidores de la API deben estar autenticados, como en el caso de la verificación de la persona que llama y proporcionar acceso a ciertos recursos según esa verificación, OAuth es la mejor opción.

Espero que esto ayude!

NB En aras de los argumentos, asumí que nadie tiene acceso de root a sus servicios internos o red, y todas las comunicaciones por cable se realizan a través de HTTPS.

Sí, eso es cierto, podría suceder. Un ataque de repetición es bastante común, pero hay formas de implementarlo de manera muy segura. Su servidor definitivamente debe usar la supervisión de IP, lo que significa que una vez que se emita el token solo permitirá una IP específica, pero eso no resuelve el problema, ya que el compromiso puede ser desde adentro. La segunda forma es minimizar el tiempo de vencimiento, lo que reduce el riesgo de exposición. Por último, siempre hay WebSockets ... por lo general, se sincroniza lo suficientemente rápido como para emitir un nuevo token por solicitud, lo que elimina la mayoría de los riesgos, ya que es para uso comercial, utilícelo en su propio Vlan dedicado que solo puede acceder al puerto x. ... etc etc

Al final del día, puede hacerlo a prueba de balas todo lo que quiera, aún no puede sobrevivir a un ataque MITM, especialmente si los certificados raíz se han comprometido en su máquina.