Mentre leggevo la tua domanda, ho provato senza successo a cercare su Internet come i token Bearer sono crittografati o firmati. Immagino che i token al portatore non siano sottoposti a hash (forse parzialmente, ma non completamente) perché in tal caso, non sarà possibile decrittografarlo e recuperare le proprietà degli utenti da esso.
Ma la tua domanda sembra cercare di trovare risposte sulla funzionalità del token Bearer:
Supponiamo che io stia implementando un fornitore di autorizzazione, posso fornire qualsiasi tipo di stringa per il token al portatore? Può essere una stringa casuale? Deve essere una codifica base64 di alcuni attributi? Dovrebbe essere hash?
Quindi, proverò a spiegare come funzionano i token Bearer e i token di aggiornamento:
Quando l'utente richiede al server un token che invia l'utente e la password tramite SSL, il server restituisce due elementi: un token di accesso e un token di aggiornamento .
Un token di accesso è un token Bearer che dovrai aggiungere in tutte le intestazioni di richiesta per essere autenticato come utente concreto.
Authorization: Bearer <access_token>
Un token di accesso è una stringa crittografata con tutte le proprietà dell'utente, i reclami e i ruoli desiderati. (È possibile verificare che la dimensione di un token aumenti se si aggiungono più ruoli o attestazioni). Una volta che il server delle risorse riceve un token di accesso, sarà in grado di decrittografarlo e leggere queste proprietà dell'utente. In questo modo, l'utente verrà convalidato e concesso insieme a tutta l'applicazione.
I token di accesso hanno una scadenza breve (ovvero 30 minuti). Se i token di accesso fossero scaduti, sarebbe un problema, poiché teoricamente non è possibile revocarli. Quindi immagina un utente con un ruolo = "Admin" che cambia in "Utente". Se un utente mantiene il vecchio token con role = "Admin", sarà in grado di accedere fino alla scadenza del token con diritti di amministratore. Ecco perché i token di accesso hanno una scadenza breve.
Ma viene in mente un problema. Se un token di accesso ha una scadenza breve, dobbiamo inviare ogni breve periodo l'utente e la password. È sicuro? No, non lo è. Dovremmo evitarlo. Questo è quando i token di aggiornamento sembrano risolvere questo problema.
I token di aggiornamento sono memorizzati nel DB e avranno una scadenza lunga (esempio: 1 mese).
Un utente può ottenere un nuovo token di accesso (quando scade, ad esempio ogni 30 minuti) utilizzando un token di aggiornamento, che l'utente ha ricevuto nella prima richiesta di un token. Alla scadenza di un token di accesso, il client deve inviare un token di aggiornamento. Se questo token di aggiornamento esiste nel DB, il server restituirà al client un nuovo token di accesso e un altro token di aggiornamento (e sostituirà il vecchio token di aggiornamento con quello nuovo).
Nel caso in cui un token di accesso utente sia stato compromesso, il token di aggiornamento di tale utente deve essere eliminato dal DB. In questo modo il token sarà valido solo fino alla scadenza del token di accesso perché quando l'hacker tenta di ottenere un nuovo token di accesso inviando il token di aggiornamento, questa azione verrà negata.