¿Debo autenticar al usuario en cada solicitud?

Debería usar gestión de sesión para gestionar la transferencia de información entre clientes y servidores.

La administración de la sesión esencialmente consiste en autenticar a un usuario para realizar inicialmente una acción privilegiada, y todas las actividades subsiguientes se autentican mediante información 'compartida', por ejemplo: cookies.

Pedir a los usuarios que se autentiquen para todas y cada una de las acciones puede considerarse más seguro pero, como resultado, reducirá en gran medida la facilidad de uso de la plataforma y la satisfacción general del usuario.

En lo que respecta a la carga de la base de datos, sin ver la aplicación específica, no puedo estar al 100%. Sin embargo, le aconsejaría que, si está registrando la última vez que se utilizó la sesión, no necesita escribir mucha otra información en la base de datos.

Identidad basada en reclamaciones es una buena manera de reducir la carga de autenticación de un usuario.

La forma más sencilla de implementar es tener un primer portal de autenticación que genere tokens firmados que contengan las reclamaciones necesarias para el usuario y luego la llamada posterior requiera que el token, verifique la firma y confíe en las reclamaciones.

Consulte JWT para una implementación práctica.

Esto es realmente un poco fuera de tema aquí. No sabemos cómo se ve / hace / parece su aplicación, por lo que no podemos responder a la pregunta que hizo más allá de decir que la relevancia funcional generalmente invalida la consideración de rendimiento. Sin embargo, ya que otros ya han comenzado a responder ...

Tradicionalmente, las sesiones http utilizan un identificador aleatorio enviado al cliente, que es una clave para los datos en el servidor. Cada vez que una solicitud requiere datos de sesión, esto se lee desde el almacenamiento. Y en la mayoría de las implementaciones, posteriormente se vuelve a escribir en el almacenamiento o antes de completar la solicitud. Este último es importante para actualizar la marca de tiempo en la sesión para que se pueda recolectar la basura más tarde. Ahora definitivamente desea escribir los datos en el almacenamiento cuando ha cambiado, pero las escrituras son al menos 3 veces más caras que las lecturas. Entonces, aunque puede implementar esto sin afectar la entrega de contenido al cliente, no escribir los datos de sesión sin cambios en el almacenamiento con cada solicitud puede tener un gran impacto en la capacidad.

El uso de un sustrato de almacenamiento más rápido también puede ayudar.

Luego existe la posibilidad de almacenar contenido en caché. Algún contenido debe ser generado de nuevo cada vez que se accede. Cierto contenido será casi estático para un usuario determinado, y otro contenido será el mismo para todos los usuarios. HTTP proporciona mecanismos para anunciar este hecho al cliente y a un proxy inverso . Por ejemplo, para el contenido almacenado en caché por un usuario específico, puede incorporar la identificación del usuario en el Etag, pero recuerde agregar un encabezado privado de control-caché en el punto donde deja el proxy inverso.

Aunque generalmente no puede confiar en el contenido enviado desde el cliente, puede cifrar los datos en cookies y utilizar el cliente para el almacenamiento, y verificar la manipulación cuando lo descifre. Nuevamente, se trata de capacidad más que de rendimiento. Y algunos pensamientos deben aplicarse a la persistencia de los datos en el cliente, incluso si están cifrados.

Pero, excepto en muy pocos casos, la sobrecarga de rendimiento de las sesiones, en relación con todo lo que sucede en una página web es muy pequeña, MUY pequeña.

Parece que estás rodando tu propia autenticación o al menos una parte de ella.

  

Me pregunto si debería ir a Redis cada vez que el usuario solicite contenido,

Sí, tiene que verificar la sesión de usuario contra su almacenamiento de back-end en cada solicitud http , de esta manera los servidores web y los marcos web se ocupan de las sesiones de usuario, algunas de ellas usa el sistema de archivos para almacenar sesiones como Apache y otros usan DB relacional como Django Framework lo hace por defecto.

El almacenamiento en memoria como Redis y Memcached es, de facto, la elección correcta para este caso.

Sin embargo, aún puede aumentar el rendimiento al reducir la cantidad de viajes de ida y vuelta entre el cliente y su servidor. Esto se puede lograr agregando datos a un menor número de solicitudes, lo que disminuirá en la frecuencia de aciertos en Redis.

No, no es necesario que presione Redis en cada solicitud, la respuesta, ya que puede administrar las sesiones desde su servidor al emitir una cookie segura. ¿Imagina lo que sucedería si Facebook o Twitter golpearan su db en cada solicitud que el usuario haga? Además, ralentizaría la solicitud de los usuarios.