3 ms·

JWTs are a pretty great solution for various authentication and authorization related problems, like OAuth tokens, password reset tokens and the like. Using an

by necubi 12y ago

JWTs are a pretty great solution for various authentication and authorization related problems, like OAuth tokens, password reset tokens and the like. Using an information-bearing (and signed) token like a JWT tends to make your web apps less stateful and simpler, by offloading the problems of determining authorizations to a single, central location. The main downside is that the representation (base64-encoded json) is pretty bulky for something that might be used in HTTP headers and URLs, but it does make them easy to debug.

haakon 12y ago
This seems like a case where Base-85 [1] would have been a better choice than Base64. [1] http://rfc.zeromq.org/spec:32 http://rfc.zeromq.org/spec:32
- BrandonM 12y ago
  Why would you consider Z85 to be a better choice? When you take URI encoding into account, Base64 is both simpler (no need for %-encoding)[0] and more space efficient (1.75 URI characters per byte for Z85, and 1.33 for Base64)[1]. The very first line on jwt.io says, JSON Web Token (JWT) is a compact URL-safe means of...; being URI-safe appears to be an explicit design decision. [0] All but six of Z85's special characters get encoded by Javascript's encodeURIComponent: : + = ^ / ? & < > [ ] { } @ % $ # [1] URI-safe versions of Base64 (as used by JWT) use 4 characters for every 3 bytes. Z85 uses 5 characters for every four bytes, but 17 of those 85 characters require three URI characters to represent, meaning that a Z85-encoded byte requires 1.75 URI characters per byte on average: (68 * 1 + 17 * 3) / 85 = 1.4 uri_chars/char 1.4 * 5 / 4 = 1.75 uri_chars/byte
  - haakon 12y ago
    Thanks, that's a nicely explained correction.
- nly 12y ago
  The HTTP standard actually allows 90 distinct octets in cookie values, but I suppose you're not going to quibble over <2% coding efficiency given Z85s other advantages. http://tools.ietf.org/html/rfc6265#section-4.1.1 http://tools.ietf.org/html/rfc6265#section-4.1.1
jfroma 12y ago
Yes, this is a real problem, tokens can get very large if you put too much information. HTTP does not define any limit for headers, but most of the Web Servers have a default limit, Apache 8kb, IIS 16kb, nginx 4kb (see this question on SO [1]). If your JWT exceeds these limits you will get a "413 Entity Too Large". It gets only worse if you need to use a query string instead of a header because the limits are lower and IE has a limit too [2]. Solution: carefully design your JWT, what information you will put on there. You usually don't need everything, store only the things you will use on every request, like the user id, name, email, roles are good candidates. Do not try to put the entire Facebook or Linkedin profile on a JWT. Beside the limits, it will make the request bigger to transport and maybe even slower to verify. [1]: http://stackoverflow.com/questions/686217/maximum-on-http-header-values http://stackoverflow.com/questions/686217/maximum-on-http-he... [2]: http://stackoverflow.com/questions/417142/what-is-the-maximum-length-of-a-url-in-different-browsers http://stackoverflow.com/questions/417142/what-is-the-maximu...

by necubi 12y ago

haakon 12y ago

This seems like a case where Base-85 [1] would have been a better choice than Base64. [1] http://rfc.zeromq.org/spec:32 http://rfc.zeromq.org/spec:32

BrandonM 12y ago
Why would you consider Z85 to be a better choice? When you take URI encoding into account, Base64 is both simpler (no need for %-encoding)[0] and more space efficient (1.75 URI characters per byte for Z85, and 1.33 for Base64)[1]. The very first line on jwt.io says, JSON Web Token (JWT) is a compact URL-safe means of...; being URI-safe appears to be an explicit design decision. [0] All but six of Z85's special characters get encoded by Javascript's encodeURIComponent: : + = ^ / ? & < > [ ] { } @ % $ # [1] URI-safe versions of Base64 (as used by JWT) use 4 characters for every 3 bytes. Z85 uses 5 characters for every four bytes, but 17 of those 85 characters require three URI characters to represent, meaning that a Z85-encoded byte requires 1.75 URI characters per byte on average: (68 * 1 + 17 * 3) / 85 = 1.4 uri_chars/char 1.4 * 5 / 4 = 1.75 uri_chars/byte
- haakon 12y ago
  Thanks, that's a nicely explained correction.
nly 12y ago
The HTTP standard actually allows 90 distinct octets in cookie values, but I suppose you're not going to quibble over <2% coding efficiency given Z85s other advantages. http://tools.ietf.org/html/rfc6265#section-4.1.1 http://tools.ietf.org/html/rfc6265#section-4.1.1

jfroma 12y ago

Yes, this is a real problem, tokens can get very large if you put too much information. HTTP does not define any limit for headers, but most of the Web Servers have a default limit, Apache 8kb, IIS 16kb, nginx 4kb (see this question on SO [1]). If your JWT exceeds these limits you will get a "413 Entity Too Large". It gets only worse if you need to use a query string instead of a header because the limits are lower and IE has a limit too [2]. Solution: carefully design your JWT, what information you will put on there. You usually don't need everything, store only the things you will use on every request, like the user id, name, email, roles are good candidates. Do not try to put the entire Facebook or Linkedin profile on a JWT. Beside the limits, it will make the request bigger to transport and maybe even slower to verify. [1]: http://stackoverflow.com/questions/686217/maximum-on-http-header-values http://stackoverflow.com/questions/686217/maximum-on-http-he... [2]: http://stackoverflow.com/questions/417142/what-is-the-maximum-length-of-a-url-in-different-browsers http://stackoverflow.com/questions/417142/what-is-the-maximu...