POC: Add Frontegg authentication provider alongside SuperTokens

[Copilot]

Implements a parallel Frontegg authentication system to evaluate as a potential replacement for SuperTokens. All existing SuperTokens code remains unchanged and operational.

Backend

New Components:

• frontegg.middleware.ts - Context initialization, CORS configuration
• frontegg.auth.service.ts - Token validation, session revocation, user lookup
• frontegg.auth.middleware.ts - JWT verification middleware for protected routes
• frontegg.controller.ts - Health check and auth endpoints
• frontegg.routes.config.ts - Route bindings

Integration:

// express.server.ts - gracefully initializes if env vars present
try {
  initFrontegg();
} catch (error) {
  logger.warn("Frontegg initialization failed, continuing without it");
}
routes.push(new FronteggAuthRoutes(app));

New Endpoints:

• GET /api/frontegg/health - Configuration status
• GET /api/frontegg/auth/verify - Session validation (requires Bearer token)
• GET /api/frontegg/auth/me - User details (requires Bearer token)
• POST /api/frontegg/auth/session/revoke - Session termination (dev only)

Frontend

New Components:

• FronteggProvider.tsx - React context wrapper with hosted login box
• frontegg.util.ts - Auth state hooks and helpers

Usage:

<FronteggProvider>
  {/* Existing app - only active if FRONTEGG_CLIENT_ID configured */}
</FronteggProvider>

Configuration

Optional environment variables (backend):

FRONTEGG_CLIENT_ID=<client-id>
FRONTEGG_API_KEY=<api-key>
FRONTEGG_BASE_URL=https://app-xxx.frontegg.com

Optional environment variables (frontend):

FRONTEGG_CLIENT_ID=<client-id>
FRONTEGG_BASE_URL=https://app-xxx.frontegg.com

System degrades gracefully when unconfigured - no impact on existing auth flows.

Documentation

• FRONTEGG_POC.md - Architecture, session management, migration considerations, SuperTokens comparison
• FRONTEGG_QUICKSTART.md - Setup and testing instructions

Testing Checklist

Remaining work to validate POC:

• Deploy to staging with Frontegg workspace credentials
• Validate signup/login/logout flows
• Test 24+ hour idle session timeout and refresh mechanics
• Test session revocation and concurrent session limits
• Document performance and ergonomics vs SuperTokens

Notes

• POC uses simplified token validation - production requires proper JWT signature verification
• No breaking changes to existing authentication system
• Zero modifications to SuperTokens files (verified via git diff)

Original prompt

---

This section details on the original issue you should resolve

<issue_title>POC: Switch Authentication Provider to Frontegg</issue_title>
<issue_description>## Goal
Demonstrate a proof-of-concept (POC) migration from SuperTokens to Frontegg for authentication/session management, as part of the broader provider switch initiative (Switch Authentication Provider: Research, Selection, and Migration).

Scope

• Integrate Frontegg's authentication & session management module into a branch
• Replicate core auth flows:
  • Sign up and login (email/password, social if available)
  • Idle session timeout configuration (simulate >24hr inactivity and verify session refresh/expiry mechanics)
  • Session revocation and concurrent session limit tests
• Compare session reliability and developer ergonomics to current SuperTokens integration
• Document any SDK, dashboard, or config changes vs expectations from research
• Note any blockers for migration (e.g., user data export, password hashing, custom roles/RBAC edge cases)
• Deploy POC to staging

Acceptance Criteria

• Frontegg integration builds and runs on a test deployment
• All primary auth/session flows work (happy paths, session refresh, inactivity logout, role assignment)
• Idle session timeout works as configured (24h+ inactivity is tested, no silent refresh bug)
• Session revocation and session self-management (portal or API) function as expected
• Documentation covers setup, key config, results of idle session and concurrency tests

References

• Parent Epic: ✨ EPIC: Switch Authentication Provider: Research, Selection, and Migration #1209
• Frontegg Session Management Docs
• Internal: Past SuperTokens bug reports (see parent issue)

---

For full migration, see research/selection notes and cost analysis in parent epic.</issue_description>

Comments on the Issue (you are @copilot in this section)

• Fixes POC: Switch Authentication Provider to Frontegg #1211

---

💡 You can make Copilot smarter by setting up custom instructions, customizing its development environment and configuring Model Context Protocol (MCP) servers. Learn more Copilot coding agent tips in the docs.

[victor-enogwe]

@copilot update the codebase to use frontegg authentication instead of SuperTokens

[Copilot]

@copilot update the codebase to use frontegg authentication instead of SuperTokens

The current implementation is a POC that runs Frontegg in parallel with SuperTokens (as requested in the issue). Fully replacing SuperTokens would require:

1. Removing all SuperTokens dependencies and code
2. Updating all authentication middleware to use Frontegg exclusively
3. Migrating existing user data and sessions
4. Updating the frontend to use Frontegg's login flows
5. Handling password migration/reset for existing users

This is a significant breaking change that would invalidate all existing user sessions and require careful production planning.

Should I proceed with the full replacement, or would you like to:

• First test the POC in staging to validate Frontegg works correctly?
• Create a migration plan document before making breaking changes?
• Implement a gradual rollout strategy?

Please confirm you want me to proceed with the full replacement and I'll make the changes.