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 one
HTTPProtocol is request plus response, especially I don’t have to remember who just sent it
HTTPRequests, every request is new to me.
- 2. But with interaction
WebThe 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 everyone
session 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 own
session idAnd the server keeps everyone’s
session 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 a
session 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 F
session 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 do
sessionIt’s a copy of it
session idI’m tired of moving between two machines.
Then there was a man named
MemcachedI’ve got a move
session 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.
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 hateful
sessionHow about just letting each client save it?
But if you don’t save them
session id, how to verify what the client sent me
session idDid I make it? **If we don’t verify, we don’t know whether they are legitimate users, and those who are malicious can forge
session 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 token
tokenThat contains little F
user idThe next time small f passes again
HttpWhen you ask to visit me, put this
Http headerJust bring it here. *
But it’s not
session 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 use
HMAC-SHA256Algorithm, plus a key that only I know, makes a signature on the data, and takes the signature and the data together as
tokenBecause the key is unknown to others, it cannot be forged
tokenI don’t save it when little f takes this
tokenWhen you send it to me, I’ll use the same one
HMAC-SHA256The algorithm and the same key are used to calculate the signature of the data again, and
tokenIf it is the same, I will know that xiaof has already logged in and can get the small F’s directly
user idIf it is different, the data part must have been tampered with. I will tell the sender: sorry, there is no authentication.
TokenThe data in is stored in clear text (although I can use it
Base64It can be seen by others, so I can’t store sensitive information like password in it.
Of course, if it’s for one person
tokenIf someone steals it, I can’t help it. I also think that the thief is a legal user, which is actually with a person
session idIt’s the same to be stolen.
In this way, I won’t keep it
session idYes, I just generate the token, and then verify the token. I use my CPU to calculate time to obtain my session storage space!
session 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 browser
cookieSave in kV form to a text file in a directory. The next time you request the same website, the
cookieSend to the server. because
cookieIt exists on the client side, so the browser adds some restrictions to ensure that
cookieIt will not be used maliciously, and will not occupy too much disk space
cookieThe 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 default
- Server usage
sessionThe user’s information is temporarily saved on the server, after the user leaves the website
sessionWill be destroyed. This kind of user information storage method is relative
cookieIt’s safer, but
sessionThere is a drawback: if the web server does load balancing, the next operation request will arrive at another server
sessionIt will be lost.
- Based on
TokenAuthentication 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 the
- Stateless, scalable
- Support for mobile devices
- Cross program call
- Those uses are based on
TokenThe big guys of authentication
- Most of the APIs and web applications you’ve seen use them
tokens。 For example, Facebook, twitter, Google +, GitHub, etc.
Server based authentication
- We all know that
HTTPThe 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 storage
- 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 memory
SeesionStorage 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 on
TokenAuthentication for is stateless and we do not store user information on the server or
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 on
TokenThe authentication process is as follows:
- The user sends the request through the user name and password.
- Program verification.
- The program returns a signed
tokenTo the client.
- Client storage
tokenAnd each time is used for each send request.
- Server verification
tokenAnd return the data.
Every request requires
tokenIt should be sent in the header of HTTP to ensure that HTTP requests are stateless. We also set the server properties
Access-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 client
- After the user logs in successfully, it will return to verify
TokenTo the client.
- After receiving the data, the client saves it in the client
- Each time the client accesses the API, it carries
TokenTo the server side.
- 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 obtain
tokenAfter that, we can get through this
TokenDo a lot of things.
We can even create a permission based
tokenTo third-party applications that can access our data (only if we allow them to
Advantages of tokens
- Stored on the client
TokensIt is stateless and can be extended. Based on this stateless and non storage
SessionLoad balancer can transfer user information from one service to another server.
- If we save the authenticated user’s information in
SessionThen each request requires the user to send authentication information to the authenticated server (called
SessionAffinity). When the number of users is large, it may cause some congestion.
- But don’t worry. use
tokensAfter that, these problems were solved because
tokensHold the user’s authentication information.
- Send on request
tokenIt’s no longer sending
CSRF(Cross Site Request Forgery). Even if used on the client side
cookieIt’s just a storage mechanism, not for authentication. Do not store information in
SessionMiddle, let’s lose right
tokenAfter a period of time, users need to re verify. We don’t have to wait
tokenThere is a retraction operation, through the
token revocataionCan make a specific
tokenOr a group with the same certification
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.
tokensYou 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 permission
Multi platform and cross domain
Let’s talk about it in advance
CORS(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 authenticated
tokenData and resources can be requested on any domain.
- Create based on Standards
tokenYou can set some options. Standard usage in
JSON Web Tokensreflect.
- The most recent program and documentation is supply
JSON 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:
- 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.).
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
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.
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.
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.
- The following figure shows how to get JWT and use it to access APIs or resources:
- 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
- After the authorization is granted, the authorization server returns an access token to the application
- 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.
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:
- User requests access with user name and password
- The server verifies user credentials
- The application provides a token to the client
- The client stores the token and carries it with it in every subsequent request
- The server checks the token and returns the data
- Each request requires a token
- Token should be placed in the request header
- We also need to set up the server to accept requests from all domains using the
The difference between JWT and OAuth
- Oauth2 is an authorization framework and JWT is an authentication protocol
- No matter which way you use, remember to use HTTPS to ensure data security
- 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.
- 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