After reading this article on Session, Cookie, and Token, you will have no problem arguing with the interviewer

This article is organized as follows:

Cookies and Sessions

The HTTP protocol is a stateless protocol, that is, each time the server receives a request from the client, it is a new request, and the server does not know the client's historical request records; the main purpose of Session and Cookie is to make up for the stateless nature of HTTP.

What is a Session?

When the client requests the server, the server will open a memory space for this request. This object is the Session object, and the storage structure is ConcurrentHashMap. Session makes up for the stateless feature of HTTP. The server can use Session to store some operation records of the client during the same session.

How to determine whether it is the same session

When the server receives the request for the first time, it opens up a session space (creates a session object), generates a sessionId, and sends a response to the client requesting the setting of cookies through the Set-Cookie: JSESSIONID=XXXXXXX command in the response header; after the client receives the response, it sets a cookie information of JSESSIONID=XXXXXXX on the local client, and the expiration time of the cookie is the end of the browser session.

Each time the client sends a request to the same website, the request header will carry the cookie information (including sessionId). Then, the server reads the cookie information in the request header, obtains the value named JSESSIONID, and obtains the sessionId of this request.

Disadvantages of Session

The session mechanism has a disadvantage. For example, if server A stores the session, even after load balancing, if the number of visits to A surges over a period of time, it will be forwarded to server B for access. However, server B does not store A's session, which will cause the session to become invalid.

What are Cookies

[[321208]]

Cookies in the HTTP protocol include Web Cookies and Browser Cookies, which are small pieces of data sent by the server to the Web browser. The browser will store the cookies sent by the server to the browser and send them to the server with the next request. Usually, it is used to determine whether two requests come from the same browser, such as to keep the user logged in.

The HTTP Cookie mechanism is a supplement and improvement to the stateless HTTP protocol.

Cookies are used for the following three purposes:

• Session management: login, shopping cart, game score, or anything else the server should remember
• Personalization: user preferences, themes, or other settings
• Tracking: Recording and analyzing user behavior

Cookies were once used for general client-side storage. While this was legal because they were the only way to store data on the client, it is now recommended to use modern storage APIs. Cookies are sent with every request, so they can slow down performance (especially over mobile data connections).

Creating Cookies

When receiving an HTTP request from a client, the server can send a Set-Cookie header with the response. Cookies are usually stored by the browser, which then sends the request to the server along with the HTTP header.

Set-Cookie and Cookie headers

The Set-Cookie HTTP response header sends cookies from the server to the user agent. Here is an example of sending a cookie:

This header tells the client to store the cookie

Now, with each new request to the server, the browser will send all previously stored cookies back to the server using the Cookie header.

There are two types of cookies, Session Cookies and Persistent Cookies. If a cookie does not contain an expiration date, it is considered a session cookie. Session cookies are stored in memory and are never written to disk. When the browser is closed, the cookie is permanently lost. If a cookie contains an expiration date, it is considered a persistent cookie. On the date specified by the expiration date, the cookie is deleted from disk.

There is also the Secure and HttpOnly tags of Cookie, which are introduced below.

Session Cookies

The above example creates a session cookie. A characteristic of a session cookie is that it is deleted when the client is closed because it does not specify an Expires or Max-Age directive.

However, your web browser may use session restore, which makes most session cookies permanent, as if you had never closed the browser.

Persistent Cookies

Persistent cookies do not expire when the client is closed, but expire at a specific date (Expires) or a specific length of time (Max-Age). For example:

 Set-Cookie: id = a3fWa ; Expires = Wed , 21 Oct 2015 07:28:00 GMT;

Cookie Secure and HttpOnly Flags

Secure cookies need to be sent to the server in an encrypted manner via the HTTPS protocol. Even if secure, sensitive information should not be stored in cookies because they are inherently insecure and this flag does not provide real protection.

The role of HttpOnly:

• The lack of the HttpOnly attribute in the session cookie can cause attackers to obtain the user's cookie information through programs (JS scripts, Applets, etc.), causing the user's cookie information to be leaked and increasing the attacker's cross-site scripting attack threat.
• HttpOnly is an extension of Cookie made by Microsoft. This value specifies whether Cookie can be accessed through client script.
• If the HttpOnly attribute is not set to true in a cookie, the cookie may be stolen. The stolen cookie can contain sensitive information that identifies the site user, such as ASP.NET session ID or Forms authentication ticket. An attacker can replay the stolen cookie to impersonate the user or obtain sensitive information, conduct cross-site scripting attacks, etc.

Scope of Cookies

The Domain and Path tags define the scope of the cookie: that is, which URLs the cookie should be sent to.

The Domain tag specifies which hosts can accept cookies. If not specified, the default is the current host (excluding subdomains). If the Domain is specified, it generally includes subdomains.

For example, if you set Domain=mozilla.org, the cookie is also included in the subdomain (such as developer.mozilla.org).

For example, if you set Path=/docs, the following addresses will match:

• /docs
• /docs/Web/
• /docs/Web/HTTP

Comparison between JSON Web Token and Session Cookies

JSON Web Token, referred to as JWT, and Session can both provide user authentication for websites, but they are not the same thing.

Below is a study of the differences between JWT and Session.

Similarities between JWT and Session Cookies

Before discussing JWT and Session Cookies, it is necessary to understand their similarities.

They can be used both to authenticate users as they click through to different pages and once they have logged into a website or application.

Without these two, you may need to log in every time you switch pages. Because HTTP is a stateless protocol. This means that when you visit a web page and then click on another page on the same site, the server's memory will not remember your previous operations.

Therefore, if you are logged in and visit another page that you have access to, you will be logged in again because HTTP does not record that you just logged in.

JWT and Session Cookies are mechanisms used to handle switching between different pages and save user login information.

That is, both technologies are used to save your login status and allow you to browse any password-protected website. This problem is solved by authenticating the user data every time a new request is made.

So what are the similarities between JWT and Session Cookies? They are a mechanism that allows you to record and verify your login status between different requests.

What are Session Cookies

Session Cookies are also called session cookies. In Session Cookies, the user's login status is saved in the server's memory. When a user logs in, a Session is securely created by the server.

At each request, the server reads the SessionId from the session cookie. If the data on the server is the same as the read SessionId, the server sends a response to the browser, allowing the user to log in.

What are Json Web Tokens?

JWT is the abbreviation of Json Web Token, which can be often called Json token. It is a form of secure transmission of information as a Json object defined in RFC 7519. The information stored in JWT is digitally signed, so it can be trusted and understood. JWT can be signed using the HMAC algorithm or using public/private keys of RSA/ECDSA.

JWT is mainly used for the following two purposes:

• Authentication: This is the most common use case for JWT. Once a user logs in, each subsequent request will include the JWT, allowing the user to access the routes, services, and resources allowed by the token. Single sign-on is a feature that widely uses JWT today because it has little overhead.
• Information Exchange: JWT is a way to securely transmit information. JWT is signed and authenticated using a public/private key. In addition, since the signature is calculated using the header and payload, you can also verify whether the content has been tampered with.

JWT Format

Next, we will explore what the composition and format of JWT is.

JWT mainly consists of three parts, each of which is separated by .. The parts are:

• Header
• Payload
• Signature

Therefore, a very simple JWT composition would look like this:

Then we discuss the different parts separately.

(1) Header

Header is the header of the JWT, which usually consists of two parts: the type of token (ie JWT) and the signature algorithm used, such as HMAC SHA256 or RSA.

For example:

 {
 "alg": "HS256",
 "typ": "JWT"
 }

After specifying the type and signature algorithm, the Json block is Base64Url encoded to form the first part of the JWT.

(2) Payload

The second part of the token is the Payload, which contains a claim. A claim is a statement about an entity (usually a user) and other data. There are three types of claims: registered, public, and private claims.

Registered declarations: Contains a set of predefined declarations that are recommended for use, mainly including:

• Public statement: A public statement can add any information. Generally, it adds user-related information or other necessary information required by other businesses. However, it is not recommended to add sensitive information because this part can be decrypted on the client.
• private declarations: Custom declarations intended for sharing information between parties who agree to use them, which are neither registered nor public.

For example:

 {
 "sub": "1234567890",
 "name": "John Doe",
 "admin": true
 }

The payload Json block is then Base64Url encoded to form the second part of the JWT.

(3) signature

The third part of JWT is a visa information, which consists of three parts:

• header (base64)
• Payload (base64)
• secret

For example, we need the HMAC SHA256 algorithm for signing:

 HMACSHA256
  base64UrlEncode(header) + "." +
 base64UrlEncode(payload),
 secret)

The signature is used to verify that the message has not been altered in the process, and for tokens signed with a private key, it can also verify the true identity of the sender of the JWT.

Putting it together

Now we combine the three dot-delimited Base64-URL string parts above into a string that can be easily passed around in HTML and HTTP environments.

Below is a complete JWT example that encodes the header and payload and then signs them using signature.

 eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6I kpvaG4gRG9lIiwiYWRtaW4iOnRydWV9.TJVA95OrM7E2cBab30RMHrHDcEfxjoYZgeFONFh7HgQ

If you want to test and write it yourself, you can visit the JWT official website https://jwt.io/#debugger-io

Differences between JWT and Session Cookies

Both JWT and Session Cookies provide secure user authentication, but they differ in the following ways:

(1) Cryptographic signature

JWTs have cryptographic signatures, whereas Session Cookies do not.

(2) JSON is stateless

JWT is stateless because the claims are stored on the client, not in server memory.

Authentication can happen locally, rather than the request having to go through a server database or similar. This means that a user can be authenticated multiple times without having to communicate with the site or application's database and consuming a lot of resources in the process.

(3) Scalability

Session Cookies are stored in the server memory, which means that if the website or application is large, it will consume a lot of resources. Since JWT is stateless, in many cases, they can save server resources. Therefore, JWT is more scalable than Session Cookies.

JWT supports cross-domain authentication

Session cookies are only valid within a single node's domain or its subdomains. If they are tried to be accessed through a third node, they will be blocked. This is a problem if you want your website to establish a secure connection with other sites.

Using JWT can solve this problem. Using JWT can perform user authentication through multiple nodes, which is what we often call cross-domain authentication.

Selection of JWT and Session Cookies

We have discussed the differences between JWT and Cookies above. I believe you will have a deeper understanding of the selection. Generally speaking,

For small to medium-sized websites that only need to log in users and access some information stored in the site's database, Session Cookies are usually sufficient.

If you have an enterprise-level site, application, or something close to it, and need to handle a large number of requests, especially from third parties or many third parties (including APIs located on different domains), JWT is obviously a better fit.

postscript

I was asked this question during an interview two days ago, so I wrote an article to summarize it. I was also asked another interview question, how to use Session when disabling Cookies? I searched on Baidu and found that this is a PHP interview question, em...

But I still chose to learn how to disable Cookies and use Session

• If Cookies are disabled, the server will still send the sessionId to the browser in the form of a cookie, but the browser will no longer save this cookie (ie, sessionId)
• If you want to continue using session, you need to use URL rewriting to achieve it.