Como usted dice, este es un punto débil potencial. Pero la forma de arreglarlo tiene mucho que ver con la forma en que se implementa la aplicación. p.ej. si se ejecuta como una aplicación java en un contenedor, es posible escribir el token en el montón de la aplicación después de que se haya iniciado. Desde allí es muy difícil de leer sin entrar en el espacio de memoria de Java. Para, digamos, una plataforma de tipo PHP no es un enfoque factible, posiblemente la mejor solución sería utilizar un conjunto de variables de entorno cuando se inicie el servidor web. Es cierto que esta es una propuesta más compleja para mantener las contraseñas POP para miles de usuarios potenciales en lugar de, digamos una contraseña de base de datos única, pero el principio es el mismo. En cuanto a una plataforma compartida ... entonces realmente tiene que ir al sistema de archivos (ver también suphp y open_basedir para php).
Sin embargo, la mayor parte de esta complicación desaparece si le pide al usuario que proporcione la contraseña. Proteger los datos de la sesión contra el espionaje es más fácil que una configuración de todo el sistema, aunque todavía hay problemas potenciales aquí. Si necesita autenticar al usuario independientemente de la instalación de un tercero, o si se conecta a múltiples terceros, entonces podría usar la contraseña del usuario como parte de una clave de cifrado en una base de datos almacenada de tokens de usuarios.
Pero en lugar de preguntar cómo proteger dicha plataforma, está preguntando cómo reducir el riesgo. Sin embargo, si no controla el mecanismo de autenticación de terceros, entonces no tiene la opción de usar otra cosa que no sea simplemente un nombre de usuario / contraseña.
Entonces, la única otra opción que tienes, además de garantizar la seguridad de dios en el extremo delantero, es aumentar tus datos con potes de miel - entonces si ves algún acceso a los botes de miel entonces sabes que ' Probablemente he sido comprometido.