gloomDev
commented
3 weeks ago For instance, in this solution, you cant logout the user.
Unless I'm mistaken... you can log out users. The auth in this example is semi-stateful because the tokens are also stored in the database, and can be explicitly revoked by the application.
From what I'm seeing (by skimming these articles briefly), arguments are being made against stateless JWTs.
There is still an issue because refresh_token is effectively stateless as is. Instead, you could easily include them in the token database. Or you could do without them and use a longer lived access_token.
Using JWTs as sessions is not recommended by several large security companies and not spring boot themselves and that there is a reason as to why spring security does not have a JWTFilter built in by default.
There are several blog posts advising you from not using JWTs as sessions. That dates back to 2016.
https://developer.okta.com/blog/2017/08/17/why-jwts-suck-as-session-tokens
https://redis.io/blog/json-web-tokens-jwt-are-dangerous-for-user-sessions/
http://cryto.net/~joepie91/blog/2016/06/13/stop-using-jwt-for-sessions/
http://cryto.net/~joepie91/blog/2016/06/19/stop-using-jwt-for-sessions-part-2-why-your-solution-doesnt-work/
https://www.youtube.com/watch?v=GdJ0wFi1Jyo
The latest draft from RFC draft from ietf (the managers of auth2) has updated their recommendations for the implicit flow (authentication and handing out tokens straight to public clients, aka browsers) to SHOULD NOT, meaning that any new development of such logins should not be implemented. And as previously the Resource Owner Password Credentials Grant has the MUST NOT recommendation, which means basically that this should never exist on the internet.
The current recommendations by spring security is to implement Oauth2, using the BFF pattern, following a standard like Open ID connect, which hands out all tokens to browsers using cookies, that have the Secured, HttpOnly, and SameSite flags set.
Which means that all blogs/videos that are showcasing JWTFilters that are using JWTs as sessions are not recommended.
There also several vulnerabilities with the approach in this repo as listed by:
OWASP: https://cheatsheetseries.owasp.org/cheatsheets/JSON_Web_Token_for_Java_Cheat_Sheet.html
IETF: https://datatracker.ietf.org/doc/html/draft-ietf-oauth-security-topics#name-attacks-and-mitigations
Stack Overflow answers: https://stackoverflow.com/questions/77591848/spring-security-6-use-jwt-tokens-instead-of-jsessionid-after-oauth2-login/77592667#77592667
For instance, in this solution, you cant logout the user. And no, deleting the token from the front end does not mean the user is logged out.
JWTs are to be used as single one shot tokens between microservices, and should not be handed out to browsers, especially not be accessible by javascript in browsers, as this is extremely dangerous.