Estás en lo correcto. La aplicación secreta debe ser secreta y no debe obtenerse fácilmente mediante la ingeniería inversa de su código de cliente.
Facebook usa OAuth, por lo que todo lo que digo aquí también se aplica a todas las aplicaciones que usan OAuth para autorizar y autenticar. El secreto de la aplicación autentica a tu cliente en facebook. Al igual que un nombre de usuario / contraseña autentica a un usuario en un servicio web, los clientes móviles / de escritorio utilizan la clave secreta de la aplicación como credencial para que el servidor valide que es la aplicación de cliente legítimo "real".
Si el hombre malvado obtiene estas entradas, ¿cuál es el peor uso posible que podría realizar?
Podría crear un cliente falso que se parece a su cliente / aplicación y lanzarlo. Los usuarios confiados lo descargarán y lo usarán para conectarse a Facebook. La aplicación falsa aún no obtiene las credenciales de los usuarios (lo cual es bueno) porque la autenticación de las credenciales de los usuarios se realiza en una página de Facebook. Sin embargo, el usuario termina autorizando esta aplicación falsa en facebook. Facebook lo hace feliz porque cree que cualquiera que presente ese secreto eres tú. Como resultado, la aplicación falsa obtiene el 'token de acceso' para el usuario y puede comenzar a publicar comentarios y hacer otras cosas que su aplicación real no pretende hacer.
Así que en resumen, es su valor de reputación lo que está en juego aquí. Otros clientes pueden suplantar como su cliente a Facebook.
Este es un estudio de caso completo de uno de dichos clientes de Twitter que almacenó la clave del consumidor (su equivalente al secreto de la aplicación) en texto sin formato.
Estoy citando una línea de ese blog:
Es muy importante entender que una clave secreta de consumidor comprometida no pone en peligro la seguridad de los usuarios de la aplicación. La clave no se puede usar para obtener acceso a las cuentas de otros usuarios, ya que para acceder a una cuenta individual se requiere un token de acceso que las instancias individuales de la aplicación cliente obtienen automáticamente en nombre del usuario durante el proceso de autorización.
Ahora, ¿cómo proteges el secreto del cliente?
Si se trata de un cliente independiente (como una aplicación móvil), no tiene más remedio que integrarlo de alguna forma. Desafortunadamente para un experto en ingeniería inversa, es solo una cuestión de tiempo antes de que pueda ser descodificado. Después de todo, su en algún lugar allí (de alguna forma) en el cliente . Si el cliente puede volver a calcularlo / ensamblarlo, también lo puede hacer un inversor.
Editar: si la arquitectura de su aplicación lo permite, su servidor puede realizar los pasos de OAuth en nombre del cliente / aplicación móvil. De esta manera, la clave reside en el servidor, realiza todos los pasos de OAuth y pasa el símbolo de acceso a su cliente para usarla para acceder a los datos de Facebook del usuario. En este punto, está haciendo algo muy similar al navegador - servidor web - interacción de facebook descrito aquí . Simplemente reemplace el 'Navegador del usuario' con su 'Aplicación cliente / móvil' y 'Su aplicación' con 'Su servidor' en esa imagen.
Si se trata de algún tipo de aplicación web, esto se puede lograr fácilmente manteniendo la clave solo en el lado del servidor y utilizando flujo del lado del servidor para evitar que se filtre el secreto de la aplicación.
