ASP.NET Identity Bearer Token vs JWT Pros and Cons

Question

I have used ASP.NET Identity for a while now and have been looking at JWT (JSON Web Token) as they seem really interesting and easy to use.

JWT.IO has a great example/to

Answer 1

The accepted answer is incorrect.

The question discusses bearer tokens and JWT tokens as two alternatives, while they in fact each describe a different aspect in the token, and many modern large-scale systems today use JWT bearer tokens.

Bearer tokens, as their name suggests, are tokens that anyone who has access to them (The "bearer") may use to access a certain restricted resource.

Compare with bearer bonds. (Securities which are not registered under a specific owner, but rather belong to whomever currently holds them, and may be physically stolen or even physically destroyed)

Cons

• A major con is that it may be reused in a replay attack by anyone who gains access to it.

One way to prevent that is to create tokens with access only to the minimally required resources. And set a relatively-near expiration time (This is usually achieved using the "exp" claim, as defined in the IANA JWT spec)

Pros

• They allow stateless authenticators (You don't have to make sure each call from the same client arrives to the same server instance), which has vast impacts on the service's architecture and prevents scaling limitations from the authentication process. (e.g. Assigning a static server instance to handle each client)

JWT Tokens (Standing for JSON Web Token) only describe the format in which the token is encoded. (i.e. A Json, using URL-safe encoding such as Base64URL)

They say nothing about how or by who they may be used. For example, a server may decide to only accept them after employing some additional proof of identity mechanism. (Meaning that a bearer of these tokens doesn't necessarily gain any new privileges from them)

Furthermore, unlike the accepted answer claims, JWT tokens may be opaque to the client (Using some sort of encryption) in order to prevent exposure of the inner working of the contacted server by the client. This idea is discussed in RFC 7516.

Pros

• JSONs are human-readable.

• The Base64URL encoding makes it easier to debug, and used even within URLs.

• Json parsing is easy, commonplace, and supported by virtually all programming languages. (Making inter-operability between systems written separately and based on different stacks significantly easier)

Cons

• Textual encoding results in relatively longer tokens than minimally required.