mirror of
https://github.com/pocket-id/pocket-id.git
synced 2025-12-06 09:13:19 +03:00
🚀 Feature: Make key type & size configurable, and support EC keys #302
Reference in New Issue
Block a user
Delete Branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @ItalyPaleAle on GitHub.
Feature description
Currently, pocket-id signs JWTs with RSA 2048 keys, which are not configurable. While RSA with a key size of 2048 is still acceptable until 2030 per NIST's guidelines, there are other algorithms that are considered better options.
It would be great if pocket-id allowed configuring the type (algorithm) and size of the key. For example, allowing using RSA keys with 3072 bits, or allowing elliptic curve signing algorithms including ECDSA (JWT alg
ES256) or EdDSA (JWT algEdDSA, e.g. withcrv: Ed25519).For more information, this is a good read: https://www.scottbrady.io/jose/jwts-which-signing-algorithm-should-i-use
Pitch
See above :)
@stonith404 commented on GitHub:
Pocket ID should stay simple OIDC provider and such settings would just overcomplicate it.
As
RS256is still the most used JWT encryption algo and is still secure, I wouldn't change that.We could increase the size of the key to
3072though, feel free to create a PR.@ItalyPaleAle commented on GitHub:
Thanks, I understand your point.
May I suggest an option that would allow supporting EC without adding user-facing complexity?
Pocket ID could detect the algorithm of the private key and use the corresponding JWS algorithm. This would only impact people who update the private key manually.
There are quite significant benefits to using EC, such as much smaller signatures (so much smaller JWTs).
@kmendell commented on GitHub:
@stonith404 Ill have to defer to you on this one.
@stonith404 commented on GitHub:
Thanks, I actually didn't know that.
Is EC widely supported by JWT libraries? If yes, we could just replace the RSA with ECDSA, right?
@kmendell commented on GitHub:
Until stonith404 replies about his thoughts on this, i am adding the Need more upvotes label.
@ItalyPaleAle commented on GitHub:
@stonith404 how would you feel about me changing the format of the (private) key file to a JWK (JSON) instead of PCKS#1 (PEM)? This would allow being more flexible with different kinds of keys. It would also contain additional info such as the key ID, so it can be computed just once.
Note this is just about the format used to encode the private key on disk, using JWK (so JSON) instead of PKCS#1
It's not a strict requirement but it would make things easier when supporting other keys/algos. For example, PKCS#1 supports RSA keys only, while EC keys usually use PKCS#8 (which can also support RSA keys) or a different ASN.1 encoding (X9.62).
Upon startup, if there's a PEM file existing, we'd convert it to JWK.
@stonith404 commented on GitHub:
Okay, I see. If the changes are only small (which I believe they are), you can create a PR if you would like to.
@ItalyPaleAle commented on GitHub:
I don't think it's as universally supported by JWT libraries. Going by what I see here: https://jwt.io/libraries some libraries only support RSA.
Solutions like Auth0 let you choose if you want RSA or ECDSA for each app (OAuth client). That may be much more complexity than you'd be willing to accept here.
@stonith404 commented on GitHub:
@ItalyPaleAle Yes, this would make sense.