The use of trusted jwt libraries which outsource registration and authentication has massive benefits such as SSO and reducing the risk of vulnerabilities (user reg/auth being handled by a dedicated party).
There’s no reliance on a database or state management, which can be useful under some conditions.
In my eyes, the problem is reliance of the authorisation header instead of cookies, this has some benefits but is also a massive deviation away from 20 years of websec. Granted all of http spec is a giant nasty hack, so it’s not really jwts fault.
It depends on your definition of session (e.g. if you’re referring to a cookie, or if you’re referring to the use of JSESSIONID or similar). In both cases, JWT is just the token and how and where it’s transferred aren’t spec defined. I susupect the reason for the authorization header to be used is to prevent csrf attacks or to better facilitate SPAs, but I’ve never researched it.
You could technically use SSO with any other auth token, or exchange it during the auth process, but ultimately having metadata about the user in near clear text is useful.
Don’t get me wrong, I think jwt and the rest of websec is a total fucking mess, but jwt is far from the worst offender.
There’s no reliance on a database or state management, which can be useful under some conditions.
In my eyes, the problem is reliance of the authorisation header instead of cookies, this has some benefits but is also a massive deviation away from 20 years of websec. Granted all of http spec is a giant nasty hack, so it’s not really jwts fault.