I recently came across with your videos. I found these videos extremely easy to understand and helpful. Thank you so much for your time and efforts for making such content.
Excellent video. Thank you for your effort. is there a particular reason why you used a different package for refresh tokens, instead of using the jwt package here as well?
👏👏👏👏👏 Thanks for your video. Can I ask if is there anyway to declare a jwt service for global level and another one in Auth module scope, like: using it for refresh only?
You're welcome! Yes, you can register another Jwt Module in the AuthModule with its own secret and config.. and it would work. However, be careful, your Auth guard will be using one of the two jwt services (Most probably the global one).. So you would need to find a way to dynamically use the correct secret key when verifying your tokens.. Now if you have the same secret for both modules, but you're using different config options such as expiry etc.. I don't think you would face any issues.. you could also override the default config used in the global jwt module, by simply assigning them explicitly such as : jwtService.verify(token, { ...override-config-here ...}, in case you don't want to register a second jwt module. I'm not sure why you would use the jwtService with the refresh however, as the refresh token is a long random string (rather than a Json Web Token) Hope my answer helps!
@@Computerix Thanks for your reply! I know I can inject any configuration into the JWT service to achieve this. Just asking for another approach. Regarding refresh tokens, generally, I see two ways in other samples: * Using a random string like you suggested. * Using JWT format. ( I dont know why) Updated: Ah, I guess the jwt can take the advantage of expired date that encoded into the self token without query the db for persistent. I mostly saw it from microservice architecture where a gateway is kinda the first line of token validator,
@@Computerix a lot of people use a jwt token as the refresh token so that it while lasting much longer (a week or so) still has an expire time. using a refresh token that never expires is considered a bad security practice by a lot of people/companies.
@@problemchild959 Correct about the expiration. BUT, you don't need to have the refresh token as a JWT for it to have an expiry date. You can use a random long string, and use an expirationDate field that you check against whenever you're calling your refresh token API to refresh the tokens. If that field has a value date in the past (meaning it expired), you force the user to login again.
I'm sorry for the late response! Here you go : github.com/charbelh3/nestjs-auth-apis (This contains the code for this video and part 2 as well.. Forgot Password / Change Password / Reset Password)
Also please can you help with a video showing how to do an email otp verification upon user signup using firebase authentication methods? It will be very much appreciated
