re: I am a Developer Advocate for Security in Mobile Apps and APIs, Ask Me Anything VIEW POST

re: Mine is about something I read on reddit saying JWT tokens are not safe to use to keep the user authenticated. Can you share the link in order to...

The link where I read JWT is not a good medium for keeping users authenticated : (came from a paragonie post about promoting Paseto).

My use case is a shop web app (hosted on where the user can log in and keep track of his orders and loved products. I use Vuejs in the fron end and an API for the backend (powered by Laravel). For the moment I used JWT stored in the browser local storage, and keep using Post request with the token in parameter to validate the authenticity of the token (and keep the user ID inside of my token in the appropriate key).

When my user validate a login form, the credentials are sent to my Auth validation endpoint (, and if they are valid, I send back the token forged using firebase/jwt. I pass the encrypted user ID inside of my JWT, and I also encrypt the whole JWT string (using laravel facade method Crypt::encryptString).

Every time the user needs to make an action (like putting a love to a product for example), I decrypt the token, check its if it's valid, decrypt the user ID, and if the user exists, persist the favorite product in database.

I guess I could use http only cookies to pass the token instead of providing it at each requests.

Do you think this process is secure enough? Should I go something different for my use case?

Thank you so much for your time, I learn a lot right now!

Thanks for the detailed explanation.

Do you think this process is secure enough? Should I go something different for my use case?

I would prefer to use session cookies with httpOnly flag set, because local storage can be accessed via javascript and httpOnly cookies cannot, aka they are automatically sent back by the browser in each request performed to your web backend, but while more safe they are not bullet proof against abuse from an attacker.

Please keep reading to understand the difference between WHO and WHAT is accessing your web backend, and then thinks sill start to make more sense.

Requests Trust and the WHO vs the WHAT

Please keep in my mind that you cannot blindly trust in any kind of secret is presented to your backend to authenticate a user or what is making the request.

To better understanding what I mean you need to know the difference between WHO vs WHAT is accessing your API server, as I explain here, where you can read:

The who is the user of the mobile app that we can authenticate, authorize and identify in several ways, like using OpenID Connect or OAUTH2 flows.

The what is the thing making the request to the API server. Is it really a genuine instance of your mobile app, or is a bot, an automated script or an attacker manually poking around your API server with a tool like Postman?

This is only an excerpt, thus I recommend you to read the full section I linked to better grasp the differences.

How Can I Defend My Backend

While more in the context of an API, lot of what I recommended in this #ama reply is valid for a web backend to.

Please keep in mind that encrypting the JWT tokens only gives you confidentially during the request life cicle, aka no one will be able to read what is inside, but will not give you authenticity, aka guarantee that WHAT is sending back the encrypted JWT is really your web app in the behalf of WHO a JWT represents, aka your user.

An absolute thank you for all those information, I have now more information about differenciation between the what and the who. I was only checking the what until now but cannot for sure ensure who is sending the token. I will have a deep look at your links, I also seen some other folks have more detail explanation and I will take note of those too. Thank you fine sir!

You got it the other way around...

The who represent the user, your JWT token and the what represents the mechanism used to make the request, aka was the request made by your web app without have been tampered, was the request made by Postman or by Curl, etc..

So until now you have been checking the who, aka the JWT token that represents the user authentication,

code of conduct - report abuse