Come dici tu, questo è un potenziale punto debole. Ma come lo risolvi ha molto a che fare con il modo in cui l'applicazione è implementata. per esempio. se viene eseguito come applicazione java in un contenitore, è possibile scrivere il token nell'heap dell'applicazione dopo l'avvio. Da lì è molto difficile rileggere senza entrare nello spazio di memoria di java. Per esempio, una piattaforma di tipo PHP non è un approccio fattibile, probabilmente la soluzione migliore sarebbe utilizzare una serie di variabili ambientali all'avvio del server web. Ammetto che questa è una proposta più complessa per mantenere le password POP per migliaia di potenziali utenti piuttosto che, ad esempio, una sola password per il database, ma il principio è lo stesso. Per quanto riguarda una piattaforma condivisa .... allora deve davvero andare sul filesystem (vedi anche suphp e open_basedir per php).
Tuttavia la maggior parte di questa complicazione scompare se chiedi all'utente di fornire la password. Proteggere i dati della sessione dallo snooping è più semplice rispetto a un'impostazione di sistema - anche se qui ci sono ancora dei potenziali problemi. Se è necessario autenticare l'utente indipendentemente dalla funzione di terze parti o ci si connette a più parti terze, è possibile utilizzare la password dell'utente come parte di una chiave di crittografia per un database memorizzato dei token utenti.
Ma invece di chiedere come proteggere tale piattaforma, stai chiedendo come ridurre i rischi. Tuttavia, se non controlli il meccanismo di autenticazione di terze parti, non hai la possibilità di utilizzare altro che semplicemente un nome utente / password.
Quindi l'unica altra opzione che possiedi, ossia quella di garantire la sicurezza di dio al front end, è di aumentare i tuoi dati con i vasi di miele - quindi se vedi qualche accesso ai vasi di miele allora sai che tu sei " probabilmente sono stati compromessi.