difference to JWT

[tcurdt]

Not really a bug or a feature request - but a request for clarification in the README.

Why would one use the this project over JWT?
JWT also supports signing and encryption - and is a standard.

I am not making a case for either - but it would be nice to read a position on this.

[elithrar]

Cookies are managed by the browser’s security model, and don’t need to be surfaced to JavaScript, unlike JWTs. You can’t pass a JWT in a request unless you can modify headers, or (often insecure) append to the query params. Storing them in LocalStorage allows any other JS to access them. JWTs also have significant complexity: most folks speak about being able to validate them remotely, but few clients actually do. There are some benefits: standardized format, and if you’re not inside a browser-like environment, they can be useful. Many HTTP clients still work with cookies though (iOS, Android). See https://jolicode.com/blog/why-you-dont-need-jwt + https://www.pingidentity.com/fr/company/blog/posts/2019/the-hard-parts-of-jwt-security-nobody-talks-about.html + https://www.google.com/amp/s/scotch.io/bar-talk/why-jwts-suck-as-session-tokens/amp

…

On Tue, Jan 28, 2020 at 11:20 AM Torsten Curdt ***@***.***> wrote: Not really a bug or a feature request - but a request for clarification in the README. Why would one use the this project over JWT? JWT also supports signing and encryption - and is a standard. I am not making a case for either - but it would be nice to read a position on this. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#70?email_source=notifications&email_token=AAAEQ4DUZD46LFKVB42FY43RABLM3A5CNFSM4KMVIM5KYY3PNVWWK3TUL52HS4DFUVEXG43VMWVGG33NNVSW45C7NFSM4IJIYJDA>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAAEQ4A6GOF6BLU56DXABKDRABLM3ANCNFSM4KMVIM5A> .

[tcurdt]

The JWT can be used as cookie or a header. Where you store them or how you send them certainly is an important aspect. But JWT is a signed or even encrypted JSON blob that is standardized. Which seems quite close to what this lib does.

I am well aware of some of the drawbacks, but those seem to apply to the securecookie project as well.
Other than a maybe simpler implementation I am still not sure why securecookie should be used over JWT.

[elithrar]

I mean, the simpler implementation is the thing. Cookies existed long before JWTs, and JWT signing & the spec have caused multiple security challenges in the past. Complex crypto that is exposed to the user is a misfeature.

…

On Wed, Jan 29, 2020 at 8:39 AM Torsten Curdt ***@***.***> wrote: The JWT can be used as cookie or a header. Where you store them or how you send them certainly is an important aspect. But JWT is a signed or even encrypted JSON blob that is standardized. Which seems quite close to what this lib does. I am well aware of some of the drawbacks, but those seem to apply to the securecookie project as well. Other than a maybe simpler implementation I am still not sure why securecookie should be used over JWT. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#70?email_source=notifications&email_token=AAAEQ4F4NBZZKPTCC5FKH5TRAGBKRA5CNFSM4KMVIM5KYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEKHG2BQ#issuecomment-579759366>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAAEQ4EWN2A6WTGYEHBCMA3RAGBKRANCNFSM4KMVIM5A> .

[danielvladco]

A big drawback of JWT in my opinion is that the payload is base64 encoded, meaning it can be easily decoded and expose internal or even sensitive data. Check https://www.ory.sh/hydra/docs/advanced/#json-web-tokens for example

[tcurdt]

A big drawback of JWT in my opinion is that the payload is base64 encrypted, meaning it can be easily decrypted and expose internal or even sensitive data. Check https://www.ory.sh/hydra/docs/advanced/#json-web-tokens for example

There is no such thing as "base64 encryption" - it's an encoding. Being easy to decode is a given.
And nobody (in the right mind) would use JWT without encryption.

If you enforce a certain encryption with JWT, the difference to securecookie isn't quite that obvious (to me).

Clearing up that difference was the original intend of the issue/question.

[danielvladco]

@tcurdt you are right, I meant encoded.

But even if you use TLS you still need to store the jwt on the client side as a cooke or in localStorage where it is unencrypted.

[tcurdt]

But even if you use TLS you still need to store the jwt on the client side as a cooke or in localStorage where it is unencrypted.

Why would you want to do that?

All you need is the encrypted and encoded token to gain access to server side resources.
On the server side it can be decoded and decrypted.

[danielvladco]

But even if you use TLS you still need to store the jwt on the client side as a cooke or in localStorage where it is unencrypted.

Why would you want to do that?

All you need is the encrypted and encoded token to gain access to server side resources. On the server side it can be decoded and decrypted.

Ok, I think I understand what you mean, when you say token encryption you refer to JWE? I was thinking about TLS encryption.

But why you say "nobody (in the right mind) would use JWT without encryption" ? I've seen a lot of applications use JWT without encryption, actually from my experience the majority don't use JWE

[elithrar]

The payload doesn’t have to be encrypted in most cases: an authenticated token (a JWT) prevents the user from modifying the contents. It doesn’t matter if they can see the payload - a session ID, their user ID and/or some ACL they have - because those are typically opaque. You can’t change them as you (the user) can’t generate a valid authenticated hash of those changes without the key.

[jamesli2021]

I think this discussion is still not complete. The question is whether a stolen JWT token can be use to impersonate user? There are other security mechanism we can employ in addition to JWT or other encrypted session.

[bencodesall]

I think this discussion is still not complete. The question is whether a stolen JWT token can be use to impersonate user? There are other security mechanism we can employ in addition to JWT or other encrypted session.

I think @jamesli2021 has a good question here. I'd love to hear some more talk on this, as well as the mentioned "other security mechanism[s]" that can be used with JWT and encrypted sessions.

Any good concise references for a green-ish auth/auth-er to find good and accessible info?