-
Notifications
You must be signed in to change notification settings - Fork 74
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Asymmetric JWTs? #95
Comments
The PR is up: #99. |
But the question is: why? What is the advantage here? RS256 JWTs might make sense in a scenario where the creation and consumption of JWT tokens is decoupled. Here, where that is not the case, it only adds complexity. The asymetric crypto operations are inherently more complex (more code, bigger binary size, more possibilities for bugs) and slower. |
Generally asymmetric keys are much safer than a single symmetric key. Additionally asymmetric keys enable more complex deployments where tokens are generated by another service based on per-device credentials (like hashicorp Vault). |
That is true if encryption/decryption or signing/verification happen in different places. Then you need the private key only for signing/decryption and encryption/verification can use the public key. That means the secret has two only be in one place, not in two places. In the context where we only have a single instance of attic, which does both: signing and verification of JWT tokens, you don't gain anything by using asymmetric crypto. There are losses though: crypto operations are slower, and setting up a public/private key pair is more complicated than using a symmetric key. I agree that for more complex deployments you may want to use asymmetric crypto. For speed, how bad is it? According to some random benchmark I found RS256 verification is may 5x slower than HS256. I can imagine scenarios (many small requests) where this would lead to a significant increase in CPU usage. In a scenario where few users are doing many requests, you could alleviate some of the performance loss by e.g. caching (a limited number of) hashes of already verified JWT tokens. Otherwise, maybe people should have a choice between RS256 and HS256 🤷 |
Slower is rarely a good argument for accepting less secure setups, We are talking milliseconds here. Database lookups are in the order of 10's-100's of milliseconds at best. So performance is not a blocking issue here. On top of that, the verification step for asymmetrics keys is very fast. The sign step is generally slower (again, milliseconds). Signing happens way less then verifying. The take-away here is that asymmetric crypto is just fine. Additionally RS256 support doesn't prevent HS256 support. If you want to use HS256, that's fine, and it will work. That should not prevent other people from using different algos. JWT/JWK has pretty good support for differentiation here. |
You're comparing network latency and CPU load. Well, the PR (#177) was merged, and it seems like there's still the choice to use HS256. So I guess all is good. Let's close this issue. |
Would you be interested in a patch to make attic's JWTs switch to RS256, which is an asymmetric publ/priv key for signing / validating?
The text was updated successfully, but these errors were encountered: