JWT vs cookies for token-based authentication

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

1. 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)

2. 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

Solution 1:

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.

Solution 2:

Overview

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.

Cookie

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

Bearer Token

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

JWT and Token Based Authentication

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.