This content originally appeared on DEV Community and was authored by Omotola Odumosu
Over the past few projects, I’ve had to make this exact choice: Do I go with ASP.NET Identity or roll my own JWT solution? Each comes with its pros and cons, and I’ve learned it really depends on the project and here’s how I usually view and explain it in simple terms
Imagine you’ve just moved into a new house. You need locks for your doors, and you have two options:
Option 1: ASP.NET Core Identity (The Professional Locksmith)
You call a locksmith (ASP.NET Identity).
They bring the lock, install it, and ensure it’s tamper-proof.
Every time you use the door, the lock automatically checks the key.
You don’t worry about the details, it just works, and it’s secure.
Less work for you, industry best practices, and battle-tested security.
Option 2: JWT Without Identity (Build Your Own Lock)
You decide to build your own lock (JWT without Identity).
You design how the keys are cut (hashing & storing passwords).
You decide how the lock works (generating JWTs).
Every time someone uses the door, you must check if the key really fits (manual validation).
More flexibility, but you carry the full responsibility for security.
The Trade-off
Use ASP.NET Identity if you want a secure, ready-made solution.
Use JWT without Identity if you need full control, but be prepared to handle every detail carefully.
One lesson I’ve learned about ASP.NET Identity
It doesn’t always provide clear error handling out-of-the-box when signup or login fails. That leaves the client guessing what went wrong.
Here’s a better approach: Create a custom login or signup endpoint that wraps UserManager or SignInManager calls in a try-catch and returns clear error messages:
This way, your API communicates exactly why a login/signup failed instead of leaving the client in the dark.
Example of JWT without Identity (build-your-own lock)
On the flip side, if you choose the JWT without Identity route, you have to manually handle things like token creation and signing.
Here’s a simple example of generating a JWT:
This is the DIY (Do It Yourself) lock-making approach: you’re in control of how tokens are created, but you’re also responsible for keeping everything secure (keys, expiration, claims, etc.).
Industry Insight
I’ve noticed that larger enterprises often lean towards the JWT without Identity approach, since it gives them full control and the ability to fine-tune authentication to their unique business logic.
But at the end of the day, both approaches can keep your house (app) safe 
. The difference is whether you’d rather trust the locksmith or build your own lock system.
LinkedIn Account: LinkedIn
Twitter(X) Account: Twitter
This content originally appeared on DEV Community and was authored by Omotola Odumosu