I am a Developer Advocate for Security in Mobile Apps and APIs at approov.io.
Another passion is the Elixir programming language that was designed to be concurrent, distributed and fault tolerant.
Location
Scotland
Education
Self teached Developer
Work
Developer Advocate for Mobile and API Security at approov.io
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 give more insight to the scope of that affirmation?
But as in many things it depends for what you are using JWTs and how you use them. Can you give me some more insight in your use case?
It is said that Pasteo is safer
You mean Paseto? Never seen it before, but looks interesting, need to take a better look into it.
I also read that keeping the token in the cookie session is safer than storing the token in localStorage.
You mean browser localStorage?
If you are use case is just for a web app and a web backend, then I would stick with secure and HttpOnly cookies.
What do you think about it? I also wondered if I encrypt my token before sending it to my client browser will make it harder to decrypt, is this enough to keep using a stateful JWT (because I have my user ID inside) to authenticate my users?
Where is comming your JWT from? An OAUTH provider or is provided by your own backend?
Without knowing more about your use case is hard to make a best recommendation, but as already said if is a web app with only a web backend I would not go with JWTs, and instead stick with session cookies, as I linked above.
The link where I read JWT is not a good medium for keeping users authenticated : cryto.net/~joepie91/blog/2016/06/1... (came from a paragonie post about promoting Paseto).
My use case is a shop web app (hosted on example.com) 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 (api.example.com/auth), 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!
I am a Developer Advocate for Security in Mobile Apps and APIs at approov.io.
Another passion is the Elixir programming language that was designed to be concurrent, distributed and fault tolerant.
Location
Scotland
Education
Self teached Developer
Work
Developer Advocate for Mobile and API Security at approov.io
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!
I am a Developer Advocate for Security in Mobile Apps and APIs at approov.io.
Another passion is the Elixir programming language that was designed to be concurrent, distributed and fault tolerant.
Location
Scotland
Education
Self teached Developer
Work
Developer Advocate for Mobile and API Security at approov.io
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,
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Can you share the link in order to give more insight to the scope of that affirmation?
But as in many things it depends for what you are using JWTs and how you use them. Can you give me some more insight in your use case?
You mean Paseto? Never seen it before, but looks interesting, need to take a better look into it.
You mean browser localStorage?
If you are use case is just for a web app and a web backend, then I would stick with secure and HttpOnly cookies.
Where is comming your JWT from? An OAUTH provider or is provided by your own backend?
Without knowing more about your use case is hard to make a best recommendation, but as already said if is a web app with only a web backend I would not go with JWTs, and instead stick with session cookies, as I linked above.
The link where I read JWT is not a good medium for keeping users authenticated : cryto.net/~joepie91/blog/2016/06/1... (came from a paragonie post about promoting Paseto).
My use case is a shop web app (hosted on example.com) 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 (api.example.com/auth), 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.
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:
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,