0

I need to efficiently store a byte[] into a JWT claim value specifically.

Is there anything more efficient than converting the byte[] to base64URL? i.e.

Microsoft.AspNetCore.WebUtilities.Base64UrlTextEncoder.Encode(arrToEnc);

Ultimate goal is to encode a List<UInt16> such that each UInt16 is at most 2 bytes(after normal JWT decode).

Considering byte[] -> UTF8 String. i.e. System.Text.Encoding.UTF8.GetString(arrToEnc);

This is completely separate from how JWT's in general use Base64 to encode them...

Thanks..

pedrofb
  • 37,271
  • 5
  • 94
  • 142
ttugates
  • 5,818
  • 3
  • 44
  • 54
  • Could you compress the content to zip before base64 encoding? Base64 adds 33% overhead. Probably compression is greater – pedrofb Feb 15 '17 at 17:14
  • An alternative is base85, but it only improves 7℅ over base64, is not common and implementations could not support it. See http://stackoverflow.com/questions/1443158/binary-data-in-json-string-something-better-than-base64 I suggest compression – pedrofb Feb 15 '17 at 17:23
  • I can and will use gzip. I will write the encoder and decoder so uncommon is ok. I think ultimately the solution depends on the charset of the 'string' in the claim value. And I encode to that base. – ttugates Feb 15 '17 at 17:25

1 Answers1

1

Base64 adds 33℅ overhead, but could be lesser, depends on the content. An alternative is base85, but it only improves 7℅ over base64, is not common and implementations could not support it. It is not a problem if you control the encoder and decoder. See Binary Data in JSON String. Something better than Base64

You could compress the content. The worst case with base64 is 33℅, The compression ratio you will get will zip is about 30-40℅, but JWT will do an additional base64 encoding when compacting, so even using base85, you will have an overload on your required ratio of 1: 1

You can also add gzip to your server, then the compression ratio will be applied over the full JWT content

Community
  • 1
  • 1
pedrofb
  • 37,271
  • 5
  • 94
  • 142