Authentication Model

Mezusphere authenticates requests at the edge before traffic reaches your workload. Authentication is not an SDK integration or a middleware library; it is a traffic-layer feature that you enable per route from the Console.

Edge-enforced authentication

When authentication is enabled on a route, Mezusphere’s global edge handles the entire auth flow:

1. End user requests a protected route: the edge checks for a valid session
2. No session found: the user is redirected to Mezusphere’s hosted login page
3. User authenticates: login, signup, or password reset, all handled by the platform
4. Session established: a session is created and the user is redirected back to the application
5. Subsequent requests: the edge validates the session and forwards authenticated traffic to the Warpgate

Your workload never sees unauthenticated traffic on protected routes. By the time a request reaches your application, the user’s identity has been verified.

Per-route configuration

Authentication is configured at the route level, giving you granular control:

This means you can mix public and authenticated routes within the same project. No application-level auth middleware is needed; the edge handles the enforcement.

Authorization rules

Beyond authentication, routes can require specific permissions:

• Role-based access: restrict routes to users with specific roles
• Permission-based access: require specific permissions for route access
• Combined rules: require both authentication and specific authorization claims

Authorization policies are enforced at the edge alongside authentication. Your workload receives only traffic that satisfies both the authentication and authorization requirements.

User directories

Mezusphere includes built-in user directories for managing end-user accounts. User directories are scoped to a project or organization and provide:

• Account creation: users can sign up through hosted login flows or be created via the Console
• Account lifecycle: activate, suspend, or deactivate user accounts
• Profile management: name, email, display name, and status tracking
• Login history: track authentication events and last login timestamps

User directories replace the need for a separate identity provider like Auth0, Cognito, or Keycloak for many product-facing use cases. The identity surface is part of the platform, not a separate integration.

Service account identity

Machines authenticate differently from humans. Mezusphere uses service accounts for machine-to-machine identity:

• Warpgate authentication: each Warpgate authenticates to the control plane using a service account API key
• API access: service accounts can access Mezusphere’s APIs with configurable permissions
• Project-scoped: service accounts are scoped to a specific project for isolation
• Revocable: API keys can be rotated or revoked instantly from the Console

Service accounts provide a clean separation between human identity (user directories) and machine identity (service accounts), each with appropriate authentication mechanisms.

Identity propagation

After authentication, Mezusphere forwards trusted identity context to your workload. Your application receives:

• User identity: who made the request (user ID, email, display name)
• Authentication metadata: how the user authenticated and when
• Authorization context: what permissions or roles the user holds

This identity context arrives as HTTP headers on the forwarded request. Your application can trust this context without implementing its own token validation, because:

1. The edge verified the identity before forwarding
2. The Warpgate validates the request as a second layer of defense
3. The connection between edge and Warpgate is protected by mTLS

What this means for your code

Without Mezusphere, your application typically needs:

• An auth SDK or library (Auth0 SDK, Passport.js, Spring Security, etc.)
• Token validation middleware
• Session management logic
• User management endpoints
• Permission checking code

With Mezusphere, your application receives pre-authenticated requests with trusted identity headers. You read the headers and make business decisions; no auth plumbing required.

Pre-authenticated traffic guarantee

On routes where authentication is enabled, every request that reaches your Warpgate has been authenticated. This is not a convention or a best practice; it is an architectural guarantee:

• Unauthenticated requests are redirected to the login flow at the edge
• Requests with invalid or expired sessions are rejected at the edge
• Only authenticated, authorized requests are forwarded through the mTLS tunnel to your Warpgate

Your workload operates in a “pre-authenticated zone” where the identity question is already answered before your code runs.