Understanding cookie, session, token, JWT


History of development

  • 1. A long time ago,WebBasically, it’s just browsing documents. Since it’s browsing, as a server, it doesn’t need to record who browsed what documents in a certain period of time. Each request is a new oneHTTPProtocol is request plus response, especially I don’t have to remember who just sent itHTTPRequests, every request is new to me.
  • 2. But with interactionWebThe rise of applications, such as online shopping sites, websites that need to be logged in, and so on, will immediately face a problem, that is, to manage conversations, we must remember who logged in to the system and who put goods in their shopping cart, That is to say, I have to distinguish everyone, which is a big challenge. Because HTTP requests are stateless, the solution is to send a session ID to everyonesession idTo put it bluntly, it is a random string, which everyone receives differently. Every time you send an HTTP request to me, you can send this string along with it, so that I can distinguish who is who
  • 3. In this way, everyone is very hi PI, but the server is not hi PI, everyone only needs to save their ownsession idAnd the server keeps everyone’ssession id! If there are more servers to access, there will be thousands, even hundreds of thousands.

    This is a huge cost to the server, which seriously limits the server’s expansion ability. For example, I use two machines to form a cluster, and small f logs in to the system through machine asession idIt will be saved on machine A. what if the next request of small f is forwarded to machine B? Machine B doesn’t have a small Fsession idAh. Sometimes a little trick is used:session stickyThat is, let small F’s requests stick to machine a all the time, but it doesn’t work. If machine a fails, it has to be transferred to machine B. That’s what we have to dosessionIt’s a copy of itsession idI’m tired of moving between two machines.

Understanding cookie, session, token, JWT

Then there was a man namedMemcachedI’ve got a movesession idIt is centrally stored in one place, and all machines come to access the data of this place. In this way, there is no need to copy, but it increases the possibility of single point failure. If the machine responsible for the session is hung up, everyone will have to log in again, and it is estimated that they will be scolded to death.

Understanding cookie, session, token, JWT

I also try to cluster the single point machine to increase the reliability. However, this small session is a heavy burden for me

  • 4. So some people have been thinking, why do I want to keep this hatefulsessionHow about just letting each client save it?

But if you don’t save themsession id, how to verify what the client sent mesession idDid I make it? **If we don’t verify, we don’t know whether they are legitimate users, and those who are malicious can forgesession idYou can do whatever you want.

Well, by the way, the key point is verification!

For example, f has already logged into the system, and I send him a tokentokenThat contains little Fuser idThe next time small f passes againHttpWhen you ask to visit me, put thistokenadoptHttp headerJust bring it here. *

But it’s notsession idThere is no essential difference. Anyone can forge, so I have to find a way to prevent others from forging.

Then make a signature on the data, for example, I useHMAC-SHA256Algorithm, plus a key that only I know, makes a signature on the data, and takes the signature and the data together astokenBecause the key is unknown to others, it cannot be forgedtokenYes.

Understanding cookie, session, token, JWT

thistokenI don’t save it when little f takes thistokenWhen you send it to me, I’ll use the same oneHMAC-SHA256The algorithm and the same key are used to calculate the signature of the data again, andtokenIf it is the same, I will know that xiaof has already logged in and can get the small F’s directlyuser idIf it is different, the data part must have been tampered with. I will tell the sender: sorry, there is no authentication.

Understanding cookie, session, token, JWT

TokenThe data in is stored in clear text (although I can use itBase64It can be seen by others, so I can’t store sensitive information like password in it.

Of course, if it’s for one persontokenIf someone steals it, I can’t help it. I also think that the thief is a legal user, which is actually with a personsession idIt’s the same to be stolen.

In this way, I won’t keep itsession idYes, I just generate the token, and then verify the token. I use my CPU to calculate time to obtain my session storage space!

It’s releasedsession idThis burden can be said to be light with nothing. My machine cluster can now easily expand horizontally and increase the number of users visiting. It is OK to add machines directly. This kind of stateless feeling is really good!


  • cookieIs a very specific thing, refers to the browser can permanently store a kind of data, is only a browser to achieve a data storage function.
  • cookieGenerated by the server, sent to the browser, the browsercookieSave in kV form to a text file in a directory. The next time you request the same website, thecookieSend to the server. becausecookieIt exists on the client side, so the browser adds some restrictions to ensure thatcookieIt will not be used maliciously, and will not occupy too much disk spacecookieThe quantity is limited.


  • sessionLiterally speaking, it’s conversation. This is similar to talking to someone. How do you know that you are talking to Zhang San instead of Li Si? The other party must have some characteristics (appearance, etc.) indicating that he is Zhang San.
  • sessionSimilarly, the server should know who is sending the request to itself. In order to make this distinction, the server must assign a different “identity” to each client, and then each time the client sends a request to the server, it will carry the “identity”, and the server will know who the request comes from. As for how the client can save this “identity”, there are many ways. For the browser client, we all use it by defaultcookieThe way.
  • Server usagesessionThe user’s information is temporarily saved on the server, after the user leaves the websitesessionWill be destroyed. This kind of user information storage method is relativecookieIt’s safer, butsessionThere is a drawback: if the web server does load balancing, the next operation request will arrive at another serversessionIt will be lost.


  • Based onTokenAuthentication is everywhere. In most Internet companies that use web APIs,tokensIt is the best way to handle authentication in multi-user environment.
  • The following features will allow you to use theTokenAuthentication for
    1. Stateless, scalable
    2. Support for mobile devices
    3. Cross program call
    4. security
  • Those uses are based onTokenThe big guys of authentication
  • Most of the APIs and web applications you’ve seen use themtokens。 For example, Facebook, twitter, Google +, GitHub, etc.


Server based authentication

  • We all know thatHTTPThe protocol is stateless, which means that the program needs to verify every request to identify the client.
  • Before that, the application identified the request by the login information stored on the server. This way is generally through storageSessionTo complete.
  • With the rise of web, application and mobile terminal, this kind of verification method gradually exposed problems. Especially in terms of scalability.

Some problems exposed by server based authentication

  • SeesionEvery time an authenticated user initiates a request, the server needs to create a record to store the information. As more and more users make requests, the memory overhead will increase.
  • Scalability: use in server memorySeesionStorage of login information is accompanied by scalability issues.
  • CORS (cross domain resource sharing): cross domain resource sharing is a headache when we need to make data used across multiple mobile devices. When using Ajax to grab resources from another domain, it is possible to prohibit requests.
  • CSR f (Cross Site Request Forgery): when users visit the bank website, they are vulnerable to cross site request forgery attack and can be used to visit other websites.

Among these problems, extensible row is the most prominent. Therefore, it is necessary for us to seek a more effective method.

Token based verification principle

be based onTokenAuthentication for is stateless and we do not store user information on the server orSessionMedium.

This concept solves many problems when storing information on the server

NoSessionIt means that your program can add or drop machines as needed without worrying about whether users log in or not.

be based onTokenThe authentication process is as follows:

  1. The user sends the request through the user name and password.
  2. Program verification.
  3. The program returns a signedtokenTo the client.
  4. Client storagetokenAnd each time is used for each send request.
  5. Server verificationtokenAnd return the data.

Every request requirestokentokenIt should be sent in the header of HTTP to ensure that HTTP requests are stateless. We also set the server propertiesAccess-Control-Allow-Origin:*To enable the server to receive requests from all domains.

It should be noted that when the acao header indicates (designing) *, it is not allowed to use HTTP authentication for clientSSLCertificates andcookiesCertificate for

Realization idea:

Understanding cookie, session, token, JWT

  1. After the user logs in successfully, it will return to verifyTokenTo the client.
  2. After receiving the data, the client saves it in the client
  3. Each time the client accesses the API, it carriesTokenTo the server side.
  4. The server uses filter filter to verify. If the verification is successful, the request data will be returned; if the verification fails, the error code will be returned

When we authenticate the information in the program and obtaintokenAfter that, we can get through thisTokenDo a lot of things.

We can even create a permission basedtokenTo third-party applications that can access our data (only if we allow them totoken

Advantages of tokens

Stateless, scalable

  • Stored on the clientTokensIt is stateless and can be extended. Based on this stateless and non storageSessionLoad balancer can transfer user information from one service to another server.
  • If we save the authenticated user’s information inSessionThen each request requires the user to send authentication information to the authenticated server (calledSessionAffinity). When the number of users is large, it may cause some congestion.
  • But don’t worry. usetokensAfter that, these problems were solved becausetokensHold the user’s authentication information.


  • Send on requesttokenIt’s no longer sendingcookieCan preventCSRF(Cross Site Request Forgery). Even if used on the client sidecookiestoragetokencookieIt’s just a storage mechanism, not for authentication. Do not store information inSessionMiddle, let’s lose rightsessionOperation.
  • tokenAfter a period of time, users need to re verify. We don’t have to waittokenAutomatic failure,tokenThere is a retraction operation, through thetoken revocataionCan make a specifictokenOr a group with the same certificationtokenInvalid.


  • TokensAbility to create programs that share permissions with other programs. For example, be able to connect a casual social account with your own big size (Facebook or twitter). When we log in to twitter through the service (we will buffer the process), we are allowing buffer to post to our twitter stream.
  • usetokensYou can provide optional permissions to third-party applications. When users want another application to access their data, we can establish their own API to get the special permissiontokens

Multi platform and cross domain

Let’s talk about it in advanceCORS(cross domain resource sharing), when extending applications and services, various devices and applications need to be involved.

Having our API just serve data, we can also make the design choice to serve assets from a CDN. This eliminates the issues that CORS brings up after we set a quick header configuration for our application.

As long as the user has an authenticatedtokenData and resources can be requested on any domain.

Access-Control-Allow-Origin: *      
  • Create based on StandardstokenYou can set some options. Standard usage inJSON Web Tokensreflect.
  • The most recent program and documentation is supplyJSON Web TokensYes. It supports many languages. This means that you can actually switch your authentication mechanism in the future.

Transfer from: WeChat official account: brother road of migrant workers


What is it?

  • JSON web token (JWT) is an open standard (RFC 7519), which defines a compact, self-contained way to securely transfer information between parties as JSON objects. This information can be verified and trusted because it is digitally signed.
  • In short, JWT (JSON web token) is a solution to realize token technology

When to use

  • Authorization(authorization): This is the most common scenario for using JWT. Once the user logs in, each subsequent request will contain a JWT, allowing the user access to the routes, services, and resources allowed by the token. Single sign on is a feature of JWT, which is widely used now, because of its low cost and easy cross domain usage.
  • Information Exchange(information exchange): JSON web tokens are a great way to safely transfer information between parties. Because jwts can be signed, for example, with a public / private key pair, you can be sure that the sender is the person they say they are. In addition, since the signature is computed using the header and payload, you can also verify that the content has not been tampered with.

JSON web token structure


  • The JSON web token consists of three parts, which are connected by dots (.). The three parts are as follows:
    • Header
    • Payload
    • Signature
  • Typical JWT


The header typically consists of two parts: the type of token (“JWT”) and the algorithm name alg (such as HMAC sha256 or RSA, etc.).

Understanding cookie, session, token, JWT

Then, code the JSON with Base64 to get the first part of JWT


The second part of JWT is payload, which contains declarations (requirements). Declarations are statements about entities (usually users) and other data. There are three types of declarations: registered, public, and private.

  • Registered claims: there is a set of predefined declarations that are not mandatory but recommended. For example: ISS (issuer), exp (expiration time), subject (subject), aud (audience), etc.
  • Public claims: can be defined at will.
  • Private claims: used to share information between parties who agree to use them and are not registered or public statements.
    • URL address of ISS [issuer] publisher
    • Subject [subject] the JWT is aimed at users, which are used to process specific applications, and are not commonly used fields
    • URL address of AUD [audience] receiver
    • Exp [expiration] the JWT destruction time; UNIX timestamp
    • NBF [not before] the JWT cannot be used earlier than this time; UNIX timestamp
    • IAT [issued at] the release time of the JWT; UNIX timestamp
    • JTI [JWT ID] the unique ID number of the JWT

Understanding cookie, session, token, JWT

Code payload Base64 to get the second part of JWT

be careful: do not place sensitive information in the payload or header of JWT unless they are encrypted.


In order to get the signature part, you must have the encoded header, encoded payload, and a secret key. The signature algorithm is the one specified in the header, and then sign them.

For example:

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

The signature is used to verify whether the message has been changed in the process of delivery, and for the token signed with the private key, it can also verify whether the sender of JWT is the sender as it is called.

Understanding cookie, session, token, JWT

How does it work

  • During authentication, a JSON web token will be returned after the user successfully logs in with their credentials. Since then, the token is the user certificate, and you must be very careful to prevent security problems. Generally speaking, you should not save the token longer than you need it.
  • Whenever a user wants to access a protected route or resource, the user agent (usually the browser) should bring JWT. Typically, it is placed in the authorization header and bear schema is used.
  • The header should look like this:
    • Authorization: Bearer <token>
  • The protected route on the server will check whether the JWT in the authorization header is valid, and if so, the user can access the protected resource. If JWT contains enough of the required data, you can reduce the need for database queries for some operations, although this may not always be the case.
  • If the token is sent in the authorization header, CORS will not be a problem because it does not use cookies.
  • The following figure shows how to get JWT and use it to access APIs or resources:

Understanding cookie, session, token, JWT

  1. The application (or client) wants to authorize the server to request authorization. For example, if the authorization code process is used, it is / OAuth / authorize
  2. After the authorization is granted, the authorization server returns an access token to the application
  3. Application uses access token to access protected resources (e.g. API)

Token based authentication and server based authentication

Server based authentication

The traditional way is to store the authenticated user information on the server, such as session. The next time the user requests the session ID, the server checks whether the user has been authenticated.

There are some problems in this server based authentication method

  • Sessions: after each user authentication, the server needs to create a record to save the user information, which is usually in memory. As more and more users have passed the authentication, the server’s overhead here will increase.
  • Scalability: since the session is in memory, there are some scalability issues.
  • CORS: when we want to extend our applications so that our data can be used by multiple mobile devices, we have to consider cross resource sharing. When using Ajax calls to get resources from another domain name, we may encounter the problem of forbidding requests.
  • CSRF: users are vulnerable to CSRF attacks.

Differences between JWT and session

  • The same thing is that they all store user information; however, session is on the server side and JWT is on the client side.
  • The biggest problem of session mode to store user information is that it takes up a lot of server memory and increases the server overhead.
  • However, JWT distributes the user state to the client, which can significantly reduce the memory pressure of the server.
  • The state of session is stored on the server side, and the client only has session ID; the state of token is stored in the client.

Understanding cookie, session, token, JWT

How does token based authentication work

Token based authentication is stateless, and no user information is stored in the server or session.

The absence of session information means that applications can expand and add more machines as needed without worrying about where users log in.

Although this implementation may be different, the main process is as follows:

  1. User requests access with user name and password
  2. The server verifies user credentials
  3. The application provides a token to the client
  4. The client stores the token and carries it with it in every subsequent request
  5. The server checks the token and returns the data

be careful:

  1. Each request requires a token
  2. Token should be placed in the request header
  3. We also need to set up the server to accept requests from all domains using theAccess-Control-Allow-Origin: *

The difference between JWT and OAuth

  1. Oauth2 is an authorization framework and JWT is an authentication protocol
  2. No matter which way you use, remember to use HTTPS to ensure data security
  3. Oauth2 is used to log in with a third-party account (such as using Weibo, QQ, GitHub to log in to an app), andJWT is used for front and rear separationIt is used when the background API needs to be protected simply.

JWT advantages

  • Because of the versatility of JSON, JWT can support cross language, such as Java, JavaScript, nodejs, PHP and many other languages.
  • With the payload part, JWT can store some non sensitive information necessary for other business logic on its own.
  • It is easy to transfer. The composition of JWT is very simple and the byte occupation is very small, so it is very easy to transfer.
  • It does not need to save session information on the server side, so it is easy to extend the application

Use of JWT

Reference link: Blog: full use of JWT