Posso/dovrei aggiornare un token OAuth2 con ogni richiesta in spring security

Question

Utilizziamo la concessione nome utente-password per connettere il nostro client JS al nostro server REST. In un certo senso il token restituito da oauth/token è la nostra sessione, in quanto consente l'accesso al back-end per un tempo limitato.

Vorremmo aggiornare quella sessione/token ogni volta che facciamo una richiesta al back-end usando il token.

So che c'è questo token di aggiornamento rilasciato dal server e potrei usarlo per aggiornare il mio token dopo che è scaduto.

Il problema è: non voglio renderlo responsabile del client per intercettare l'eccezione scaduta del token e rianalizzarlo o pianificare un aggiornamento prima della scadenza del token. Voglio che il token si aggiorni da solo fino a quando non viene più utilizzato per un periodo di tempo limitato, proprio come una sessione. (Inoltre, non vorrei che emettesse una richiesta di aggiornamento con ogni richiesta "dati", anche se penso di ricordare, un token di aggiornamento è valido solo una volta ..?!)

C'è un modo per farlo in primavera sicurezza o dovrò costruire alcune implementazioni personalizzate del negozio di token o qualunque parte scegliamo?

Dal momento che non riesco a trovare una risposta (quindi il post), sto pensando: forse non è saggio farlo, anche se non riesco a pensare perché. Se riesco a rubare il token, posso anche rubare il token di aggiornamento. Quindi credo che non vedo il punto di avere un token di aggiornamento, in primo luogo ..

EDIT

In risposta alla risposta di Luke Taylor mi clearify nostro caso d'uso.

• Abbiamo un server REST che contiene dati dell'applicazione come persone. ma fornisce anche l'accesso alla nostra gestione dei contenuti e consente ai clienti di pubblicare su Facebook. Incapsula la logica dell'applicazione e la memorizzazione dei dati
• Abbiamo già un'applicazione client completa che ha il proprio livello di sicurezza e giustifica l'accesso ai dati sul nostro server REST tramite il flusso di credenziali del client. Chi può fare ciò che viene deciso dal lato client
• Abbiamo diverse applicazioni medie e piccole come un'app di contatto su Facebook che accedono ai dati sul server REST anche utilizzando le credenziali del cliente
• Stiamo ora sviluppando un'applicazione client utilizzando solo javascript che accederà al livello REST per eseguire tutte le operazioni che l'applicazione Big Client esegue, ma deve anche fornire un mezzo per autenticare i singoli utenti e consentire il multi-tenancy. Pertanto questa nuova applicazione client utilizza la concessione nome utente-password per autenticare e sicurezza a livello metodo per autorizzare gli utenti

Quindi abbiamo un server REST che deve fornire accesso completo alla nostra applicazione attendibile che fa le proprie cose di sicurezza e quello stesso server deve fornire l'accesso per gli utenti della nostra nuova applicazione client javascript multi-tenancy. Nella produzione avremo diversi server REST ciascuno con un proprio database, ma il core sarà sempre lo stesso, quindi in teoria un server dovrebbe essere in grado di gestire tutto.

Answer 1

Voglio il token per aggiornare se stesso fino a quando non viene più utilizzato per un periodo limitato di tempo - proprio come una sessione

Questo in realtà non ha senso (in un contesto OAuth2) . Il token di accesso viene emesso dal server di autorizzazione, che decide per quanto tempo è valido.Viene "utilizzato" in un server di risorse, che può essere completamente separato dal server di autorizzazione, quindi non esiste alcuna funzione in OAuth2 per connettere l'utilizzo con la durata del token. Sarebbe teoricamente possibile hackerare qualcosa insieme che ha reso questo lavoro, ma sembra una cattiva idea.

Se riesco a rubare il token, posso anche rubare il token di aggiornamento. Quindi immagino di non vedere il punto di avere un token di aggiornamento in primo luogo ..

Il token di accesso viene utilizzato ripetutamente e inviato dal client a server diversi dal server di autorizzazione. Il token di aggiornamento viene mantenuto dal client e inviato solo al server di autorizzazione. Un client deve anche autenticarsi per utilizzare correttamente un token di aggiornamento, quindi anche l'id e il segreto del client devono essere compromessi.

Non è chiaro dalla tua domanda perché stai utilizzando OAuth2. Probabilmente dovresti espandere la tua domanda per chiarire questo. Se c'è un solo client e un server REST, perché non utilizzare solo qualcosa come l'autenticazione BASIC su HTTPS?

Inoltre, il client è un'app basata su browser? In tal caso, la concessione nome utente/password non è realmente adatta per l'utilizzo in un client non attendibile.