Hi, I’m a mouse

Most modern applications are developed separately from the front and back ends. The front end (client) is responsible for interaction with the user, while the back end (server) is responsible for processing data requests and replying to requests from the front end. The two ends transmit data through HTTP protocol.

However, HTTP protocol is a stateless protocol, each server access is irrelevant, the client does not remember the content of each visit,

Imagine that you log on to your account on November 11, ready to shop. But every time you open a new page, the server doesn’t remember that you logged in, so you have to log in again, and the user experience is a little bit worse.

So there is the emergence of sustainable access, which essentially means making access state through external storage. Common solutions include:

  • Sessionstorage
  • Tokenstorage
  • Credentialsauthorization

In fact, these three schemes are essentially based on Cookie. Cookie here refers to browser Cookie, which is used to store a small amount of user information and is attached to the request message of the client. When the server receives the request, it can read the Cookie in the request message. Thus achieving the purpose of state access.

This is actually the simplest Session Session, which is very common in early network applications, but the problem is obvious, users can view and tamper with cookies, which is not safe.

Session

Session refers to the Session generated during the access between the client and the server, which is used to store the interaction information. In the early days, the server generally replies to the client in the Cookie, and the client accesses the server with the Cookie. This is called a client Session.

But as mentioned before, the user can view and manipulate the contents of the Cookie, so we have a server Session, and when we talk about a Session, we actually mean a server Session.

A server Session stores user information in the backend database, and a session_ID is stored in the Cookie and returned to the client. Session_id is also an early token.

The client carries a Cookie in each request, and the server recognizes the Cookie and accesses the corresponding data in the database through the session_ID in it, so as to achieve the purpose of sustainable access.

The advantages of the Session

This refers to the server Session as opposed to the traditional Cookie (client Session) :

  • High security: Information is stored on the server and cannot be tampered with.
  • It can store large information: the Cookie itself can only support less than 4Kb, while the Session is stored on the server and depends on the database, and the capacity is unlimited.
  • Storage types vary: Cookies only allow string types, while sessions allow arbitrary types.
  • High controllability: The Cookie itself can only set a fixed validity time, while the Session is stored on the server, which can adapt to various scenarios and effectively manage.
    • Deleting an Invalid Session
    • Session clearing automatically after expiration
    • Refresh the validity time

The disadvantage of the Session

Sessions are not perfect, and their shortcomings can be exposed in different scenarios.

  • Server burden: As the number of users increases, each user stores interactive information in the server, which is bound to cause server burden.

  • Sessions rely on HTTPS secure access: In an insecure network environment, cookies can be stolen, which means sessionIDS can be stolen

  • Sesion_ID Theft risk: As mentioned above, session_ID is an early token that can be used by unauthorized users to steal sessions

    Of course, this can be ensured by storing the IP address and proxy information that the user accesses on the server, but this will result in larger sessions and the user may need to log in frequently.

  • Non-cross-domain: This is because cookies are not cross-domain. Different domain names require different authentication

  • Unshareable: In the case of multiple cluster servers, the Session of server A and server B is not shared

  • CSRS attacks: If the site is a malicious script such as http://www.bank.com/api/transfer?count=1000&to=Tom, this script is stored in a text or even a picture, if the way we use Session, when we click on the images will lead to trigger.

Token storage

Token refers to Token, which is a cross-domain authentication scheme. The most common Token scheme is JWT, which is similar to the process of client Session:

  • If the user logs in successfully, the server returns oneTokenTo the client.
  • Client-side saveTokenOn the client sidelocalStorage.sessionStorage.Cookie (not recommended)In the.
  • Client access server carryTokenPut cookies in the request header (cookies are not recommendedAuthorizationIn the field)
  • Server verificationTokenThe request data is returned on success, and an error code is returned on failure.

The encryption in the JWT token is as follows:

  • Header: token type
  • Payload: User information
  • Signature: To verify information and ensure that the content is not tampered with

As long as all three pass validation, the token is determined to be valid.

Token advantage

  • Tokens are protected against, or specifically against, CSRF attacks and are not automatically added to the request header.

  • The Token is stored in the Authorization field of the packet header.

  • The Token supports cross-domain sharing and can be shared with third parties. Details about the mechanism will be described later.

  • Tokens are independent of cookies and work well on mobile devices.

  • The Token is stored in the localStorage client, making the server stateless and reducing the burden.

Token shortcomings

  • TokenYou cannot manage the tokens you issue, and it is difficult for the server to unregister them if they are stolen. thisSessionYou can control your conversation well.

Authorization Credentials

Different application scenarios

Token is suitable for mobile, third-party sharing API, one-time authorization and protection against CSRF attacks.

Session is suitable for managing sessions, especially for user login, logout, and password change. The best practice is still Session.

Is there a way to combine the advantages of both to make up for the disadvantages?

Credentials authorization is one solution, and it is widely used in modern applications, such as logging in to a website, using QQ accounts to log in, and verifying third-party applications.

A common application is OAuth, which allows users to provide an authorization layer that itself is HTTPS and third-party applications are HTTP. See OAuth for details

On the one hand, we manage the state of user account through Session at the top level; on the other hand, we can authorize third-party applications through OAuth.

This is typical SSO single sign-on combined with token authorization.

Related articles recommended

First of all, thank you very much for reading. Your likes and attention are the best support for me.

If there are any errors in the article, thank you very much for pointing them out, and you are welcome to discuss them with me.

Cookie, Session, Token, JWT