Para resumir:
- Usted tiene una clave API emitida por un proveedor para que pueda usar su API, y tiene la obligación de evitar que otra persona conozca esta clave
- Está realizando llamadas a la API de ese proveedor (que requiere la clave API) en el código de su aplicación
- Está implementando la aplicación en sistemas donde los clientes tienen acceso a los archivos binarios y, por lo tanto, podrían descompilar / desofuscar el código o interceptar el tráfico.
La mejor manera de evitar el compromiso de esta clave es mantener el control. Esto significa que nunca debe implementarse en un servidor donde cualquier persona además de usted pueda leer el binario, y nunca pasar por un enlace de comunicación que no controle.
En última instancia, si los archivos binarios están fuera de su control, todo en ellos está fuera de su control. Del mismo modo, si alguien puede interceptar el tráfico, puede capturar la clave API ( potencialmente incluso si está utilizando SSL ).
Puedo ver dos formas principales de lograr esto, las cuales no incluyen su clave API privada en su aplicación implementada:
Obtenga una clave API única para cada implementación
Esto requeriría alguna relación adicional con el proveedor, donde puede obtener claves o hacer que sus clientes obtengan claves.
Esto es bastante común con, por ejemplo, productos que usan la API de Google Maps. El creador del software tiene su propia clave que usa al desarrollar / ejecutar su copia, pero no la incluye en el software y, en cambio, le exige, como usuario que instala dicho software, que vaya a Google y obtenga su propia API llave. El software simplemente tiene una opción de configuración para configurar la clave API de Google Maps para usar.
De hecho, muchos proveedores que emiten claves API contractualmente requieren que haga las cosas de esta manera, por lo que incluso puede estar en el camino equivocado de todos modos, y esta puede ser la única solución que puede usar de acuerdo con los Términos de servicio del proveedor y / o cualquier contrato legal que pueda tener con ellos.
Use un proxy
Configure una API proxy, donde su aplicación llama a su API (en sus servidores) y, a su vez, su API llama a la API del proveedor utilizando la clave.
Es posible que necesite protección adicional en su API, por ejemplo, algo para asegurarse de que solo su aplicación la esté utilizando. Esto podría hacerse por:
- haciendo que la funcionalidad sea tan específica, solo tu aplicación puede usarla
- Listas blancas de IP
- Algunos mecanismos existentes de licencia / autorización que ya tiene para sus servidores
- Su propio sistema de claves API donde puede emitir claves a sus clientes
Lo que hay que tener en cuenta aquí es que es posible que no se le permita hacer esto. Su proveedor puede tener Términos de servicio o contratos legales que le impiden construir un "servicio de agregación" o proxy, por lo que debe verificarlo.
Manejar el mal comportamiento
Incluso si su clave no se ve comprometida, si uno de sus clientes está haciendo algo que hace que el proveedor bloquee su clave, de repente TODOS sus clientes están deshabilitados, y su única solución es actualizar a todos los demás.
Del mismo modo, si usted quiere bloquear uno de sus clientes (por ejemplo, dejaron de pagar, los piratas de software, etc), entonces usted no puede hacerlo sin la emisión de una actualización de todos los demás, y luego la desactivación de la llave.
La logística de esto para cualquier cosa más allá de un puñado de clientes se volverá rápidamente insostenible.
Ya sea que actúe como un proxy o tenga una clave única para cada instalación, puede manejar cualquiera de estas situaciones con relativa facilidad (y con poco o ningún impacto para nadie más).
Intentar proteger la clave mientras está incrustado en su software es, en última instancia, un esfuerzo inútil. No importa lo que haga, cualquier atacante que tenga acceso a los binarios, la fuente y / o el canal de comunicaciones y esté lo suficientemente determinado como para llegar a su clave podrá hacerlo.
Así que no lo incrustes. "El único movimiento ganador es no jugar."