Desarrollando un sistema de autenticación entre el cliente, el servidor y la base de datos CouchDB

Estoy creando una aplicación auto hospedada que se basa en CouchDB para almacenar sus datos. El cliente (reaccionar) puede acceder a la base de datos, que es proxy por el servidor Express a myapp.com/database . El servidor también necesita acceder a la base de datos. Esto es lo que puedo pensar para el primer proceso de inicio:

• Crear bases de datos
• Genere un secreto JWT aleatorio y guárdelo en algún lugar
• Crear funciones de validación para datos y permisos
• Termine la parte de administración creando una cuenta de administrador (las credenciales se generan aleatoriamente y se guardan en algún lugar con secreto) 4

Al iniciar la aplicación :

• eliminar de _users all end_user s
• genere un UUID de instancia y guárdelo en la memoria.

proceso de registro de usuarios (que puede ocurrir solo una o dos veces en un servidor):

1. En el cliente, envíe una solicitud PUT /api/users con nombre de usuario y contraseña
2. Al recibir esta solicitud, el servidor genera un hash y salt seguros utilizando password-hash-and-salt y luego guárdelo en app_users (una colección a la que solo puede acceder un usuario administrador, controlada por la aplicación de nodo)

Proceso de inicio de sesión básico

1. En el cliente, envíe una solicitud PUT /api/sessions
2. En el servidor, al recibir la solicitud, cree un nuevo _users con una contraseña generada aleatoriamente con el rol end_user y como _id users/:uid/:username (con como uid el UUID generado al iniciar el servidor)
3. Guarda la contraseña generada en la memoria
4. Aún en el servidor, firme un JWT de 1w que incluya el nombre de usuario y el ID de instancia y devuélvalo al cliente
5. Tiempo de espera en 1 semana una eliminación de la base de datos del _user creado.

Operación básica de base de datos:

1. En el cliente, envíe una solicitud a /database/posts (por ejemplo), con en los encabezados el token de sesión
2. En el servidor, intercepte la solicitud, lea el encabezado de la sesión, verifíquelo y luego guarde la base de datos guardada en (3) de inicio de sesión. Reemplace el encabezado de Autorización con un% codificado password:username .
3. Si el usuario no tiene un token válido, no haga proxy pero devuelva 401.

Este proceso permite varias cosas:

• Asegúrese de que el cliente nunca conozca la contraseña de la base de datos
• El cliente couchDB enviaría en el encabezado una codificación Base64 del nombre de usuario / contraseña. Esto evita que la contraseña / nombre de usuario se envíe en cada solicitud y, por lo tanto, reduce una posible superficie de ataque.
• Esto permite crear políticas de sesión personalizadas como 1w expiración o posiblemente reglas de contraseña (como la entropía mínima)
• El cliente no necesita almacenar en la memoria la contraseña por mucho tiempo.

¿Qué tan seguro sería este flujo de autenticación?