As we all know, when carrying out the front and back end interaction or interface data operation, it is necessary to verify who will perform the operation and whether there is relevant permission
Cookie
A cookie is a very specific thing. It refers to a kind of data that can be stored permanently in the browser. It’s just a data storage function implemented by the browser.
The cookie is generated by the server and sent to the browser, which saves the cookie in the form of KV in a text file under a directory. The cookie will be sent to the server when the same website is requested next time. Since cookies are stored on the client, browsers put in some restrictions to ensure that cookies can’t be used maliciously and don’t take up too much disk space, so the number of cookies per field is limited.
Session
A session is literally a session. It’s kind of like when you’re talking to someone, how do you know that you’re talking to A Joe and not a Joe? There must be something about the other person that says he is Zhang SAN.
Sessions are similar in that the server needs to know who is currently sending the request to it. To do this, the server assigns a different “id” to each client, and then each time the client sends a request to the server, it carries this id so that the server knows who the request is coming from. As for how the client saves this “identity”, there are many ways, for the browser client, everyone uses cookie by default.
The server uses a session to temporarily store user information on the server, which is destroyed when the user leaves the site. This method of storing user information is more secure than cookies, but sessions have a drawback: if the Web server is load-balanced, the session will be lost when the next operation request reaches another server.
Token
Token-based authentication is ubiquitous in the Web world. Tokens is the best way to handle authentication across multiple users in most Internet companies that use Web APIS.
The following features allow you to use token-based authentication in your applications
Stateless, extensible support for mobile device cross-application call security for those who use token-based authentication
Most oF the apis and Web applications you’ve seen use Tokens. Facebook, Twitter, Google+, GitHub, etc.
Server-based authentication
We all know that the HTTP protocol is stateless, which means that the program needs to verify every request to identify the client.
Until now, applications have identified requests based on login information stored on the server. This is usually done by storing sessions.
With the rise of the Web, applications, and mobile, this approach to validation is becoming increasingly problematic. Especially in terms of scalability.
Some issues exposed by server-based authentication
Seesion: Each time an authenticated user makes a request, the server needs to create a record to store information. As more and more users make requests, the memory overhead increases.
Scalability: The use of Seesion in server memory to store login information comes with scalability issues.
CORS(Cross-domain resource sharing) : Cross-domain resource sharing can be a headache when data needs to be used across multiple mobile devices. When using Ajax to fetch resources from another domain, requests can be disabled.
CSRF(Cross-site request forgery) : When a user visits a bank website, they are vulnerable to cross-site request forgery and can be used to access other websites. Of these, extensible rows are the most prominent. Therefore, it is necessary for us to seek a more effective method.
Token-based authentication principle
Token-based authentication is stateless and we do not store user information in the server or Session.
This concept solves many problems when storing information on the server side
NoSession means that your application can add and subtract machines as needed without worrying about whether the user is logged in or not. Token-based authentication is performed as follows:
A user sends requests using a user name and password. Program validation. The program returns a signed token to the client. The client stores tokens and uses them each time to send a request. The server validates the token and returns data. Each request requires a token. The token should be sent in the HTTP header to ensure that the HTTP request is stateless. We also set access-Control-allow-Origin :* to Allow the server to receive requests from all domains.
It is important that certificates such as HTTP authentication, client SSL certificates and cookies are not included in the ACAO header marked (designating)*.
The advantage of Tokens
Stateless and extensible
Tokens stored on the client side are stateless and scalable. Based on this statelessness and not storing Session information, the load balancer can transfer user information from one service to another.
If we store information about authenticated users in a Session, each request requires the user to send authentication information (called Session affinity) to the authenticated server. There may be some congestion when there are a lot of users.
But don’t worry. With Tokens, all of these problems are solved because Tokens itself holds the user’s authentication information.
security
Sending tokens instead of cookies in a request prevents CSRF(cross-site request forgery). Even if a cookie is used to store tokens on the client side, the cookie is only a storage mechanism and is not used for authentication. By not storing information in the Session, we have less access to the Session.
Tokens are time-limited and users need to re-verify them after a certain period of time. We also don’t have to wait until the token is automatically invalidated. There is a withdrawal of the token. Token revocataion can invalidate a particular token or a group of tokens that have the same authentication.
scalability
Tokens creates programs that share permissions with other programs. For example, the ability to associate a casual social media account with your Twitter account (Facebook or Twitter). When logging into Twitter from a service (we have this process Buffer), we can attach these buffers to The Twitter stream where they are hard to work.
With Tokens, you can provide optional permissions to third party applications. When users want another application to access their data, we can create tokens with special permissions by building our own API.
Multiple platforms cross domains
Let’s start by talking about CORS(Cross-domain resource Sharing), which involves a wide variety of devices and applications when extending applications and services.
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 token, data and resources can be requested in any domain.