Esistono già numerose soluzioni standard per questo tipo di problema, come i token Web di JavaScript. L'architettura per la maggior parte di queste soluzioni è abbastanza semplice: si dispone di un servizio di autenticazione che autentica l'utente e restituisce un token univoco che è crittografato e contiene le informazioni richieste dal servizio. Il server possiede la chiave privata per questo token. Il client quindi effettua chiamate API e passa il token come parametro nella chiamata API. Il servizio utilizza la chiave privata per verificare il token ed eventualmente estrae dettagli aggiuntivi dal toekn per verificare l'autorizzazione, ecc. Spesso il token avrà una data di scadenza e altri dati. Quali potrebbero essere questi dati aggiuntivi dipenderà dalla tua applicazione e dai requisiti che hai. Il componente critico è garantire che la chiave privata utilizzata per crittografare il token sia sicura.
È anche importante garantire qualsiasi soluzione tu adotti, che si adatti alla tua applicazione. Il livello di sicurezza necessario dipende dalla valutazione del rischio e dalla misura in cui è necessario proteggere le cose. Non c'è niente di peggio per l'utente che essere obbligato a passare troppa sicurezza rispetto al valore del servizio offerto.
Raccomando anche di utilizzare una soluzione esistente, ben collaudata e compresa piuttosto che provare a reinventare la ruota. Esistono numerose librerie per server e client per gestire questo tipo di requisito. Questi non sono garantiti per essere sicuri al 100% (mai nulla è). Ad esempio, ci sono stati post recenti riguardanti problemi di sicurezza con le librerie JWT. Tuttavia, il fatto che questi framework siano stati testati ed esaminati per motivi di sicurezza significa che probabilmente otterrete un risultato finale migliore rispetto alla scrittura di qualcosa che non otterrà quell'attenzione aggiunta.