Can this be achieved with Keystore?
Non penso che si adatti al tuo caso d'uso. Keystore è progettato per memorizzare chiavi crittografiche che verranno utilizzate per la crittografia, la decrittografia e la firma. L'idea è che queste chiavi saranno fuori dalla portata dell'applicazione che le utilizza, quindi in pratica, se hai bisogno di qualcosa firmato o crittografato, chiami una funzione di sistema che ha accesso al keya, ma non puoi ottenere le chiavi da solo. Questo li protegge dalle applicazioni compromesse. Questo non funziona per te, dal momento che devi accedere al token di accesso stesso.
Se si utilizza Keystore per crittografare e decrittografare il token di accesso, questo proteggerebbe il token di accesso da altri processi (o dall'estrazione da parte del software legale dal file system), ma si veda la scadenza del token di accesso più in basso ...). Ciò migliorerebbe sicuramente la sicurezza. Ma se la tua app è stata compromessa, un utente malintenzionato avrebbe comunque accesso al token di accesso decrittografato.
Is there a more secure way than using localstorage?
Direi che se si vuole proteggere contro qualcuno con accesso root e / o un'applicazione compromessa, allora no. Non è possibile proteggere un segreto da root, indipendentemente da dove lo si archivia sul dispositivo, tranne forse nell'hardware della piattaforma di calcolo attendibile (questo non è esattamente vero - i sistemi Linux supportano le funzionalità di sicurezza che root ha per impostazione predefinita, ma può essere negato dal kernel se così configurato - ma penso che non sia molto rilevante per questa discussione)
Il problema con la protezione da root è che la root ha accesso a tutto ciò a cui può accedere l'app, quindi anche se si cripta il proprio token di accesso, root avrebbe accesso alla chiave di crittografia e potrebbe decodificarlo. Lo stesso vale quando la tua applicazione è compromessa.
Un modo per aggiungere un po 'di sicurezza potrebbe essere quello di avere un servizio che è ospitato al di fuori del dispositivo fare un ulteriore livello di crittografia e decrittazione del token di accesso basato su una chiave revocabile, quindi se il dispositivo fosse perso, si potrebbe revocare la chiave associata e quindi il token di accesso crittografato sul dispositivo sarebbe inutile. Ma per questa soluzione, è necessario disporre di due livelli di crittografia, uno sul dispositivo (altrimenti, si aprirà una nuova vulnerabilità inviando token di accesso in testo normale sulla rete a un altro servizio) e uno sul servizio.
Tuttavia, questo mi sembra una quantità ridicola di lavoro per proteggere un token di accesso (potrebbe essere un po 'più sensato per un token di rinnovo longevo). I token di accesso sono generalmente di breve durata e se hai eliminato un token di accesso non appena non ne hai più bisogno, aumenterebbe anche la sicurezza.
La memorizzazione del token di accesso da qualche parte oltre a localstorage potrebbe, tuttavia, essere più sicura rispetto a localstorage perché la memoria locale è accessibile usando javascript, quindi se la tua webview è stata infettata da javascript dannoso, potrebbe rubare il token di accesso. Ma dal momento che il tuo codice nella webview probabilmente ha bisogno di accedervi, sei sfortunato.
BTW: presumo che tu stia parlando di un token di accesso oauth. il giuramento è stato originariamente progettato per risolvere l'autorizzazione per le applicazioni lato server utilizzate dagli agenti utente (browser). oauth 2 lo ha esteso per includere i flussi di autorizzazione e autenticazione per altri scenari, ad esempio applicazioni javascript in esecuzione nel browser o app su dispositivi controllati dagli stessi utenti, ma ci sono alcune persone (l'editor originale della specifica oauth 2 tra questi) che si lamentano del fatto che il supporto di oauth 2 per questi scenari alternativi non è molto buono / sicuro.