The HTTP protocol is stateless. After each HTTP request response, the connection is disconnected. If the client sends a request again, the server cannot identify whether the client is the same as the last request, and the HTTP protocol cannot perform session tracing. Cookie, Session and Token are designed to solve the stateless problem of HTTP protocol.

Cookie

Cookie mechanism is implemented in the client, using the client to maintain state scheme. The Cookie is generated by the server and sent to the client (set-cookie). The client will carry the Cookie when requesting the Cookie. Request process:

• Name: Name
• Value: the Value
• Domain: the Domain
• Path: the Path
• Expaires/ max-age: expiration time

The cookies logged_in and user_session in the preceding figure represent the login status and Session saved after logging in to github.com.

Session

Session is implemented on the server. When the client requests the server, the server checks whether the request contains the Session ID.

• If not, the server generates a random Session with a matching Session ID and returns the Session ID to the client.
• If so, the server finds the corresponding Session in the store based on the Session ID.

Token

Token, also known as Token, consists of uid+time+sign[+ fixed parameter] :

• Uid: indicates the unique user identity
• Time: indicates the timestamp of the current time
• Sign: the signature is compressed into a hexadecimal string of fixed length using hash/encrypt to prevent malicious third parties from joining Token requests to the server

The following features allow you to use token-based authentication in your application:

• Stateless and extensible
• Mobile device support
• Cross-program call
• security

The Token is stored by the client. The user’s status is not stored in the server’s memory, so it is a stateless authentication mechanism. The specific process of certification is as follows:

The server receives the request and authenticates the user name and password. After the authentication succeeds, the server issues a Token and sends the Token to the client. After receiving the Token, the client can store it. For example, every time a client requests resources in a Cookie or Local Storage, it needs to bring the Token signed by the server. The server receives the request and verifies the Token in the request. If the verification succeeds, it returns the requested data to the client

Third-party Authorized Login

This is an application scenario of Token, implemented using OAuth. OAuth (Open Authorization) is an open standard that allows a user to give third-party applications access to the user’s private resources (such as photos, videos, and contact lists) stored on a site without having to provide a user name and password to third-party applications. OAuth allows users to provide a token, rather than a username and password, to access the data they store with a particular service provider. Let’s take a look at github’s licensing process:

How to design a user table for third-party login

The difference between

The Cookie and Session

Token and Session

Token as authentication is more secure than Session. Session is an HTTP storage mechanism designed to provide a persistence mechanism for stateless HTTP. Tokens, if referred to as OAuth tokens or similar mechanisms, provide authentication and authorization, authentication for the user and authorization for the App.

reference

• Cookies, sessions, tokens
• Thoroughly understand cookies, sessions, and tokens
• Close reading of Illustrated HTTP