Invio di token di accesso non in scadenza su ogni richiesta vs utilizzando token di aggiornamento?

Question

Invio di token di accesso non in scadenza su ogni richiesta vs utilizzando token di aggiornamento?

#1 da (1 voti)

5

Quando si proteggono le API REST per le applicazioni mobili, ciò che si vede spesso è l'uso di token di aggiornamento. Esistono perché:

I token di accesso hanno una data di scadenza.
Non vogliamo che l'utente debba inserire le sue credenziali.

I token di aggiornamento sono token revocabili senza date di scadenza che possono essere utilizzate per recuperare un nuovo token di accesso quando quest'ultimo è scaduto. Vedi qui .

Su tutte le tue chiamate API, verrà inviato il token di accesso (valido). Quando è scaduto, usi la "chiave speciale" (il token di aggiornamento) per ottenere un altro token di accesso non scaduto.

In che modo questo modello ampiamente utilizzato è in ogni caso inferiore o diverso dall'emissione di un token di accesso non scaduto e dall'archiviazione nel dispositivo, nello stesso modo in cui avresti memorizzato il tuo token di aggiornamento?

PS: Se la tua risposta è che l'invio del token non in scadenza su ogni richiesta è meno sicuro (middle man), direi: è davvero quando la tua API è su HTTPS? Inoltre, fai invia un token senza scadenza sulla stessa rete, lo chiami semplicemente "token di aggiornamento" e invialo meno spesso).

PS2: se la tua risposta si riferisce alla possibilità di revocare i token di aggiornamento, suppongo che potrei sostenere che potremmo rendere anche revocabili i nostri token di accesso.

api rest authentication token

posta lapin 02.05.2016 - 14:58

fonte

1 risposta

Leggi altre domande sui tag api rest authentication token

Quale codice a blocchi dovrebbe essere usato in TLS 1.2 (tenendo in mente 1.3)? Il riempimento di PKCS 1.5 consente a un utente malintenzionato di estrarre la chiave privata o no? PKCS 1.5 è sicuro da usare nel contesto dell'autenticazione?

score 1 · Answer 1

Quando si lavora, ad esempio, con token JWT, i token sono autofirmati.
Ciò significa che resource service può verificare l'integrità del token senza dover comunicare con authentication server . Che va bene con% di breve durata% co_de.
Ma quando access tokens verrà utilizzato per acquisire un nuovo refresh token da access token , authentication server potrebbe eseguire una maggiore convalida, come verificare se la sessione è stata revocata o se l'account dell'utente è ancora attivo, è ancora attivo e ha ancora i diritti per accedere a authentication server per cui emetterà un nuovo resource service .

In tal caso, l'utilizzo dei token di aggiornamento e accesso può aiutare a implementare meccanismi di convalida più semplici per i token di accesso di breve durata, consentendo una risposta più rapida dal server delle risorse.