I am developing a REST API but JWT's looks wrong to me. We all calling them as "stateless tokens" but actually they brings a lot of problems.
We all say, they should not be stored in a database or memory cache solutions. But there are 3 core conditions about that API for me, please enlighten me about how can I implemented them without accessing / store them in DB.
When user changes his password, the token should be invalidated immediately. When user log-out, the token should be invalidated immediately. The architecture should be available to scale horizontally easily. I don't want a trouble. If we do database/cache lookups in each request for those conditions, JWT is a totally useless solution, Isn't it?
With your requirements they are mostly unsuitable. You can either invalidate a user session server-side, or can be stateless, but not both.
"Not secure" is a strong statement, but there are threats that they do not mitigate by default.
JWTs are overused without understanding risks and limitations. One use for JWTs is single sign-on scenarios, but not a lot of people actually need that. Another use is truly stateless apps, but those come with risks. There are uses for JWTs, they are not useless, but they tend to be used more than they should be.
If you need server-side session invalidation (forced logout), your solution will not be stateless. If you want stateless, JWTs are great, but you have to accept their risks and limitations. If you have sso with an identity provider that issues tokens that are used by your app to authenticate users, JWTs are a standard way to achieve that via say OpenID Connect. If you want to say pass a limited, timebound session to something else than a web app, a JWT might come handy. In a plain web app with users logging in on the same domain and just looking at pages or consuming an api on the same origin, a plain old session id is more secure.
In short, you need to choose the right tools for the job. Sometimes it's a JWT, but sometimes it's not.