Dovremmo memorizzare accesstoken nel nostro database per oauth2?

Tecnicamente è possibile memorizzare il token di accesso nel database e utilizzarlo per le chiamate API fino alla scadenza. Potrebbe essere più difficile del suo valore, però.

Per prima cosa, come Jonathan nota nel suo commento sopra, ora devi preoccuparti di proteggere il tuo database e i dati in esso contenuti - questi token danno accesso ad alcune informazioni abbastanza privilegiate sui tuoi utenti. Ovviamente, semplicemente la memorizzazione del token nella memoria di sessione potrebbe metterlo su disco, a seconda della configurazione della sessione. È una buona idea tenerlo crittografato mentre non lo stai usando.

Il tuo scenario proposto in merito ai cookie di cancellazione dell'utente e al ritorno è anche un problema. Puoi prendere il token di accesso dal database e reinserirlo nei loro cookie, ma prima di farlo devi assicurarti che siano chi dicono di essere - e ora devi fare un altro livello di password solo per darglieli accesso al token che ti hanno già dato.

Probabilmente stai meglio rieseguire semplicemente il flusso di autorizzazione quando tornano e fai nuovamente clic sul pulsante di accesso. Non è che costoso. Ma se questo è veramente un ostacolo per te, allora la memorizzazione del token è un'opzione. Dovrai solo essere molto attento a risolvere tutti i problemi associati.

Ci stavo pensando e forse ho trovato una risposta che funzionerà per noi, anche se non posso dire se potrebbe funzionare per te.

Nel nostro ambiente, il motivo principale per cui potremmo aver bisogno di utilizzare token di accesso è quello di operare per conto di un utente dopo che alcuni processi automatici o di back-end sono stati completati o in base a una pianificazione. In uno scenario del genere non possiamo semplicemente chiedere all'utente di accedere di nuovo perché l'utente non è coinvolto direttamente in questo flusso di lavoro (avrebbe richiesto che il lavoro fosse fatto ma non è lì quando termina). Quindi dobbiamo avere accesso al token di accesso in qualche modo.

Naturalmente, mi piacerebbe saltare la reauthorization anche se fattibile, se non causa problemi.

Ma non mi piace nemmeno l'idea di archiviare tutto il necessario per utilizzare il token di accesso sul server web. Quindi, anche se crittografo il token di accesso nel database, non allevia le mie paure se la chiave di crittografia è archiviata sul server web. Diamine, ci sono anche il segreto del cliente e l'ID della app, quindi è tutto.

Quindi ecco la mia soluzione proposta, che richiede quattro attori:

Il server web memorizza la stringa di connessione appid, secret e database (ovviamente). Quando riceve un token dell'app, genera una chiave di crittografia simmetrica casuale e crittografa il token di accesso. Il database ottiene il token di accesso crittografato e la chiave di crittografia è memorizzata in un cookie del client . Allo stesso tempo, il server Web invia la chiave di crittografia e l'ID utente al sistema di back-end in coppia.

Quando il client utilizza il sito, è possibile evitare la riautenticazione utilizzando il cookie client per decrittografare il token di accesso nel database; se il cookie scompare, la riautenticazione deve avvenire non importa quale. Il sistema di backend (che avrebbe una superficie di attacco molto più piccola del server web) ha anche una stringa di connessione DB, quindi è l'unico posto in cui tutte le informazioni necessarie dovrebbero risiedere per interagire con le informazioni dell'utente; potrebbe utilizzare le informazioni a volontà per la durata del token di accesso.

Questo lascia al server web solo un accesso temporaneo a qualsiasi token di accesso e il token non viene mai memorizzato sul client. Mi sembra abbastanza sicuro, anche se forse qualcuno direbbe che è troppo ingegnerizzato. Pensieri?

Penso che ci sia una certa confusione circa il token di accesso e il modo in cui viene utilizzato che può causare un problema di sicurezza.

È corretto che i token possano rappresentare un rischio per la sicurezza, ma ciò dipende dalle informazioni che chiedi al servizio. Un elenco di amici contiene più informazioni del nome e del cognome, ad esempio, ma tali informazioni non sono così importanti come le informazioni personali. In entrambi i casi, NON vuoi MAI esporre il token di accesso effettivo, perché è come esporre una password alla tua applicazione.

Ho scelto di creare un "token" secondario, se lo desideri, che contiene un valore di sessione (ad esempio un valore di sessione crittografato nei cookie) che identifica l'utente fino alla scadenza. Quindi ho il token di accesso nel database (probabilmente dovrebbe essere crittografato, solo per sicurezza) che può accedere alle informazioni dell'utente.

Puoi anche recuperare l'ID della persona attraverso il token. Se almeno lo memorizzi nel database, puoi abbinare il token recuperato tramite l'ID della persona. In questo modo quando si scambia un codice per il token di accesso, è possibile confrontare gli ID e trovare il record corretto.

Suggerirei di memorizzare i token se dovessi mai raggiungere il tuo lease massimo su token nell'applicazione che stai utilizzando. Tuttavia, piuttosto che il database, suggerirei di usare Redis. Se un token viene perso, l'app deve essere configurata per continuare a funzionare, quindi non ha bisogno di persistere a lungo termine e Redis è molto più veloce dell'utilizzo del database e ci sono anche alcune semplici implementazioni di Redis che non dovrebbero richiedere molto tempo mettiti al lavoro.