It was a nice tutorial, but I keep seeing the same mistake over and over from multiple people. Amigoscode did the same thing as you did. The whole point of using JWT token is that you do NOT check against your database. That is literally the most important advantage in comparison to cookie / sessionID. You should have all the relevant information within token itself. The only exception to this rule is if you actually want to create or modify resource in your application and you need to make sure that the user still exists in the DB. And even in that case, that logic should be part of the controller/service that handles creation/modification of the resource. But if you just want to make sure your user is valid, the token should be all you need. If it is not, then you should reconsider whether the JWT token authentication is the best approach for your use case. But otherwise great tutorial. Thanks for that :)
You're totally right Jakub. I should avoid validating the user against the database for all read actions, but make some checks for the write actions. Thanks for the advice. I will use this approach in my followings projects/videos.
Can you explain further, I thought what Sergio did was right. First, you login and then receive a JWT token with the login as the payload. After that, every request has the JWT in the header and then the server will know who you are to query the database corresponding to who you are. In which point did he check against the database? My approach is that I have the userId inside the payload so I can query everything with this Id.
In this new video, ruclips.net/video/YUqi1IjLX8I/видео.html, i get the JWT after validating the credentials, then read the JWT from the headers, without requesting the database. Finally, if I perform some write operation, I validate the JWT with the user Id against the database
Thanks for the video, I think there is a missing point which is that the REST API communication is in clear HTTP, using HTTPS will protect our login object sent in the request body.
You must take into account that the JWT is an immutable token which will be stored in the frontend during all the user navigation. If you store critical information and this token is stolen, somebody may be able to decrypt the token. The critical informations must be sent to the backend through a POST request and stored in the backend (in a database or something else).
Yes Ahmed, the refresh token is another process. When refreshing a token, you only need to check if the current token is valid, you don't need to check the credentials again. Still, you can do it with a renew token to increase the security, sergiolema.dev/2023/03/13/how-to-renew-a-jwt-without-requesting-to-login/
OK thanks a lot But its still the same cycle when implementing the renew token I hade to validate token and credentials from db for every request or just I check the token validity instead of db call to check the user every request?
I've implemented a two ways JWT validation in the following video. When it's a GET, I trust the JWT and just try to decode it. When it's another HTTP verb (POST, DELETE, PUT...) I also check the user in the database. bit.ly/43YU0wb
Spring Security provides some resources for the most basic authentication, like the Basic auth or the Session auth. But if you want to customize more, using a stateless app, handling the information in the JWT and more, you need to write this by hand.
The easiest way to invalidate the JWT is to set a validity date very short, and renew it every short time. Another way, is to store the JWT in an invalidation table. Every time you invalidate a JWT, add it to a table and check it when used. In a stateless application, there is no invalidateSession that can be used, you have to find some hacks.
Thanks sound good, but looks like "Hello world". What about improving it? How? 1-hour expiration is too long, what if we want 1> around 10 minutes expiration time (5, 7, 10, 15) 2> each time authenticated user invokes any authenticated page - his expiration time should be renewed by this now() moment 3> next request should use new (updated) JWT.
It may seem an utopian, but I've use this configuration in several projects. Sometimes with 1 hour, sometimes with 1 week expiration time. It will depend on the usage. About the renew of the JWT, I've used another method: * When creating the JWT, I also create a renew-JWT (with an expiration higher) * Both are stored in the frontend * When the frontend receives a 403 HTTP code, it tries an /auth/renew endpoint with the renew-JWT * This will return a fresh JWT and a fresh renew-JWT In my method, I don't need to generate a new JWT every request. You may have an inactivity higher than 10 minutes, do you want the user to log in again? What about parallel requests, each will receive their own JWT, which one must be stored? What do you think?
Sorry, but i don't speak Portuguese (i've used google translate to answer you). I speak english, spanish or french. If it's ok for you, send me an email at thedevworldsl@gmail.com
Straight to the point and well explained. Great job!
Thank you Michael!
Great explanation of the Spring Security authentication. Helped a lot, thank you
I'm so glad to hear that!
Very useful video. Thank you. Short, concise, very well explained, simple and quite useful.
Thank you Joan!
Thank you very much! very helpful.
Thanks to you for following me and watching!
Thanks Sergio!
Great explanation and very simple code flow!
Very useful!
Thanks again Paolo!
Thank you, very helpful!
I tried my best!
Awesome work! This code is so easy to read. Great stuff. Thank you!
Thanks for watching!
It was a nice tutorial, but I keep seeing the same mistake over and over from multiple people. Amigoscode did the same thing as you did. The whole point of using JWT token is that you do NOT check against your database. That is literally the most important advantage in comparison to cookie / sessionID. You should have all the relevant information within token itself.
The only exception to this rule is if you actually want to create or modify resource in your application and you need to make sure that the user still exists in the DB. And even in that case, that logic should be part of the controller/service that handles creation/modification of the resource. But if you just want to make sure your user is valid, the token should be all you need. If it is not, then you should reconsider whether the JWT token authentication is the best approach for your use case.
But otherwise great tutorial. Thanks for that :)
You're totally right Jakub.
I should avoid validating the user against the database for all read actions, but make some checks for the write actions.
Thanks for the advice. I will use this approach in my followings projects/videos.
Can you explain further, I thought what Sergio did was right. First, you login and then receive a JWT token with the login as the payload. After that, every request has the JWT in the header and then the server will know who you are to query the database corresponding to who you are. In which point did he check against the database? My approach is that I have the userId inside the payload so I can query everything with this Id.
In this new video, ruclips.net/video/YUqi1IjLX8I/видео.html, i get the JWT after validating the credentials, then read the JWT from the headers, without requesting the database.
Finally, if I perform some write operation, I validate the JWT with the user Id against the database
Tendrás un ejemplo con el algoritmo RS256 (llaves publicas y privadas)?
La generación de un JWT con RS256? No, nunca he hecho eso. Pero igual esta página te puede ayudar, auth0.com/blog/rs256-vs-hs256-whats-the-difference/
Thanks for the video, I think there is a missing point which is that the REST API communication is in clear HTTP, using HTTPS will protect our login object sent in the request body.
That's a good point. Still, I prefer dedicate another video to the HTTPS alone.
@@TheDevWorldbySergioLema Thanks
So for credit cards or any sensitive data which would be the way to send it to the backend?
You must take into account that the JWT is an immutable token which will be stored in the frontend during all the user navigation. If you store critical information and this token is stolen, somebody may be able to decrypt the token.
The critical informations must be sent to the backend through a POST request and stored in the backend (in a database or something else).
Very clear explanation!
Thank you
does we need another endpoint for refresh token ?
Yes Ahmed, the refresh token is another process.
When refreshing a token, you only need to check if the current token is valid, you don't need to check the credentials again.
Still, you can do it with a renew token to increase the security, sergiolema.dev/2023/03/13/how-to-renew-a-jwt-without-requesting-to-login/
OK thanks a lot
But its still the same cycle when implementing the renew token
I hade to validate token and credentials from db for every request or just I check the token validity instead of db call to check the user every request?
I've implemented a two ways JWT validation in the following video.
When it's a GET, I trust the JWT and just try to decode it.
When it's another HTTP verb (POST, DELETE, PUT...) I also check the user in the database.
bit.ly/43YU0wb
Why write this by hand, doesn't Spring Security provide this out of the box?
Creating custom filters and jwt tokens, etc
Spring Security provides some resources for the most basic authentication, like the Basic auth or the Session auth. But if you want to customize more, using a stateless app, handling the information in the JWT and more, you need to write this by hand.
Hi man..how do you invalidate the jwt token anyway?
The easiest way to invalidate the JWT is to set a validity date very short, and renew it every short time.
Another way, is to store the JWT in an invalidation table. Every time you invalidate a JWT, add it to a table and check it when used.
In a stateless application, there is no invalidateSession that can be used, you have to find some hacks.
Thanks sound good, but looks like "Hello world".
What about improving it?
How?
1-hour expiration is too long, what if we want
1> around 10 minutes expiration time (5, 7, 10, 15)
2> each time authenticated user invokes any authenticated page - his expiration time should be renewed by this now() moment
3> next request should use new (updated) JWT.
It may seem an utopian, but I've use this configuration in several projects. Sometimes with 1 hour, sometimes with 1 week expiration time. It will depend on the usage.
About the renew of the JWT, I've used another method:
* When creating the JWT, I also create a renew-JWT (with an expiration higher)
* Both are stored in the frontend
* When the frontend receives a 403 HTTP code, it tries an /auth/renew endpoint with the renew-JWT
* This will return a fresh JWT and a fresh renew-JWT
In my method, I don't need to generate a new JWT every request. You may have an inactivity higher than 10 minutes, do you want the user to log in again? What about parallel requests, each will receive their own JWT, which one must be stored?
What do you think?
Tenes otro canal en español o solo este?
Solo este, pero traduzco los subtítulos al español para cada video
en español por favorrrrr
Todos mis videos tienen subtítulos en español traducidos por mi mismo.
VocÊ é brasileiro?
Quase, sou espanhol
@@TheDevWorldbySergioLema amigo, tens tempo para fazer essa aula particular comigo? Eu pago. posso enviar meu discord?
Sorry, but i don't speak Portuguese (i've used google translate to answer you). I speak english, spanish or french. If it's ok for you, send me an email at thedevworldsl@gmail.com
@@TheDevWorldbySergioLema te respondi via email, poemos fazer em spanish