WICKET is not just another login system, it's designed to be developer-friendly, secure, and easy to host. Here's how I'm building it:
Cross-Site Authentication
WICKET is built to work on subdomains like auth.example.com or accounts.example.com, while the main site runs on example.com.
The auth server stores secure cookies and tokens.
Your main site just asks the auth server to confirm if a user is logged in or verify it self if using same secret string.
This means one login works across your entire platform.
This model is the same approach used by big providers like Google, Microsoft, and Auth0 for handling authentication at scale.
JWT Tokens for Security
When a user logs in, WICKET issues access tokens and refresh tokens.
Access tokens let your site verify user actions quickly.
Refresh tokens allow your site to generate new access tokens securely, by contacting WICKET again.
This keeps the system both fast and secure, while giving developers full control.
Simple Configuration
Developers only need to manage two files:
.env file → contains secure keys and connections (Postgres, Redis, etc.).
Config file → defines project rules, like:
- Enable or disable Google login.
- Require 2FA (Passkeys, TOTP) before allowing login.
- Control what login methods are available.
Why This Approach?
This design avoids vendor lock-in, reduces complexity, and keeps sensitive data under your control. Instead of relying on external services, you run everything yourself, just like large organizations do, but with far less setup.
Vision
My goal is to make WICKET a plug-and-play authentication system:
Easy for beginners to set up in minutes.
Flexible enough for organizations with strict security needs.
Transparent, open-source, and built for long-term trust.