Assuring Client is Authorized to use JSON Web Token

Question

JSON Web Tokens ( JWT ) are server-signed objects that the issuing server uses to identify a user, track session data and authorize requests.

The fact that JWT are server-signed gives assurance that the token was produced by someone with access to the server's private or shared, symmetric key, but--what mechanism is in place to assure that the token is being sent to the server by an authorized user?

For example, let's say I have a server that issues a JWT out into the world. Regardless of whether or not I transmit that token over a secure connection, because data can be saved, decrypted and retransmitted by the client it seems safe to assume that once one client has a web token, everyone has that web token.

So, how am I to make sure on my server that tokens coming in over the wire actually are coming in from authorized parties?

Answer 1

In one sentence: you have to trust the client to use TLS and generally protect the token.

Like many token systems, JWT relies on the client to secure its token. Clients are already required to maintain credentials needed for authentication (eg: passwords) so this is not a radically different concept. Furthermore, JWTs typically have a much shorter expiration time than credentials so securing them is typically easier.

Below are some snippets from relevant specs.

The JWT RFC, which utilizes the JSON Web Signature RFC, requires the use of TLS:

To protect against information disclosure and tampering, confidentiality protection MUST be applied using TLS with a ciphersuite that provides confidentiality and integrity protection.

JWTs are similar to the OAuth 2.0 concept of bearer tokens. The bearer token RFC states:

Any party in possession of a bearer token (a "bearer") can use it to get access to the associated resources (without demonstrating possession of a cryptographic key). To prevent misuse, bearer tokens need to be protected from disclosure in storage and in transport.

In section 5.2 it goes on to say that TLS must be used to ensurer security of the token in transit, both when obtaining the token and when using it:

This requires that the communication interaction between the client and the authorization server, as well as the interaction between the client and the resource server, utilize confidentiality and integrity protection.

Answer 2

Ask the owner of the information if they authorize the request.

As Neil Smithline points out in his excellent answer to this question, the RFCs on JWT, OAuth, and many other token-based authentication systems rely on the end user maintaining the secrecy of their token.

For me personally, this is a hard pill to swallow: a lot of end users don't understand what a token is or even where it is, let alone why or how they should secure it.

While this may sound so fundamental it's belittling to point out: if an end user is aware someone is attempting to access their private information, or if an end user is aware that the privacy of their key has been compromised, one could argue they are significantly more likely to alert interested parties that something has gone wrong.

So, one might conclude the task at hand is to design a system whereby it is easy for end users to be aware of when their private information is being accessed, when their token is being used. While we can't design a system that doesn't rely on trust, we can design a system that ties protection of the key into interests that the user already has and knows how to manage.

In a hypothetical implementation of a system that uses web tokens, one might experiment with the following:

1. Run tests on the application's infrastructure that ensure it is using Perfect Forward Security.
2. Ask clients who access the application's infrastructure who they are.
3. Look up the identification provided by the client in an internal system that maps the identification to a cell phone--and contact that cell phone.
4. The message sent to the phone will provide as much information about the client as possible, and ask the person in control of the phone whether the client should be authorized to use the application infrastructure.
5. If the client is authorized by the person in control of the phone, issue a token to the client and keep a record of how the token is used. Furthermore, share pertinent parts of that log with the phone on record.
6. Expire the token after a short period of time; reject any further requests using that token.

While the steps above certainly aren't part of RFCs on JSON Web Tokens, OAuth or many other token-based authentication systems, it partially moves the issue of trust from a user who doesn't know how to keep a token secure to a group of engineers who ideally know how to implement two-factor authentication well.