Come sempre, hai più di un'opzione e quella giusta dipende dallo scenario esatto, ma per esempio potresti:
-
Supporta la concessione delle credenziali del client OAuth 2.0 nel server di autorizzazione in modo che i servizi di back-end possano richiedere i token per proprio conto senza coinvolgere l'utente
(fonte: Concessione di credenziali client )
-
Supporta un meccanismo di scambio di token che consentirebbe un servizio back-end per scambiare il token di accesso ricevuto con un altro che potrebbe consentire di chiamare altri servizi utilizzando la rappresentazione o la delega dell'utente.
Nello scenario 1, dato che i servizi potevano richiedere un token ogni volta che richiesto, la scadenza sarebbe un non-problema.
Per lo scenario 2, poiché i token venivano emessi per servizi back-end di cui ci si fida e non abbandonerebbero mai il limite lato server, la durata del token ottenuto potrebbe essere molto maggiore di quella utilizzata nel token di accesso disponibile per l'applicazione web che risolve anche il tuo problema di scadenza.
Ricorda inoltre che lo scenario 1 richiederebbe che i tuoi servizi abbiano la possibilità di essere richiamati con un token associato all'utente o con un token associato al servizio, quindi potrebbe richiedere una logica aggiuntiva.
In relazione all'approccio del token di aggiornamento, i token di aggiornamento non vengono di solito rilasciati per le applicazioni basate su browser a causa dei maggiori rischi di perdite.