21

One advantage of a JWT over a cookie seems to be that it bypasses the origin restrictions on cookies.

Can someone help me understand any other advantages and importantly any other disadvantages to JWTs?

Ben Aston
  • 53,718
  • 65
  • 205
  • 331

3 Answers3

11

a lot of web-related info can be found in a similar post here: Token Authentication vs. Cookies; I would like to call out some "architectural" differences:

  1. JWTs are a standardized container format to encode user and client related information in a secure way using "claims" (whereas cookie contents and signing/encryption are not standardized)
  2. JWTs are not restricted to present session-like information about the authenticated user itself; they can also be used to delegate access to clients that act on behalf of the user
  3. JWTs allow for a more granular access model than cookies because JWTs can be limited in "scope" (what they allow the client to do) as well as time
Community
  • 1
  • 1
Hans Z.
  • 50,496
  • 12
  • 102
  • 115
  • 1
    What about GET requests from new tabs? If you use JWT on a web app accessed via browser, it is safe to assume the user might want to open different tabs (and perhaps manually enter the desired URL). In this case, you don't have a way to read your stored JWT before making a request (and injecting it on a header, for example). Cookies don't have this problem since they are natively sent by the browser with new requests, even on new tabs. I have made a question about this issue: http://stackoverflow.com/questions/30061307/jwt-how-to-handle-get-requests-when-user-opens-a-new-tab – noderman May 05 '15 at 20:17
  • the premisse is that upon accessing a URL without presenting the correct JWT, the browser would be redirected to a specific endpoint (Authorization Server) where it can get the JWT – Hans Z. May 05 '15 at 21:08
  • [Does the generation of a new JWT invalidates the JWT that exists on the original tab? If so, you can't do this without disrupting the operation of the original tab] So the cycle seems to be: you are already authenticated, the new tab causes a redirection, where I suppose your app has a local JS code just to get your $window.localStorage.token (sessionStorage doesn't work between tabs) -- this is necessary: you want to avoid a new login by the user and possibly avoid JWT destruction -- and then redirect back to the desired resource with JWT injected. – noderman May 05 '15 at 22:33
  • 1
    Re: the use of a cookie, there is an interesting article here at stormpath https://stormpath.com/blog/where-to-store-your-jwts-cookies-vs-html5-web-storage/ where the JWT is transported on the cookie. This is good because the server can still use the cookie's JWT to authenticate without needing to check databases, which is one of the main reasons for using JWT. – noderman May 05 '15 at 22:36
  • 1
    @noderman I would handle this in the client side, personally. Any GET request would actually retrieve my web application - likely an SPA - and then that SPA would make any necessary AJAX requests using the token stored in localStorage. While the issue you raise is legitimate, I think it's very easy to work around. –  Jul 26 '15 at 05:08
  • 1
    @nodeman I am not sure if using cookie to store token is such a good idea. Why not to simply use cookie in a traditional way. Whole idea of JWT is to is to provide more secure way. If you store them in the cookie you are vournelabre to CSRF because your credentials will be sent automatically with any request. Take a look at github conversation [dwyl/learn-json-web-tokens](https://github.com/dwyl/learn-json-web-tokens/issues/63). User **joepie91** points out some serious security issues related to that approach. – FullStackForger Aug 09 '16 at 15:09
4

Advantages

  1. JWT is a stateless authentication mechanism as the user state is never saved in the database. As JWTs are self-contained, all the necessary information is there, reducing the need of going back and forward to the database. With JWT we don't need to query database to authenticate the user for every api call.
  2. Protects against CSRF (Cross Site Request Forgery) attacks.
  3. JWT is compact. Because of its size, it can be sent through an URL, POST parameter, or inside an HTTP header.
  4. You can authorize only the requests you wish to authorize. Cookies are sent for every single request.
  5. You can send JWT to any domain. This is especially useful for single page applications that are consuming multiple services that are requiring authorization - so I can have a web app on the domain myapp.com that can make authorized client-side requests to myservice1.com and to myservice2.com. Cookies are bound to a single domain. A cookie created on the domain foo.com can't be read by the domain bar.com.

Disadvantages

  1. Not easy to revoke a JWT as it is a stateless authentication mechanism. It makes difficult to implement feature like Sign out from all devices. This is easy to implement using session based authentication as we just need to delete the session from database.
  2. Need to write some code to implement whereas cookies work out of the box.
PR7
  • 1,524
  • 1
  • 13
  • 24
0

As far as I use it, a JWT is just a token used to represent data that cannot be counterfeit by the client. You can pass it to the server through a http header or through a cookie. You just need to implement on your server side both ways to access the JWT before processing it. The cookie is practical for web browser but using a header is easier for plain http request like when using curl or native apps. JWT is protocol agnostic you can also use it in a web socket, put it in a json payload or anywhere else as long as it can be accessed and decoded on the receiving side.

Nicolas Manzini
  • 8,379
  • 6
  • 63
  • 81