Sviluppo di un sistema di autenticazione tra client, server e database CouchDB

Sto creando un'applicazione auto-ospitata che si affida a CouchDB per memorizzare i suoi dati. Il client (reagisce) potrebbe accedere al database, che è inviato dal server espresso a myapp.com/database . Anche il server deve accedere al database. Ecco cosa posso pensare per il primo processo di avvio:

• Crea database
• Genera un segreto JWT casuale e salvalo da qualche parte
• Crea funzioni di convalida per dati e autorizzazioni
• Termina la festa di amministrazione creando un account amministratore (credenziali generate casualmente e salvate da qualche parte con segreto) 4

All'avvio dell'app :

• rimuovi da _users tutto end_user s
• genera un UUID di istanza e lo salva in memoria.

processo di registrazione utente (che potrebbe verificarsi solo una o due volte su un server):

1. Nel client, invia una richiesta PUT /api/users con nome utente e password
2. Quando si riceve questa richiesta, il server genera un hash sicuro e sale usando password-hash-and-salt e quindi salvarlo in app_users (una raccolta accessibile solo dall'utente amministratore, controllata dall'app nodo)

Processo di accesso di base

1. Nel client, invia una richiesta PUT /api/sessions
2. Nel server, quando si riceve la richiesta, crea un nuovo _users con una password generata casualmente con il ruolo end_user e come _id users/:uid/:username (con come uid l'UUID generato all'avvio del server)
3. Salva la password generata nella memoria
4. Sempre nel server, firma un JWT da 1w che include il nome utente e l'ID istanza e lo restituisce al client
5. Timeout in 1 settimana una rimozione del database del _user creato.

Operazione di base del database:

1. Nel client invia una richiesta a /database/posts (per esempio), con nelle intestazioni il token di sessione
2. Nel server intercettare la richiesta, leggere l'intestazione della sessione, verificarla e quindi ottenere il database salvato in (3) di accesso. Sostituisci l'intestazione Authorization con Base64 codificato password:username .
3. Se l'utente non ha un token valido, non eseguire il proxy ma restituire 401.

Questo processo consente diverse cose:

• Assicurati che il client non conosca mai alcuna password del database
• Il client couchDB avrebbe mandato nell'intestazione una codifica Base64 del nome utente / password. Ciò evita che la password / nome utente venga inviata ad ogni richiesta e quindi riduce una potenziale superficie di attacco.
• Ciò consente di creare policy di sessione personalizzate come la scadenza di 1w o eventualmente le regole di password (come l'entropia minima)
• Il client non ha bisogno di memorizzare per lungo tempo la password.

Quanto sicuro sarebbe questo flusso di autenticazione?