Authentication is one of the first things developers add to an application. Today, many teams use services like Google OAuth, Clerk, Auth0, or Firebase Authentication because they are easy to integrate and handle most of the security for you.
But what happens if you want complete control over your authentication system? Maybe you want to avoid vendor lock-in, reduce costs, or host everything yourself.
The good news is that you don't need to build authentication from scratch. You can replace managed authentication platforms with open source identity providers that offer the same core features.
In this article, we'll understand how Google OAuth and Clerk work, and how we can replace them with open source implementations in simple words.
How Authentication Works Today
Let's imagine a user wants to log into your application.
Here's what happens behind the scenes:
- The user clicks Sign in.
- Google or Clerk displays the login page.
- The user enters their credentials.
- The authentication provider verifies them.
- A JWT (JSON Web Token) is generated.
- The frontend sends this token with every API request.
- The backend verifies the token before allowing access.
Notice something important:
Your backend never checks the user's password.
Google or Clerk does that for you.
The Problem
Managed authentication services are great, but they come with trade-offs.
- Monthly subscription costs
- Vendor lock-in
- Limited customization
- Your authentication depends on a third-party service
- Less control over user management
As your application grows, you might want to host authentication yourself.
The Idea Behind Replacing Them
Many developers think they need to rebuild OAuth.
You don't.
OAuth is a standard.
What you're actually replacing is the Identity Provider.
Instead of asking Google or Clerk to verify users, you'll run your own authentication server.
That's it.
The New Architecture
Instead of this:
You'll have:
The flow stays almost exactly the same.
Only the service performing authentication changes.
Which Open Source Tools Can Replace Clerk?
Some popular options are:
- Keycloak
- Authentik
- Ory Kratos
- Zitadel
- SuperTokens Community Edition
Among these, Keycloak is one of the most mature and widely used solutions.
It already supports:
- OAuth 2.0
- OpenID Connect
- JWT Tokens
- User Management
- Role-Based Access Control
- Multi-Factor Authentication
- Social Login
- Single Sign-On (SSO)
Step 1: Deploy Your Authentication Server
Install an authentication server like Keycloak.
Instead of relying on Google, Keycloak becomes responsible for:
- Managing users
- Managing passwords
- Creating sessions
- Generating JWT tokens
- Handling login and logout
Think of it as your own private version of Google Login.
Step 2: Store Users Yourself
Instead of Google storing user accounts, your authentication server stores them.
Passwords are never stored as plain text.
They are securely hashed using algorithms like bcrypt or Argon2.
Step 3: User Logs In
The user enters:
- Password
The frontend sends these credentials to Keycloak.
Keycloak checks the credentials.
If they're correct, it generates a JWT token.
Step 4: Return the JWT
Keycloak sends a JWT token back to the frontend.
The frontend stores it securely.
Now the user is authenticated.
Step 5: Call Protected APIs
Whenever the frontend calls your backend, it includes the JWT.
GET /profile
Authorization: Bearer <JWT_TOKEN>
Step 6: Verify the Token
The backend checks whether the JWT is valid.
If it is valid:
- Allow the request.
If it is invalid:
- Return 401 Unauthorized.
This is exactly how Google OAuth and Clerk work.
The only difference is that your own server issued the token.
Before vs After
Before
After
Nothing changes for your backend except who issues the token.
Migration Steps
If you're moving away from Clerk or Google OAuth, your migration looks like this:
- Deploy Keycloak (or another open source identity provider).
- Create your application (client) inside Keycloak.
- Configure login, registration, and roles.
- Update the frontend to authenticate with Keycloak.
- Update the backend to verify JWTs issued by Keycloak.
- Test login, logout, and protected routes.
- Remove Clerk or Google OAuth from your application.
Benefits of Self-Hosted Authentication
- No vendor lock-in
- Lower long-term costs
- Full control over user data
- Custom authentication workflows
- Support for OAuth 2.0 and OpenID Connect
- Enterprise-ready features like SSO, MFA, and RBAC
Challenges
Self-hosting also comes with responsibilities.
- You must maintain the authentication server.
- You need to install security updates.
- You are responsible for backups and monitoring.
- Initial setup takes more effort than using a managed service.
For small projects, managed authentication may still be the better choice.
For larger applications or organizations that need complete control, open source identity providers can be an excellent solution.
Final Thoughts
Replacing Google OAuth or Clerk doesn't mean replacing OAuth itself.
You're simply replacing the service that proves a user's identity.
Instead of trusting a third-party provider, you run your own identity server while continuing to use industry standards like OAuth 2.0, OpenID Connect, and JWT.
The overall login flow remains almost identical, but you gain full ownership of your authentication infrastructure.
If you're building products that require flexibility, customization, or long-term control, open source authentication is definitely worth exploring.
Top comments (0)