I am just curious to know if the application has end to end TLS communication (HTTPS), why do we need again JSON web encryption to encrypt the JSON token considering sensitive data is passed in JWT token?
Any thoughts/clarififactions?
2
-
In "end to end TLS", what exactly do you consider to be the ends?– BergiCommented Aug 1 at 17:44
-
at rest is the key here...(either in memory or written to storage) client-side exploits can get at this "sensitive data".– browsermatorCommented Aug 6 at 20:29
Add a comment
|
2 Answers
TLS only protects data in transit between two network hosts. Each host can see the data as plaintext. If the data is passed around over multiple TLS connections, then it can be exposed to a large number of different hosts. If the data isn't sensitive, or if the hosts are supposed to see the data, this is fine. But this may not be the case.
In comparison, JWE messages can only be read by those who have the necessary key. No matter how many hosts the message passes through, none of them can access the plaintext content unless they're the intended receiver (or have stolen the key).
So TLS and JWE are complementary techniques. TLS is strictly for network-level encryption between two hosts. JWE can be used to encrypt data between arbitrary parties (like applications which aren't directly connected or even people). Note that JWE requires the use of TLS according to RFC 7516.
If you're specifically talking about protocols like OAuth, then JWE makes sense for Access Tokens which contain data that is exclusively intended for the Resource Server, not the Client. This cannot be implemented with TLS, because the Client gets the plaintext traffic from the Authorization Server, including the Access Token.
HTTPS encrypt the connection between the client and the server, so only the client and the server can see the contents of the JWT. JWE is useful if you also want to hide the contents from the client.
HTTPS is generally recommended for every web app. JWE is only useful in specific cases. Some users of JWE use it as a defense-in-depth measure, to make things secure even though there is no specific attack scenario it defends against.
