> Paseto is everything you love about JOSE (JWT, JWE, JWS) without any of the many design deficits that plague the JOSE standards.
Needs to be substantiated. Where's the comparison? There's only a link to a website and presentation talking about the downsides of JOSE, but the only one i see for JWT is poor implementations failing when the algorithm supplied client-side is invalid. That's a trivial bug and hopefully long since fixed. Is that it?
I think, having given it a read in the past, the idea is a little like TLS 1.3 is to previous versions of TLS - it removes the choice to implement badly.
Yes, I agree, accepting any old signature algorithm is a trivial bug in the application that uses JWTs, but I guess it's something that's happened enough to be an issue.
I think the real question is - what major components/projects support these as well as/instead of JWTs? Is it reaching any sort of critical mass, or is it a well-designed curiosity?
which is quite informative. So from what I can tell the core of the complaint with JWT is having the ability to let someone set alg=None.
Correct me on this but further reading also tells me that Paseto is better suited for websites that have access to server-side session storage. One of the reasons for widespread adoption of JWT is its ability to work with JS/SPAs and not require a server side workflow. So Paseto might be aimed towards the ASP.NET/Spring type setups.
Another thing to factor in is support from identity providers like Okta and Auth0, for a lot of people and enterprises, having momentum and names behind these protocols is a deciding factor. Hopefully if this RFC pans out, maybe the Identity providers can offer Paseto as an option.
> So from what I can tell the core of the complaint with JWT is having the ability to let someone set alg=None.
No, the core complaint is that JWT ignores the hard-learnt lessons from the past couple of decades of security engineering and repeated terrible choices that have caused a plague of vulnerabilities in the past. It’s no surprise then, that practically every JWT implementation has been completely broken. alg=none is a symptom, not the root cause.
> Correct me on this but further reading also tells me that Paseto is better suited for websites that have access to server-side session storage. One of the reasons for widespread adoption of JWT is its ability to work with JS/SPAs and not require a server side workflow. So Paseto might be aimed towards the ASP.NET/Spring type setups.
No, that’s not the case. You can use Paseto anywhere you can use JWT. It was designed to be a replacement for JWT, so it would be a bit odd for it not to support the same use-cases.
8 comments
[ 0.17 ms ] story [ 37.8 ms ] thread> Paseto is everything you love about JOSE (JWT, JWE, JWS) without any of the many design deficits that plague the JOSE standards.
Needs to be substantiated. Where's the comparison? There's only a link to a website and presentation talking about the downsides of JOSE, but the only one i see for JWT is poor implementations failing when the algorithm supplied client-side is invalid. That's a trivial bug and hopefully long since fixed. Is that it?
Yes, I agree, accepting any old signature algorithm is a trivial bug in the application that uses JWTs, but I guess it's something that's happened enough to be an issue.
I think the real question is - what major components/projects support these as well as/instead of JWTs? Is it reaching any sort of critical mass, or is it a well-designed curiosity?
https://github.com/fernet/spec/blob/master/Spec.md
https://branca.io/
https://developer.okta.com/blog/2019/10/17/a-thorough-introd...
which is quite informative. So from what I can tell the core of the complaint with JWT is having the ability to let someone set alg=None.
Correct me on this but further reading also tells me that Paseto is better suited for websites that have access to server-side session storage. One of the reasons for widespread adoption of JWT is its ability to work with JS/SPAs and not require a server side workflow. So Paseto might be aimed towards the ASP.NET/Spring type setups.
Another thing to factor in is support from identity providers like Okta and Auth0, for a lot of people and enterprises, having momentum and names behind these protocols is a deciding factor. Hopefully if this RFC pans out, maybe the Identity providers can offer Paseto as an option.
No, the core complaint is that JWT ignores the hard-learnt lessons from the past couple of decades of security engineering and repeated terrible choices that have caused a plague of vulnerabilities in the past. It’s no surprise then, that practically every JWT implementation has been completely broken. alg=none is a symptom, not the root cause.
> Correct me on this but further reading also tells me that Paseto is better suited for websites that have access to server-side session storage. One of the reasons for widespread adoption of JWT is its ability to work with JS/SPAs and not require a server side workflow. So Paseto might be aimed towards the ASP.NET/Spring type setups.
No, that’s not the case. You can use Paseto anywhere you can use JWT. It was designed to be a replacement for JWT, so it would be a bit odd for it not to support the same use-cases.