Reputation: 10534
I read some posts about "JWT vs Cookie" but they only made me more confused...
I want some clarification, when people talking about "token-based authentication vs cookies", cookies here merely refer to session cookies? My understanding is that cookie is like a medium, it can be used to implement a token-based authentication(store something that can identify logged-in user on the client side) or a session-based authentication(store a constant on the client side that matches session information on the server side)
Why do we need JSON web token? I was using the standard cookie to implement token-based authentication(not using session id, not use server memory or file storage): Set-Cookie: user=innocent; preferred-color=azure
, and the only difference that I observed is that JWT contains both payload and signature...whereas you can choose between signed or plaintext cookie for http header. In my opinion signed cookie (cookie:'time=s%3A1464743488946.WvSJxbCspOG3aiGi4zCMMR9yBdvS%2B6Ob2f3OG6%2FYCJM'
) is more space efficient, the only drawback is that client cannot read the token, only the server can...but I think it's fine because just like claim in JWT is optional, it's not necessary for token to be meaningful
Upvotes: 260
Views: 149250
Reputation: 766
Reposted from my Blog Post - Need for JSON Web Token
Upvotes: 31
Reputation: 6137
JSON is the best (and only needed IMHO) data format in which you can put anything you want.
With JWT you are not limited by the size of your data, with cookies you only have 4093 bytes per domain - for all cookies, not the one.
Despite the above, I would implement JWT authentication using cookies. I.e. generate JWT access token and store it in a cookie.
Upvotes: 1
Reputation: 141682
What you're asking for is the difference between cookies and bearer tokens for sending JSON Web Tokens (JWTs) from the client to the server.
Both cookies and bearer tokens send data.
One difference is that cookies are for sending and storing arbitrary data, whereas bearer tokens are specifically for sending authorization data.
That data is often encoded as a JWT.
A cookie is a name-value pair, that is stored in a web browser, and that has an expiry date and associated domain.
We store cookies in a web browser either with JavaScript or with an HTTP Response header.
document.cookie = 'my_cookie_name=my_cookie_value' // JavaScript
Set-Cookie: my_cookie_name=my_cookie_value // HTTP Response Header
The web browser automatically sends cookies with every request to the cookie's domain.
GET http://www.bigfont.ca
Cookie: my_cookie_name=my_cookie_value // HTTP Request Header
A bearer token is a value that goes into the Authorization
header of any HTTP Request. It is not automatically stored anywhere, it has no expiry date, and no associated domain. It's just a value. We manually store that value in our clients and manually add that value to the HTTP Authorization header.
GET http://www.bigfont.ca
Authorization: Bearer my_bearer_token_value // HTTP Request Header
When we do token-based authentication, such as OpenID, OAuth, or OpenID Connect, we receive an access_token (and sometimes id_token) from a trusted authority. Usually we want to store it and send it along with HTTP Requests for protected resources. How do we do that?
Option 1 is to store the token(s) in a cookie. This handles storage and also automatically sends the token(s) to the server in the Cookie
header of each request. The server then parses the cookie, checks the token(s), and responds accordingly.
Option 2 is to store the token in local/session storage, and then manually set the Authorization
header of each request. In this case, the server reads the header and proceeds just like with a cookie.
It's worth reading the linked RFCs to learn more.
Upvotes: 207
Reputation: 1142
While cookies can increase the risk of CSRF attacks by virtue of them being sent automatically along with requests, they can decrease the risk of XSS attacks when the HttpOnly
flag is set, because any script that is injected into the page won't be able to read the cookie.
CSRF: a user clicks on a link (or views images) on an attacker's site, which causes the browser to send a request to the victim's site. If the victim uses cookies, the browser will automatically include the cookie in the request, and if the GET request can cause any non-read-only actions, the victim site is vulnerable to the attack.
XSS: an attacker embeds a script in the victim site (the victim site is only vulnerable if inputs are not sanitized correctly), and the attacker's script can do anything JavaScript is allowed to do on the page. If you store JWT tokens in local storage, the attacker's script could read those tokens, and also send those tokens to a server they control. If you use cookies with the HttpOnly
flag, the attacker's script won't be able to read your cookie to begin with. That said, the script they successfully injected will still be able to do anything JavaScript can do, so you're still hosed IMO (i.e., while they may not be able to read the cookie to send it off to their own server for use later, they can send requests to the victim site using XHR, which will include the cookie anyway).
Upvotes: 41
Reputation: 6054
In addition to what MvdD has said about cookies being automatically sent:
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.
Upvotes: 45
Reputation: 23494
The biggest difference between bearer tokens and cookies is that the browser will automatically send cookies, where bearer tokens need to be added explicitly to the HTTP request.
This feature makes cookies a good way to secure websites, where a user logs in and navigates between pages using links.
The browser automatically sending cookies also has a big downside, which is CSRF attacks. In a CSRF attack, a malicious website takes advantage of the fact that your browser will automatically attach authentication cookies to requests to that domain and tricks your browser into executing a request.
Suppose the web site at https://www.example.com allows authenticated users to change their passwords by POST
-ing the new password to https://www.example.com/changepassword without requiring the username or old password to be posted.
If you are still logged in to that website when you visit a malicious website which loads a page in your browser that triggers a POST to that address, your browser will faithfully attach the authentication cookies, allowing the attacker to change your password.
Cookies can also be used to protect web services, but nowadays bearer tokens are used most often. If you use cookies to protect your web service, that service needs to live on the domain for which the authentication cookies are set, as the same-origin policy won't send cookies to another domain.
Also, cookies make it more difficult for non-browser based applications (like mobile to tablet apps) to consume your API.
Upvotes: 308