POC: Add Frontegg authentication provider alongside SuperTokens
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: SwitchbackTech/compass#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 SwitchbackTech/compass#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.
@copilot update the codebase to use frontegg authentication instead of SuperTokens
@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:
- Removing all SuperTokens dependencies and code
- Updating all authentication middleware to use Frontegg exclusively
- Migrating existing user data and sessions
- Updating the frontend to use Frontegg's login flows
- 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.
Closing until it's picked up again.