Autenticazione utente del server REST

Innanzitutto, l'approccio token sembra valido per il tuo caso. Un'opzione è quella di crittografare le informazioni dell'utente (ad es. Id) nel token. Dal lato server, puoi quindi mantenere le cose senza stato. Renditi conto che, a prescindere dai dettagli di come viene generato, questo token è sensibile. Se qualcuno lo ha, possono usarlo per fingere di essere quell'utente finché è valido (proprio come un id di sessione.)

Fino all'ultima parte, non è chiaro quale sia il requisito di accesso. Dici che non vuoi che debbano fare il login ogni poche ore. Quante volte si desidera che debbano effettuare il login ed è basato sull'inattività? Non consiglierei di memorizzare le credenziali poiché altre applicazioni sul dispositivo potrebbero potenzialmente recuperare le credenziali.

Non conosco davvero il caso di utilizzo completo, ma questo mi urla davvero usando una sessione. Normalmente questi sono implementati con un ID univoco inviato al client sotto forma di cookie e memorizzato sul server in un database in memoria come redis o memcached .

Quando un utente registra un nuovo oggetto verrà aggiunto a redis e memorizzato da una chiave univoca con tutte le informazioni utente necessarie, un tempo di scadenza può essere impostato anche qui. L'impostazione di una scadenza rimuoverà automaticamente una chiave dalla cache che renderà la sessione di un utente non valida se ha superato la data di scadenza. Per il tuo caso probabilmente memorizzerebbe solo l'id utente, potrebbe anche essere usato per memorizzare qualsiasi altro dato statico comunemente usato che non debba essere interrogato ogni volta.

Poiché le informazioni sulla sessione sono utili sulla maggior parte degli endpoint, un filtro di livello superiore viene normalmente implementato per interrogare redis per la chiave e memorizzare le informazioni dell'utente sulla richiesta prima che venga eseguita qualsiasi logica handler . Se la chiave non esiste, nella risposta potrebbe essere inviato uno stato di 403 .

Tutto dipende da quale tecnologia lato server stai usando, ma questo schema è molto comune e potrebbe già essere implementato nel framework che stai utilizzando. Ad esempio, ho scritto un pseudo codice in pochi minuti che usa express e il loro oggetto di sessione redis . Solo con poche righe di codice fornisce supporto per la scadenza delle sessioni e sicurezza dei dati dell'utente.

    var session = require('express-session');
var RedisStore = require('connect-redis')(session);

//this is middleware provided by the library which will query 'redis'
// from the request cookie, add the session to the request data and
//update the expiry with user activity.
app.use(session({
    store: new RedisStore({ttl: 10000000}),
    secret: 'keyboard cat'
}));

app.post('login', function(req, resp) {
    var sessionData = doLogin(req);
    //store the session data on the request if login is successful
    if(sessionData) {
        req.session = sessionData;
    }

    resp.send(200);
});

app.post('insert', function(req, resp) {
     var userId = req.session && req.session.userId;
     // use the session data to validate the user
     if(userId) {
        doInsert(req);
        resp.send(200);
     }
     else {
        resp.send(403);
     }
}); 

Solo una nota a margine, normalmente un api non dovrebbe prendere l'utente come parametro per manipolare i dati per un utente in quanto è molto incline all'hacking. Memorizzando le informazioni dell'utente su una sessione e facendo sempre riferimento alle informazioni dell'utente si evita qualsiasi manipolazione non autorizzata dei dati dell'utente.