JWT vs cookies for token-based authentication

Question

I read some posts about \"JWT vs Cookie\" but they only made me more confused...

1. I want some clarification, when people ta

Answer 1

In addition to what MvdD has said about cookies being automatically sent:

1. A cookie can be a medium, but its most significant function is how it interacts with the browser. Cookies are set by the server and sent in requests in very specific ways. JWT on the other hand is exclusively a medium, it is an assertion of some facts in a particular structure. If you were so inclined, you could put a JWT as your authentication cookie. When you read articles comparing them, they typically are talking about using a JWT sent as a bearer token by front end code vs an authentication cookie which corresponds to some cached session or user data on the back end.
2. JWT offers many features, and puts them in a standard so they can be used between parties. A JWT can act as a signed assertion of some facts in many different places. A cookie, no matter what data you put in it or if you sign it, only really makes sense to use between a browser and a specific back end. JWT can be used from browser to back end, between back ends controlled by different parties (OpenId Connect is an example), or within back end services of one party. Regarding your specific example of your signed cookies, you can probably achieve the same functions ("not using session id, not use server memory or file storage") as JWT in that use case, but you lose out on libraries and peer-review of the standard, in addition to the CSRF issues talked about in the other answer.

In summary: the posts you're reading are probably comparing JWT as a bearer token to authentication cookie for browser to server authentication purposes. But JWT can do much more, it brings in standardization and features for use outside the use case you're probably thinking of.