12 ms·

I love JWTs between servers. Between servers and clients, you just end up remaking cookies/sessions. Strictly my experience/opinion. Glad to hear from others.

slt2021 1y ago
you cant generally reuse cookies across domains, because browser controls which domain receive which cookie. Also cookies are not cryptographically signed and thus easily forgeable by the client/browser. JWTs on the other hand allow to be used across domain, so that you can use JWT issued by your IDP on one domain, to be trusted on another domain. crypto signature helps in verifying integrity of data. sessions are usually tied to a single backend/application server. Its hard to reuse a session data across different apps. JWTs on the other hand allow sharing session data across different app servers/microservices.
- gerdesj 1y ago
  "Also cookies are not cryptographically signed and thus easily forgeable by the client/browser." My Apache webby thingies quite happily dole out encrypted cookies: https://httpd.apache.org/docs/2.4/mod/mod_session_crypto.html https://httpd.apache.org/docs/2.4/mod/mod_session_crypto.htm... Your notes on cross site issues are also described there. JWTs are mutually shared secret passable with nobs on - you can store loads of data in them. Cookies are more one shot and one piece of data.
  - formerly_proven 1y ago
    Encryption generally doesn’t provide authentication, so I wouldn’t be surprised if that Apache module allows a user to flip is_admin=0 to 1 because the encryption is sufficiently malleable to do that. Especially because that page mentions 3DES.
- kevlened 1y ago
  > Also cookies are not cryptographically signed and thus easily forgeable by the client/browser While it's true that you could avoid signing cookies, this isn't the default for any server library I'm aware of. If your library doesn't require a secret to use for signing, you should report it. I'm also unaware of JWT libraries that default to "none" for the algorithm (some go against the spec and avoid it entirely), though it's possible to use JWTs insecurely.
gerdesj 1y ago
Cookies are only controlled by the server but obviously can be negotiated for with a secret. JWTs have a mutual secret component built in and far cooler sounding ... stuff. So both ends have to trust the other and prove it with JWT and when cookies are in play, you takes your chances - you can use mutual TLS to get the same trust that JWT gives. I have a web app that I'm doing sysops for which ended up with both. The web devs insisted on JWT and cough "forgot" about the auth bearer bit in the header because their API didn't use it. I ended up amending and recompiling an Apache module for that but to be fair, they will support it in the next version so I can revert my changes. A few db lookups in the Apache proxy JWT module I'm using and you have your claims. On the front of that lot you have Apache session cookies generated when auth succeeds against a PrivacyIDEA instance - ie MFA. I suppose we have cookies for authN and JWT for authZ. Cookies could do both and apart from session I'm not too familiar but it looks like claims would require multiple cookies where JWT does it all in one.
- genghisjahn 1y ago
  I use JWTs with RSA key pairs primarily. I tell the other service to make the pair and send me the public. I never see the private. Then I can verify all their tokens with the public key. This way I don’t have to worry about sharing the secret. It never leaves the other service.
  - some_furry 1y ago
    > Then I can verify all their tokens with the private key. Mmmm. No. You're supposed to use a public key to verify the tokens, not a private key. What library are you using that tolerates this sort of misuse?
  - firesteelrain 1y ago
    I think you meant verify with public key.
    - genghisjahn 1y ago
      Yes. I meant verify with public key. (Facepalm and updated)
deleted 1y ago
[deleted]

slt2021 1y ago

you cant generally reuse cookies across domains, because browser controls which domain receive which cookie. Also cookies are not cryptographically signed and thus easily forgeable by the client/browser. JWTs on the other hand allow to be used across domain, so that you can use JWT issued by your IDP on one domain, to be trusted on another domain. crypto signature helps in verifying integrity of data. sessions are usually tied to a single backend/application server. Its hard to reuse a session data across different apps. JWTs on the other hand allow sharing session data across different app servers/microservices.

gerdesj 1y ago
"Also cookies are not cryptographically signed and thus easily forgeable by the client/browser." My Apache webby thingies quite happily dole out encrypted cookies: https://httpd.apache.org/docs/2.4/mod/mod_session_crypto.html https://httpd.apache.org/docs/2.4/mod/mod_session_crypto.htm... Your notes on cross site issues are also described there. JWTs are mutually shared secret passable with nobs on - you can store loads of data in them. Cookies are more one shot and one piece of data.
- formerly_proven 1y ago
  Encryption generally doesn’t provide authentication, so I wouldn’t be surprised if that Apache module allows a user to flip is_admin=0 to 1 because the encryption is sufficiently malleable to do that. Especially because that page mentions 3DES.
kevlened 1y ago
> Also cookies are not cryptographically signed and thus easily forgeable by the client/browser While it's true that you could avoid signing cookies, this isn't the default for any server library I'm aware of. If your library doesn't require a secret to use for signing, you should report it. I'm also unaware of JWT libraries that default to "none" for the algorithm (some go against the spec and avoid it entirely), though it's possible to use JWTs insecurely.

gerdesj 1y ago

Cookies are only controlled by the server but obviously can be negotiated for with a secret. JWTs have a mutual secret component built in and far cooler sounding ... stuff. So both ends have to trust the other and prove it with JWT and when cookies are in play, you takes your chances - you can use mutual TLS to get the same trust that JWT gives. I have a web app that I'm doing sysops for which ended up with both. The web devs insisted on JWT and cough "forgot" about the auth bearer bit in the header because their API didn't use it. I ended up amending and recompiling an Apache module for that but to be fair, they will support it in the next version so I can revert my changes. A few db lookups in the Apache proxy JWT module I'm using and you have your claims. On the front of that lot you have Apache session cookies generated when auth succeeds against a PrivacyIDEA instance - ie MFA. I suppose we have cookies for authN and JWT for authZ. Cookies could do both and apart from session I'm not too familiar but it looks like claims would require multiple cookies where JWT does it all in one.

genghisjahn 1y ago
I use JWTs with RSA key pairs primarily. I tell the other service to make the pair and send me the public. I never see the private. Then I can verify all their tokens with the public key. This way I don’t have to worry about sharing the secret. It never leaves the other service.
- some_furry 1y ago
  > Then I can verify all their tokens with the private key. Mmmm. No. You're supposed to use a public key to verify the tokens, not a private key. What library are you using that tolerates this sort of misuse?
- firesteelrain 1y ago
  I think you meant verify with public key.
  - genghisjahn 1y ago
    Yes. I meant verify with public key. (Facepalm and updated)

deleted 1y ago

[deleted]