Ho clienti che sono tutti i browser. Tutti i client eseguono il rendering di una sola applicazione per ottenere dati da un'API Web. Il design dell'API segue i principi REST.
Uso l'autenticazione basata su token senza OAuth perché non ho terze parti per la mia API e voglio sentire in che modo la sicurezza può danneggiare la mia mente; -)
Il formato del mio token I è JSON Web Token (JWT): contiene userId, lifetime (data di scadenza), emittente e chiave di firma (alg: HS256 che è hash SHA-256 algo)
Il token è valido 7 giorni. Quindi l'utente deve riautentarsi ogni 7 giorni. (Forse non è ancora la soluzione finale in questo campo ...)
Questo è il mio flusso di autenticazione:
1) Uso l'autenticazione di base su SSL per il mio endpoint di accesso
2) Se il nome utente e la password inviati dall'utente sono validi, inserisco un token nella risposta
3) Questo token è memorizzato nella memoria locale / di sessione sul lato client
4) Ogni ulteriore richiesta a un endpoint di risorsa dell'API del server deve includere un token valido altrimenti la richiesta ottiene un 401 e vede di nuovo la vista di accesso.
5) Prima di svolgere ulteriori indagini con il token come controllare la data di scadenza, devo sapere se l'autenticità del token è ancora valida o se un utente legittimo lo ha modificato. Ciò presuppone che il token sia stato firmato con una chiave prima della quale chiamiamo MAC (Message Authentication Code)
Convalidare il token con la stessa chiave di firma il token è stato firmato durante la creazione del token. Conservo la chiave di firma che è un gruppo di numeri generati casualmente nella tabella sql dell'utente che appartiene all'ID utente. L'utente che ottengo dal token vede sopra. O meglio detto, memorizzo l'hash della chiave (array di byte) nella tabella sql dell'utente con hash con BCrypt.
Domanda :
-
C'è qualcosa che non va?
-
Devo memorizzare il token completo nel database invece della sola chiave di firma e qual è il vantaggio?