Replies: 1 comment 1 reply
-
Hi @d3bt3ch ! Good question! We cover this in the first couple of paragraphs in the readme introduction to encrypted JWTs. All RFC-defined encryption algorithms MUST be authenticated encryption (AEAD) algorithms, and these guarantee that no-one has manipulated the encrypted JWT in transit. AEAD algorithms provide both encryption and integrity protection (similar to a signed JWT). So when you choose one of the RFC-defined AEAD Algorithms, and pair it with a JWE key management algorithm, you will ensure that your JWT is both encrypted and maintains its digital integrity using appropriate cryptographic primitives in a safe way. For example, as shown in the section on creating a jwe: .encryptWith(key, keyAlgorithm, encryptionAlgorithm) // (3) <--- What you don't want to do is get into schemes that you try to design yourself, like "should I sign then encrypt, or encrypt then sign?", as custom-designed schemes that do one then the other are quite often susceptible to various security flaws. Is there a particular scenario or type of key you want to use to perform JWE authenticated encryption that I could help clarify? For example, if the JWT creator and recipient are two different parties, it's best to use public key (RSA or Elliptic Curve) cryptography, if the creator and the recipient are the same party (e.g. a web server creates and later reads it's own JWT in a session cookie), symmetric keys can be fine. Hopefully this is helpful - what scenario are you trying to address? |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
-
How can we both sign and encrypt a jwt ? Some code examples would be great.
Beta Was this translation helpful? Give feedback.
All reactions