Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

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.



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.


Isn't that what OIDC/JWKS is? That also uses PKI to verify JWT with public keys.


I think you meant verify with public key.


Yes. I meant verify with public key. (Facepalm and updated)


It’s easy to get mixed up.


> 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?


Who uses apache reverse proxy in 2025?




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: