Building an Auth0 BFF architecture for Product

The platform brought together a React frontend, multiple backend APIs, agent services, ITSM and infrastructure integrations, a service mesh, organization-based access, backend RBAC, and audit requirements.

A direct browser-to-service design would force every backend service to understand Auth0, JWT validation, token claims, organization context, session behavior, and authentication failures. As services grow, that logic becomes duplicated and harder to secure consistently.

A Backend for Frontend sits between the browser and internal APIs. Instead of sending the browser directly to every service, the browser uses one controlled entry point for authentication.

The BFF establishes who the user is; it does not replace authorization inside the backend. Backend services still decide what that user is allowed to do.

The architecture is organized into client, edge, authentication, platform, and persistence layers. The key boundary is between the public browser and the trusted identity context passed to internal APIs.

The BFF is the authentication boundary, while backend services remain the authorization boundary.

Auth0 owns identity concerns such as login, MFA, account recovery, identity verification, and OAuth/OIDC. After successful authentication, the BFF creates an application session so the browser does not repeat the full Auth0 flow on every API request.

The session is represented by an ia_session cookie. Auth0 answers who the user is; the application session gives the platform a stable way to recognize that identity during subsequent requests.

The BFF establishes the authenticated identity and organization context. Backend services then use that context when evaluating permissions with Casbin-based RBAC.

A valid Auth0 login does not grant access to every operation. The backend checks organization, role, and permission before allowing an API operation, which protects tenant boundaries.

Once a session exists, the browser sends the ia_session cookie with a request. The BFF validates the application session and forwards trusted identity context to the API, where authorization is evaluated before data or infrastructure operations run.

The BFF owns authentication, session management, Auth0 integration, identity extraction, organization context, authentication-related auditing, and session security.

Backend services own business logic, authorization, RBAC, infrastructure operations, agent execution, ITSM operations, data access, and approval gates. This keeps the BFF from becoming a second business-logic service.

Redis is suited to fast, ephemeral application session state. PostgreSQL/CNPG remains the durable store for application and compliance data. Keeping those roles distinct prevents convenient cache state from becoming the authoritative security record.

Authentication failures stop at the authentication boundary: no session or an invalid session returns 401 Unauthorized. An authenticated user who fails an RBAC check receives 403 Forbidden.

The central decision is separating identity from authorization. Auth0 provides the identity foundation, the BFF manages the browser authentication boundary and session, and backend services own authorization and business rules.

That separation also leaves room for other authentication paths, such as PATs, CLI access, automation, and machine-to-machine integrations, without weakening the browser security boundary.