The difference between JWT token and session

background knowledge

Authentication: User authentication refers to verifying the identity of the user. For example, if you want to log in as Little A, the application needs to confirm that you are really Little A through the username and password.

Authorization: Authorization refers to the authorization provided to you after confirming your identity. For example, user A can modify data, while user B can only read data.

Since the http protocol is stateless, each request is stateless. When a user logs in with a username and password, his next request will not carry any status, and the application cannot know his identity, so he must re-authenticate. Therefore, we hope that every http request after the user successfully logs in can save his login status.

Currently, there are two mainstream user authentication methods: token-based and session-based.

What is JWT

Json web token (JWT), is a JSON-based open standard ( (RFC 7519 ) implemented for passing claims between web application environments . The token is designed to be compact and secure, especially suitable for single Sign-on (SSO) scenario. JWT claims are generally used to pass authenticated user identity information between identity providers and service providers, so as to obtain resources from resource servers, and can also add some additional business logic necessary The declaration information of the token can also be directly used for authentication or encrypted.

origin

Speaking of JWT, we should talk about the difference between token-based authentication and traditional session authentication.

Traditional session authentication

We know that the http protocol itself is a stateless protocol, which means that if the user provides a user name and password to our application for user authentication, the user will have to perform user authentication again when the next request is made. OK, because according to the http protocol, we don't know which user made the request, so in order for our application to identify which user made the request,We can only store a piece of user login information (session) on the server, and this login information (sessionID, sessionID is used to identify the session) will be passed to the browser in response, and the browser will save the sessionID in the cookie for next time Sent to our app when requested, so that our application can identify which user the request comes from, which is the traditional session-based authentication.

But this session-based authentication makes the application itself difficult to expand,With the increase of different client users, independent servers can no longer carry more users, and at this time, the problems of session-based authentication applications will be exposed.

session authentication process

  1. User enters their login information

  2. The server verifies that the information is correct, creates a session, and thenUser Info(such as user name ID, etc.) placed in the session and stored in the server-side memory

  3. The server generates a sessionId for the user, will have the sessionId'sCookies will be placed in the user's browserMedium (sessionID is stored in the cookie in the browser)

  4. On subsequent requests, the browsercarry sessionIDSend the request, the server will verify the sessionID andGet the currently logged in user information from the session

  5. Once the user logs out of the application, the session will be destroyed on both the client and server side

session code example

  • In the process of storing information in the session by the server, the subsequent response will return the session ID and store it in the browser cookie. session exists in server memory
    insert image description here
  • The server gets it in the sessionUser InfoThe process of requesting carries the sessionID (the process of parsing the sessionID is not in the code). session exists in server memory
    insert image description here

Issues revealed by session-based authentication

Session : After each user is authenticated by our application, our application must make a record on the server side to facilitate the identification of the user's next request. Generally speakingSessions are stored in memory, and with the increase of authenticated users, the overhead of the server will increase significantly

Extensibility : After the user is authenticated, the server makes an authentication record. If the authentication record is stored in memory,This means that the user's next request must also be requested on this server, so as to obtain authorized resources, so that in distributed applications, the capacity of the load balancer is correspondingly limited. This also means limiting the appliedScalability

CSRF : Because it is based on cookie for user identification, if the cookie is intercepted, the user will be vulnerable to cross-site request forgery.

token-based authentication mechanism

The token-based authentication mechanism is similar to the http protocol and is also stateless, itThere is no need to retain user authentication information or session information on the server side. This means that the application based on the token authentication mechanismThere is no need to consider which server the user is logged in, which facilitates the expansion of the application

The process is like this:

  1. User enters their login information

  2. The server verifies that the information is correct and returns the signed token

  3. The token is stored on the client, such as in local storage or in a cookie

  4. Subsequent HTTP requests will add token to the request header

  5. The server decodes the JWT, and if the token is valid, accepts the request

  6. Once the user logs out, the token will be destroyed on the client side, no interaction with the server is required One key thing is, the token is stateless. The backend server does not need to keep a record of the token or the current session.

This token must be passed to the server every time it is requested, it shouldstored in the request header, In addition, the server must support CORS(跨来源资源共享)policies, and generally we can do this on the server Access-Control-Allow-Origin: *.

Code example based on token mechanism

Front-end and back-end separation projects

  • When logging in for the first time, after verification,Generate token by user id and password visa, and return the token in the response
    insert image description here
  • The front-end storage token is stored in the browser's localstorage

insert image description here

  • The token is carried when the front end requests other back-end interfaces, inrequest headercarry in

insert image description here

  • The backend can not only obtain user information but also perform user authentication through the request header token, the following isInterceptor for user authentication
    insert image description here
  • Get the current login through tokenUser Info, after getting the tokenGo to the database to query, instead of directly fetching in the server memory like the session, no need to consider which server the user is logged in
    insert image description here
    insert image description here

So let's go back to the topic of JWT now.

For a detailed explanation of JWT, see the article JWT

Guess you like

Origin blog.csdn.net/hhb442/article/details/131984567