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

JWTs are like a ticket to an attraction. It contains all the security information a server needs embedded in it. Once the server has handed it out the client just needs to present it whenever it asks for something and the server responds accordingly if it's valid.

The contents are entirely viewable, but they're signed using a secret key by the server so it can tell if they've been tampered with.

Since everything is in the JWT, and the client can present it to whomever they want, you can use it for Single Sign On as long as the different servers share the same secret so they can verify the signature.

Like a ticket, a JWT has an expiry date. As long as it hasn't expired, it's valid. This means you can't revoke them before that. For this reason JWTs often have short expiry times (30 mins or so) and the client is also issued a refresh token in order to renew the JWT quickly when it expires.

JWTs

• Not stored on the server
• Great for SSO
• Can't be revoked prematurely

Bearer tokens are like a guest list. The server puts the client on the guest list, then provides a pass code to identify it when it wants something. When the client provides the code, the server looks it up on the list and checks that it's allowed to do whatever it's asking.

The server has to have the list available to it so if you want to share access across servers, they either all need to be able to access the list (database), or talk to some authority that has it (auth server).

On the other hand, since they have the guest list, they can take you off it whenever they want.

Bearer Tokens

• Stored on the server
• Can be revoked at any time
• Requires a central authority or shared database to share the token across servers

Bit of Tech has some excellent tutorials on implementing JWTs with Web Api if you want to go down that route.

http://bitoftech.net/2015/02/16/implement-oauth-json-web-tokens-authentication-in-asp-net-web-api-and-identity-2/

Answer 2

Unfortunately The previous answer could be misleading: Bearer Tokens are the predominant type of access token used with OAuth 2.0. A Bearer Token is an opaque string, not intended to have any meaning to clients using it. Some servers will issue tokens that are a short string of hexadecimal characters, while others may use structured tokens such as JSON Web Tokens. (https://oauth.net/2/bearer-tokens/)

Answer 3

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.