Given the critique raised in those articles about the inability to do session invalidation without server state, this means the dream of stateless backend for auth is dead, right?
So paseto fixes JWT, but the use cases should be limited to like “here’s a little signed parcel of goodies” / “here’s a little encrypted message”, not “here’s my session token”?
well, either one can also be used to include a session token, or can be used as a session token, but then they aren’t really stateless: they need some other check, such as a round trip to a database or cache, to check if they are still valid. Most likely you don’t want to do this,, the link giving more reasons why, but basically it is at cross purposes for why you would use some sort of token to begin with. It can have valid uses, but most likely it’s an architectural pattern that you don’t want to go down.
For stateless authentication however, yes, it’s limited to the “here’s a little encrypted message” sort of functionality.
Additionally, as much as I prefer the lack of crypto-agility (basically, the ability to pick and choose algorithms within a cryptographic system) in Paseto, Branca, or Macaroons, their deployments are fairly limited: most systems and services use JWTs. So:
if you wholly own the ecosystem and want to send bundles of things, Paseto can be a safer alternative because it is “misuse resistant:” it’s been designed in such a way that it is very difficult to use incorrectly
if you do not wholly own the ecosystem and need to interact with other services, follow as many best practices as you can (such as this one from PortSwigger or this one from Auth0.)
you also have to hope that all the services you interact with also don’t require something silly
if your service doesn’t need to send bundles of stuff around, opaque session identifiers and traditional session management can still be a useful thing
I hope this makes sense, but also happy to clarify.
tl;dr: yes, Paseto fixes JWTs and also should basically just be used for securing bundles of stuff, with the caveat that not many external services and systems use Paseto just yet
inability to do session invalidation without server state
I am thinking of JWT as sort of a ‘signature’, where the authentication server states:
this user has been authenticated for the next 2 hours.
So every 2 hours a client has to ask for the ‘refresh token’, or else the backend will consider the signature (the JWT) - invalid.
Therefore, some point in time, the refresh token becomes invalid (if a user is deprovisioned, for example).
Wouldn’t that result in ‘eventual’ session invalidation?
As I understood the argument linked from the blog post in the comment above:
Doing this will work, but you will lose the ability to invalidate a session. Ie you can’t force-log-out a user.
If you’re ok with that, this approach works fine, but many devs don’t realize that using JWTs as session tokens means giving up the ability to log out / invalidate sessions.
Right, eventual is the key word there. You can set the expire time on the JWT/Paseto at each request and return a new valid token to the client for the next request if you really wanted to, which gives you session invalidation as you can just not return a new one. If you are going to work this hard, it might be easier to just use session tokens though, so you can just invalidate whenever you want.
Most people don’t work that hard or don’t realize it’s a trade-off.
Nice that they skip over the bajillion security concerns with JWT. Paseto is a sane implementation of JWT’s without the bajillion security issues: https://paseto.io/
Given the critique raised in those articles about the inability to do session invalidation without server state, this means the dream of stateless backend for auth is dead, right?
So paseto fixes JWT, but the use cases should be limited to like “here’s a little signed parcel of goodies” / “here’s a little encrypted message”, not “here’s my session token”?
well, either one can also be used to include a session token, or can be used as a session token, but then they aren’t really stateless: they need some other check, such as a round trip to a database or cache, to check if they are still valid. Most likely you don’t want to do this,, the link giving more reasons why, but basically it is at cross purposes for why you would use some sort of token to begin with. It can have valid uses, but most likely it’s an architectural pattern that you don’t want to go down.
For stateless authentication however, yes, it’s limited to the “here’s a little encrypted message” sort of functionality.
Additionally, as much as I prefer the lack of crypto-agility (basically, the ability to pick and choose algorithms within a cryptographic system) in Paseto, Branca, or Macaroons, their deployments are fairly limited: most systems and services use JWTs. So:
I hope this makes sense, but also happy to clarify.
tl;dr: yes, Paseto fixes JWTs and also should basically just be used for securing bundles of stuff, with the caveat that not many external services and systems use Paseto just yet
I am thinking of JWT as sort of a ‘signature’, where the authentication server states: this user has been authenticated for the next 2 hours.
So every 2 hours a client has to ask for the ‘refresh token’, or else the backend will consider the signature (the JWT) - invalid. Therefore, some point in time, the refresh token becomes invalid (if a user is deprovisioned, for example).
Wouldn’t that result in ‘eventual’ session invalidation?
As I understood the argument linked from the blog post in the comment above:
Doing this will work, but you will lose the ability to invalidate a session. Ie you can’t force-log-out a user.
If you’re ok with that, this approach works fine, but many devs don’t realize that using JWTs as session tokens means giving up the ability to log out / invalidate sessions.
Right, eventual is the key word there. You can set the expire time on the JWT/Paseto at each request and return a new valid token to the client for the next request if you really wanted to, which gives you session invalidation as you can just not return a new one. If you are going to work this hard, it might be easier to just use session tokens though, so you can just invalidate whenever you want.
Most people don’t work that hard or don’t realize it’s a trade-off.
this seems interesting, I think I mention many security concerns in the article too. https://www.cbsnews.com/news/okta-stock-breach-hack/, nothing seems very safe nowadays everything has a vulnerability.
Security is not an absolute and until people realize security is a set of trade-offs, it’s hard to talk reasonably about where reasonableness happens.
JWT however is just a disaster. All Paseto does is cut out all the ridiculousness, to make JWT something within the realm of useful.
https://www.howmanydayssinceajwtalgnonevuln.com/
yay, 1 month!
stateless … persistence? Like mute sermon? Like O(0)?