¿Cómo gestionan las grandes aplicaciones web a los usuarios y sus datos?

OAuth 2.0 es la respuesta muy corta. En Java, normalmente se implementaría un servicio oauth con el que interactúan otros microservicios. A veces, eso significaría que esas solicitudes de autenticación para el principal (identidad) se negocian a través de un proxy inverso que puede tener o no un caché de identidad en una sesión o de otra manera.

misma historia en PHP, aunque las aplicaciones típicas no usan el proxy inverso de la misma manera.

El uso de un JWT firmado proporciona todo lo que necesita para confirmar la identidad y una lista relativamente corta de ámbitos (permisos). Sin embargo, las implementaciones específicas pueden variar bastante. Sin embargo, tenga cuidado: los JWT más grandes tienen un costo en términos de carga útil … por lo que se debe hacer una compensación entre los servidores de recursos que nunca necesitan comunicarse con el servidor de autorización frente a cada tamaño de carga útil de las solicitudes en bytes.

League oauth Server sería un buen ejemplo de PHP.

Spring security oauth sería un buen ejemplo de Java.

ahora, ese es solo el usuario (identidad) de un servicio a otro. Por lo general, eso se pasa efímeramente en cada solicitud. Aunque históricamente se guardaría en forma de un objeto de sesión disponible para el grupo de servidores (que tiene limitaciones en términos de escala). Por razones de eficiencia, el almacenamiento en caché de la primera solicitud para un usuario determinado puede tener sentido. En otros escenarios puede no serlo (consideraciones de seguridad).

El repositorio de almacenamiento de datos puede variar … pero cualquier base de datos SQL estaría bien siempre que los índices estén configurados para un acceso eficiente (por ejemplo, tiene un índice en la dirección de correo electrónico). Las bases de datos se escalan muy bien con esta información … aunque el repositorio debe ser un almacén de datos relacionales. Incluso una tienda en memoria puede estar bien siempre que tenga suficiente memoria para mantener a todos los usuarios, lo que no es irrazonable dado que la mayoría de las entidades de usuario son muy pequeñas en términos de su carga útil. NoSQL incluso sería una opción … diablos, podría pegar a todos los usuarios como un archivo JSON en S3 y acceder a eso … simplemente almacenar en caché la entidad de usuario en Redis o algo por razones de eficiencia en las llamadas posteriores.