3

If I'm using JWE to send an encrypted JSON message, which will be stored on the client-side, for use with authorization, why would the client need to decrypt this message?

Client attaches the JWE token to all requests. Server identifies client using JWE token and responds or denies request. Throughout, only the server can decrypt.

If there's no problem with this structure, what's the best way to implement it? Should I use asymmetric encryption and not provide a public key (is this possible within the JWE spec)?

Along these lines, what's the best way to ensure the JWE token hasn't been intercepted and, though not decrypted, attached to a malicious server request, effectively allowing an attacker to impersonate the client?

Also, are there any other security concerns I'm missing?

twils0
  • 2,431
  • 2
  • 12
  • 24

1 Answers1

3

If I'm using JWE to send an encrypted JSON message, which will be stored on the client-side, for use with authorization, why would the client need to decrypt this message?

When the client needs to read some data contained in the JWT, such as the user id or the expiration date. This is not needed in all scenarios.

Client attaches the JWE token to all requests. Server identifies client using JWE token and responds or denies request.

Yes, this is the usual authorization flow

Throughout, only the server can decrypt.

Not necessarily. The server can encrypt the encryption key with the recipient's public key using for example RSAES-OAEP. Then the recipient will be able to decrypt the JWT with his private key

If there's no problem with this structure, what's the best way to implement it? Should I use asymmetric encryption and not provide a public key (is this possible within the JWE spec)?

It depends on your requirement. If you want that a client could decrypt the JWT you need to provide the key or use assymetric encryption and encrypt the message to the recipient

Along these lines, what's the best way to ensure the JWE token hasn't been intercepted and, though not decrypted, attached to a malicious server request, effectively allowing an attacker to impersonate the client?

Posession of JWT is the proof-of-authentication. If a token is stolen then the attacker can impersonate user. So you need to protect it to mitigate the risk:

  • Mainly use HTTPS to encrypt the communication channel

  • Store it securely on the client.

pedrofb
  • 37,271
  • 5
  • 94
  • 142
  • 2
    It is also necessary to pin the server certificate in order to prevent MITM attacks. – zaph Jul 18 '17 at 17:46
  • Or alternatively, it sounds like pedrofb is suggesting I store it securely on the client and use HTTPS - to prevent attacks. If an attacker somehow gets the JWE token then they've gotten access - period. At least in that case, however, they do not have access to the contents of the JWE token, which is what drew me to JWE over JWS in the first place. – twils0 Jul 18 '17 at 18:17
  • i try to explain. A JWT can be digitally signed (JWS) and/or encrypted (JWE). To avoid JWT hickjacking, you should use an encrypted SSL/TLS channel. Note that if an attacker gets a token he could use it to be authenticated, even if the token is encrypted. A SSL client must verify the identity of server to prevent MITM. This is done checking if the issuer of the server certificate is present in the client trust store. Certificate pinning is technique on SSL connections which include directly the server certificate in the client truststore instead of root CA. This avoid MITM – pedrofb Jul 18 '17 at 18:54
  • Thanks for your help pedrofb. I should have thanked you earlier haha. – twils0 Jul 18 '17 at 18:58
  • Summarizing: You should always use HTTPS and check server certificate. Encrypt JWT only if you need to hide info to client, or you want to use JWT ro interchange data safely encrypting data to recipient( not for the authorization context you described) – pedrofb Jul 18 '17 at 18:58
  • Happy to help! Consider to mark the answer as accepted and upvote if you have enough reputation – pedrofb Jul 18 '17 at 19:00
  • Thanks - I see what you're saying. The HTTPS process already verifies the source of the connection. I've got to look into certificate pinning. Thanks - very helpful +1 – twils0 Jul 18 '17 at 19:06