Cookies vs Headers vs URL Parameter

URL Parameters

First of all, we never recommend placing a token in the URL. URLs are bookmarked, shared with friends, posted online, etc. It is too easy for a user to copy a URL of a page they like and forward to a friend.

So this narrows us down to only Cookies vs HTTP Headers. If you are focused on creating RESTful APIs, really the Cookie is just another header just like the Authorization Header. You could in fact take the same JWT that would be sent via an Authorization Header and wrap it in a cookie.

The proxy will extract the Cookie and add the appropriate headers when relaying the request. The real reasons come in the next section:

The two choices that most people think of is Cookies and HTML5 Local Storage. So sometimes when people refer to Cookie vs HTTP Header, they are actually asking “Cookie vs. Local Storage?” There are benefits and security risks for each.

Cookies and local storage serve different purposes. Cookies are primarily for reading server-side, local storage can only be read by the client-side. So the question is, in your app, who needs this data — the client or the server?

If it's your client (your JavaScript), then by all means switch. You're wasting bandwidth by sending all the data in each HTTP header.

If it's your server, local storage isn't so useful because you'd have to forward the data along somehow (with Ajax or hidden form fields or something). This might be okay if the server only needs a small subset of the total data for each request.

Local Storage : It stores data with no expiration date, and gets cleared only through JavaScript, or clearing the Browser Cache / Locally Stored Data — unlike cookie expiry.