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, password reset, and email verification, 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.

Authentication methods

Mezusphere is the identity provider; there is no external IdP to integrate. End users authenticate with:

• Passkeys (WebAuthn): phishing-resistant, passwordless sign-in
• Password plus TOTP: time-based one-time-password MFA for password accounts
• Email verification and password reset: built into the hosted login flows

For programmatic and delegated access, Mezusphere implements OAuth 2.1 with mandatory PKCE (S256) and issues OIDC id_tokens. OAuth clients are managed per environment from the Console.

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 as plain HTTP headers on the forwarded request:

Inbound copies of these headers are stripped from every request before authentication, so a client can never spoof them. The credentials Mezusphere issued (session cookies and bearer tokens) are removed at the edge and never reach your application.

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

Reading identity in your code

// Node.js / Express
app.get("/api/orders", (req, res) => {
  const userId = req.get("Mz-User-Id");
  const email = req.get("Mz-User-Email");
  // your business logic; no token parsing, no key sets, no auth middleware
});

// Go
func handler(w http.ResponseWriter, r *http.Request) {
	userID := r.Header.Get("Mz-User-Id")
	email := r.Header.Get("Mz-User-Email")
	// your business logic
}

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.

For the exact OAuth and OpenID Connect specifications the platform implements, see Standards conformance.