What is JWT?

This post explains what JWT is, without getting into technical details you don’t need to know. Intention of the post is to dispel some harmful misconceptions.

In short, JWT is just a piece of data signed by someone. It doesn’t do much as-is but it’s a key building block useful in many applications.

What JWT Looks Like

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiYWRtaW4iOnRydWV9.TJVA95OrM7E2cBab30RMHrHDcEfxjoYZgeFONFh7HgQ

If you look carefully, it’s basically three gibberish text separated by a period. Th role each part plays are:

Header.Payload.Signature

They look gibberish because they are encoded. Important part is the payload. Rest is there to describe (header) and protect (signature) the payload.

What Each Part Does

Header primarily describes (using JSON) how the Payload was signed so the Signature can be verified.

{
 "alg": "HS256",
 "typ": "JWT"
}

Payload is a collection of name-value pairs presented as JSON like this:

{
  "sub": "1234567890",
  "name": "John Doe",
  "admin": true
}

Signature protects both the Header and the Payload so that neither can be changed without detection.

Key Points About JWT

  • JWT doesn’t say anything meaningful about its sender, recipient nor signer as-is.
  • JWT is not encrypted as-is.

This is not to say JWT can’t but they have to be added. Allow me to go into a bit more detail on each points.

JWT doesn’t say anything meaningful about its sender, recipient nor signer as-is.

JWT typically includes some info on its signer so the signature can be verified but that only proves it was signed by someone who can prove they signed it. Unless the signer is known that is. How one know calls for relationship and/or infrastructure.

Same goes for sender and recipient. To verify sender or recipient, more has to be built-on top of JWT.

JWT is not encrypted as-is.

JWT is typically sent unencrypted over a secure channel of communication to a recipient but it may even be printed plainly using QR-code in newspapers. If you need to protect the token, encrypt it whole in  way that only the recipient can decrypt it. If only part of the payload needs to be protected, then encrypt just the value.


Follow up series of posts will discuss how to build with JWT to solve some common problems like protecting APIs or delegated authorization in a mobile app without issues OAuth has. Stay tuned.

Why wasn’t OAuth Vulnerability found earlier?

According to OAuth about page, it was Blaine Cook who initiated the birth of the the standard while working at Twitter in Nov. 2006. Blaine mobilized the initiative by getting Chris Messina involved which attracted others at CitizenSpace to join the effort (an excellent demonstration of benefits co-working social environments offer). By April 2007, the initiative got to formalize and, by October 2007, OAuth Core 1.0 spec was finalized. The question of interest to me is, why did it take a year and a half to uncover the first vulnerability?

It’s puzzling because OAuth was well known and popularized, attracted a large body of developers, many of whom I presume read the spec, and implemented by many, some very large companies. I’ve read the spec as well and discussed it with peers and partners in the security and payment industry on several occasions.

I think the right answer might be that our collective perspective in dealing with the standard was focused on implementation, application, and hype while wrongly assuming that the standard was secure. Recollecting my thoughts when I was reading the spec for the first time, I now realize that it was the safety in numbers and the lure of promising applications that influenced me to focus only on implementation.

The good news is that I think OAuth will be given the proper shake it needs to get any remaining kinks out. The bad news is that we are likely to repeat the mistake when the next popular grassroots standard emerges in a hurry. Relatively fast pace of community/grassroots standard initiatives is not a concern only if mass appeal can be effectively leveraged to shine intensive searchlight on all aspect of the standard.

On Twitter’s OAuth Fix

While the OAuth team is working on addressing the OAuth session fixation vulnerability at the spec level, Twitter made following changes to reduce the exposure window:

  • Shorter Request Token timeout – This is good practice in general. Developers tend to be too generous and, all too often, forget to enforce or verify enforcement.
  • Ignore oauth_callback, in favor of URL set at regration time – this prevents hackers from intercepting callback.

Double-callback is still possible though which means Twitter OAuth Consumers will have to detect extraneous callbacks and invalidate access to everyone involved because they have no way of telling who is who.

Remaining exposure to the vulnerability is when hacker’s simulated callback arrives before the user. We are talking temporal exposure of a couple of seconds at most which, given current Twitter use-cases, is not that big a deal. I wouldn’t do banking over Twitter though. 😉

Facebook Disconnect

Launch of Facebook Connect is a perfect example of how amazingly forgetful tech media can be. Despite regular appearance of phishing related news, there is no alarm being raised about glaring phishing vulnerability in Facebook Connect, just the usual armchair-general’s strategy bravos and hypes.

First, there is zero phishing protection in Facebook Connect as it is implemented now. What they need, at the very least, is something like Bank of America’s SiteKey.

Second, overall security of Facebook Connect sites depend on each and every one of them being secure. Is TechCrunch secure? Maybe. What about others? Is perpetual security audit a requirement for Facebook Connect?

Third, I don’t buy “there is nothing to phish for in Facebook” argument. Not until Facebook makes it clear to all Facebook users, developers, and partner sites aware of the dangers.

Disclaimer: I worked on the technology behind SiteKey while at PassMark which was acquired later by RSA/EMC and rebranded as Adaptive Authentication (AA). The core of the team that built SiteKey/AA now works at SafePage, company I co-founded a year ago.