Would encrypting a signed JWT prove viable to secure claims payload?

Question

I am working on a server-client web application, and as an authentication scheme, I am issuing base64 encoded json web tokens. Consider the following token...

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiYWRtaW4iOnRydWV9.TJVA95OrM7E2cBab30RMHrHDcEfxjoYZgeFONFh7HgQ

Decoded as such...

{
  "alg": "HS256",        // header
  "typ": "JWT"
},
{
  "sub": "1234567890",   // payload
  "name": "John Doe",
  "admin": true
},
HMACSHA256(base64UrlEncode(header) + "." + base64UrlEncode(payload), 'secret') // signature 

My concern is with the payload portion of this token, where I wish to supply defined claims e.g. "role": "readonly". My concern is with these values being visible and tampered with by the end user once issued. Modifying this portion will not invalidate the signature check. I don't wish to persist any data on the server to re-check/compare issued tokens - I wish to keep the server completely stateless.

I thought maybe signing the token, encrypting it via AES 256, and using this as my "token". The flow would be summarized as such...

1. generate and sign base64 encoded token
2. encrypt token server side via AES 256

3. Issue encrypted token to client

   ---

4. request recieved, encrypted token supplied

5. decrypt token server side
6. validate base64 encoded original token signature (now able to ensure claims have not been altered)

My thoughts are, the claims (payload) will not be seen, and any tampering with this encrypted value will obviously not decrypt as expected server side. My question is - is this viable? I couldn't find much on the web for encrypting whole tokens. Is there a better way?

Answer 1

I believe you are asking two questions:

1. does changing payload invalidate signature: TL;DR: yes
2. does adding encryption over JWT give you authenticity of content: TL;DR: don't encrypt yourself, use JWE!

Here are the answers in more detail:

(1) According to the specifications, https://www.rfc-editor.org/rfc/rfc7515.txt

the signature of a signed JWT (JWS) is computed over the protected header as well as the payload:

(see section 5.1. Message Signature or MAC Computation)

Compute the JWS Signature in the manner defined for the
       particular algorithm being used over the JWS Signing Input
       ASCII(BASE64URL(UTF8(JWS Protected Header)) || '.' ||
       BASE64URL(JWS Payload)). 

So changing the payload should invalidate the signature.

(2) Do NOT encrypt your own JWT!! There is an actual specification that defines how to encrypt JWTs (called JWE): https://www.rfc-editor.org/rfc/rfc7516.txt

JWE uses authenticated encryption which means that the plaintext is first encrypted and then an integrity check is produced over the ciphertext. You can get more info on what the plaintext looks like from Section 5.1 of above Spec.

It is possible to securely store access policies in the payload of your JWT if you use either encrypted or signed formats. You may want to use encrypted if you don't want the client or other parties to have any knowledge of the policy data. If you don't care who can read it and you only care about who can change the values, use signatures only.

Remember though that the more security you add, the bigger the performance impact so use your judgement on what is needed.

Final note: Key management of the signature and encryptions keys also becomes an important issue for you to consider, because at the end of the day, whoever has access to the keys can decrypt your JWE or modify the signature of your JWS. So make sure you use good safety practices in where you store the actual keys, who has access to them and how they are used and kept in memory.