At work, we maintain more than 20 React applications served through Express.js for different enterprise customers. Each customer has different authentication requirements: some use CAS, others use Keycloak, and others use Entra ID/Azure AD. Over time, every application developed its own middleware, session handling, token-refresh behavior, Redis configuration, and fixes for provider-specific edge cases. Supporting both browser sessions and bearer-token APIs made the differences even harder to maintain. I started building a shared internal layer to standardize these flows without replacing the identity providers that customers already require. How are others handling authentication consistently across multiple Node.js and Express applications in similar enterprise environments?
3 Answers
If possible, standardizing on one identity provider would remove a lot of operational complexity. Maintaining a custom authentication layer across dozens of applications can become another long-term product to support. That said, this is often a business and customer constraint rather than a purely technical choice.
The difficult part is usually not role-based authorization itself. Once a token or session is normalized, each application can apply its own roles and permissions. The hard work is keeping CAS and OIDC behavior consistent, handling session lifecycles, refresh races, Redis failures, proxy constraints, logout behavior, token expiry, and both browser-session and bearer-token flows. A shared library can avoid duplication without putting a separate authentication service in front of every application, which may be preferable when an additional dependency or single point of failure would worry customers.
That matches our experience. We considered a standalone authentication service, but a shared library gives the applications common behavior without adding another always-on dependency between each customer and their application.
A managed authentication provider or a well-supported open-source library can take care of much of the repeated work, although managed services add recurring costs. For enterprise integrations, a generic SAML or OIDC gateway can also provide a more consistent interface over several upstream providers. If you later need automated user provisioning and deprovisioning, SCIM 2.0 is worth considering because it has become a fairly common standard.
Managed services definitely reduce the maintenance burden, but our customers already use different providers, so we cannot always standardize on one service. Our immediate problem is consistent authentication behavior across the applications; provisioning and deprovisioning would likely be the next major concern.
That would be ideal for a typical SaaS product, but enterprise customers often mandate their own identity providers and SSO policies. The shared layer is intended to normalize integration logic across the applications, not replace the customers’ existing providers.