¿Existe alguna inquietud grave al enviar el nombre de usuario y la contraseña del usuario con cada solicitud HTTPS?

Debido a ciertos requisitos / restricciones, me pregunto sobre el envío de inicio de sesión y contraseña de usuario con cada solicitud.

Esto de alguna manera no me parece muy bien, aunque creo que para mi caso en particular, podría tener sentido: reduciría la cantidad de solicitudes HTTP, reduciría la latencia y simplificaría el código de interfaz.

Aquí está la situación:

• El tráfico al servidor proviene de una aplicación móvil
• Todo el tráfico pasa por HTTPS
• Mantenemos las credenciales de usuario cifradas en el almacenamiento del dispositivo para iniciar sesión automáticamente en cada inicio de la aplicación
• El tiempo de espera de la sesión del servidor es muy bajo (pocos minutos) y está fuera de mi control
• El DB está fuera de mi control; No puedo agregar nada a la base de datos de forma fácil y rápida (sería un gran desafío obtener un campo de base de datos si, por ejemplo, quisiera un token de sesión de larga duración)
• El tráfico en la aplicación usualmente ocurre en lotes
• El lote de tráfico típico dentro del tiempo de espera de la sesión es solo unas pocas solicitudes HTTPS
• Dado que el tráfico proviene de la aplicación móvil, no siempre es posible enviar solicitudes de "mantener la sesión activa"; si el usuario mata una aplicación y la vuelve a iniciar unos minutos más tarde (o se minimiza durante unos minutos), no hay posibilidad de mantener la sesión y debo volver a iniciar sesión en el usuario.

Por lo tanto, el patrón de tráfico típico actualmente es:

#USER OPENS THE APP
POST /autologin    -> response: [ok, here's the new sessionid]|[auth failure, maybe the password changed since]
#SUPPOSING AUTH WAS OK; USER BROWSES AROUND THE APP
POST /someAction1
POST /someAction2
POST /someAction3
#USER IDLE FOR A FEW MINUTES
POST /keepSession
...
#USER MINIMIZES THE APP
#USER RELAUNCHES THE APP, MAYBE SEVERAL MINUTES LATER, MAYBE NEXT DAY
POST /someAction4  -> response: sessionTimeout
POST /autologin    -> response: [ok, here's the new sessionid]|[auth failure, maybe the password changed since]
#SUPPOSING AUTH WAS OK; USER BROWSES AROUND THE APP
POST /someAction4
...

De todos modos, en promedio, tengo que enviar la solicitud de inicio de sesión con bastante frecuencia una vez que la sesión expira; Un porcentaje significativo de solicitudes son solicitudes de inicio de sesión.

Si envío un nombre de usuario y una contraseña en cada solicitud, puedo

• deshacerse de las solicitudes /autologin en el arranque
• deshacerse de las solicitudes /keepSession cada pocos minutos mientras el usuario está activo
• deshacerse de /action - > /autologin - > /action combo en caso de que la sesión haya expirado; bajando de la solicitud 3 a solo 1

Siempre podría enviar tanto la ID de sesión como la Contraseña de inicio de sesión, luego, en el back-end, reutilizar la ID de sesión si todavía es válida, de lo contrario, crear una nueva sesión con el nombre de usuario y la contraseña, y hacer lo que quisiera dentro de la misma llamada HTTP, sin la necesidad para jugar ping-pong entre frontend y backend.

Para resumir, desde mi perspectiva:

Contras:

• Debería tener cuidado en el backend para no registrar accidentalmente las credenciales de los usuarios en múltiples controladores de solicitudes, no solo uno (controlador de inicio de sesión)
• podría aumentar el número de solicitudes con inicio de sesión y pasar la carga útil en un factor de N = ~ 4,

Pros:

• el número total de solicitudes HTTP realizadas por el servidor disminuyó en un 20% +
• no es necesario que la lógica de frontend mantenga la sesión del usuario; simplemente disparar cada solicitud con credenciales. Si falla debido a un problema de autenticación, cierre la sesión del usuario.

Sabiendo que el tráfico está encriptado con HTTPS, ¿hay algún inconveniente grave en mi enfoque de siempre enviar, iniciar sesión y pasar?