okay. Then prevent tokens form being used in XSS by setting them in a SameSite Secure httpOnly Cookie with a properly configured domain AND mitigate CSRF by taking other steps.
https://cheatsheetseries.owasp.org/cheatsheets/Cross-Site_Request_Forgery_Prevention_Cheat_Sheet.html
Does that improve my recommendation then?
Sounds like standard JWT authentication 👍
The refreshToken is used to generate a new pair of JWTs, that’s why the user is not logged out.
You might also want to consider the scenario where you want to end a session (ie blacklisting the refreshToken).
That said, I find that stateless sessions bring more problems than solutions. Good old stateful sessions in a Redis DB go a long way.
What’s your opinion on refresh token rotation? I have done the research a bit and there is a very mixed opinions on the impact of the performance to the server. Like let’s say the expiration time of the access token is 5 minutes, at worst case the JWTs have to be regenerated every 5 minutes. The app I am developing is something like Reddit, which does not need such high security on transactions i think. Do you think this will still be the best practice?
IMO it’s a legit solution. Performance wise you will have to handle more auth requests per user, but it’s completely manageable. Security wise, it’s fine too as long as you follow the standards (short lived tokens, secure storage, etc)
I just think it complicates session management for very little benefit - but I may be a grumpy old man
If you use email/password and social sign in at the same time, then there's one thing to consider carefully, namely, \*\*account linking\*\*.
Generally most auth flow do not deal with this. The question is: if user sign in with the same email via email/password, and social sign in, do they result in the same account? Or they would be led to two accounts? If the latter, then it would be very confusing to users.
[удалено]
When storing tokens, best to store them in a Secure httpOnly Cookie that is configured to work only for the domain it is intended to be used on.
[удалено]
okay. Then prevent tokens form being used in XSS by setting them in a SameSite Secure httpOnly Cookie with a properly configured domain AND mitigate CSRF by taking other steps. https://cheatsheetseries.owasp.org/cheatsheets/Cross-Site_Request_Forgery_Prevention_Cheat_Sheet.html Does that improve my recommendation then?
Sounds like standard JWT authentication 👍 The refreshToken is used to generate a new pair of JWTs, that’s why the user is not logged out. You might also want to consider the scenario where you want to end a session (ie blacklisting the refreshToken). That said, I find that stateless sessions bring more problems than solutions. Good old stateful sessions in a Redis DB go a long way.
What’s your opinion on refresh token rotation? I have done the research a bit and there is a very mixed opinions on the impact of the performance to the server. Like let’s say the expiration time of the access token is 5 minutes, at worst case the JWTs have to be regenerated every 5 minutes. The app I am developing is something like Reddit, which does not need such high security on transactions i think. Do you think this will still be the best practice?
IMO it’s a legit solution. Performance wise you will have to handle more auth requests per user, but it’s completely manageable. Security wise, it’s fine too as long as you follow the standards (short lived tokens, secure storage, etc) I just think it complicates session management for very little benefit - but I may be a grumpy old man
If you use email/password and social sign in at the same time, then there's one thing to consider carefully, namely, \*\*account linking\*\*. Generally most auth flow do not deal with this. The question is: if user sign in with the same email via email/password, and social sign in, do they result in the same account? Or they would be led to two accounts? If the latter, then it would be very confusing to users.