How to really use OAuth
OAuth is very popular in the dev world and rightfully so. At the beginning of your dev journey you learn frontend stacks, UI, things you can see and click and feel good about. Then you go deeper. Backend. Authentication. System design. CI/CD. Containers. And suddenly you realize… nothing is simple anymore.
How it’s used
In most cases OAuth is just used for login.
“Sign in with Google” → click → boom you’re in
Nice UX, users love it, everyone is happy. And yeah… it works fine. Until your users start doing normal user things.
The real problem
Most users don’t live inside one provider. They’ve got:
• Google account
• GitHub account
• Twitter/X
Now imagine this:
• Same human.
• Different providers.
• Different identity data.
And your app is sitting there trying to make sense of it all.
Congrats, you just created an identity problem
Now you have to answer questions OAuth doesn’t even care about:
• Is this the same user or a new one?
• Do we link these accounts? Or do we create duplicates?
• What happens when they switch login method?
And this is where things start breaking quietly. Because if you get it wrong:
• you merge two different people (bad) or split one user into 3 accounts (also bad)
Either way… chaos.
The thing nobody tells you
OAuth is NOT identity. It just tells you:
“this person proved they own this account” That’s it.
It doesn’t care who they are across the internet.
Enter: the Identity engine
This is the part most tutorials skip completely. You don’t just need OAuth. You need something that actually understands identity.
Something that:
• links accounts properly
• keeps users consistent across providers
• doesn’t randomly merge strangers
• doesn’t duplicate the same person 5 times
Basically… a small identity system living inside your auth layer. And that’s where things get real Because once you see this problem in production, you realize: OAuth is easy. Identity is the hard part.
This is why I built create-authenik8-app
Because I got tired of every “auth tutorial” stopping at:
“here’s Google login, you’re done 👍”
No mention of:
• linking logic
• identity resolution
• real-world edge cases
• messy user behavior
So I built a starter that actually thinks beyond login.
It gives you:
• JWT auth
• OAuth (Google, GitHub, etc.)
• identity-aware linking
• Real backend structure for production systems
Not just “login works”…
but “identity doesn’t break later”
Final thought
OAuth is the easy part.
The real problem starts after the user logs in. And if you don’t design for identity early… you’ll feel it later.
LinkedIn: www.linkedin.com/in/kbseeisa
Create-authenik8-app: https://authenik8.vercel.app
Command:
npx create-authenik8-app app
