Shulou(Shulou.com)06/02 Report--

This article mainly explains "what are the characteristics of Session, JWT and OAuth2". The content of the explanation is simple and clear, and it is easy to learn and understand. Please follow the editor's train of thought to study and learn "what are the characteristics of Session, JWT and OAuth2".

Session mode

The mainstream authorization mode of browsers adopts Session mode.

Participant browser participant server browser-> server: user logs in Note right of browser: provide user name, Password server-> server: generate and save Session ID Note right of server: Session ID associated with user server-> browser: return Session ID browser-> browser: automatically save Session ID to Cookie browser-> server: access Note right of browser again: automatically carry Cookie (including Session ID) server-> server: check whether Session ID is stored On the Note right of server: if it exists, it automatically matches the corresponding user and refreshes the Session expiration server-- > browser: return the response result

Characteristics

Session ID is generated on the server side, and the browser carries Session ID as its identity every time it visits.

The expiration time of Session is generally 30 minutes, and the expiration time is automatically refreshed for each visit.

advantage

No operation for 30 minutes. Session expires automatically to enhance security.

The server can set the Cookie of Session ID to HttpOnly, which prevents js from reading Session ID from Cookie. Avoid XSS vulnerabilities to obtain Session ID.

In line with the habits of most people.

Shortcoming

A copy of the Session information needs to be kept on the server side. In the case of multiple servers (such as clusters), Session synchronization is required.

As long as the Session remains refreshed, it is permanently valid (unless the user actively exits). If an attacker steals a Session ID from a browser or from a data transfer, the Session ID can be kept permanent.

JWT mode

The full name of JWT is JSON Web Token. It is suitable for distributed authorization mode. After the user logs in successfully, the authentication server returns a JWT with signature authentication. The JWT is saved in the client (such as a browser or APP), and each time you access the application server, put the JWT in the header of the http. Different from the centralized management of Session, JWT itself contains user information. Each application server can independently determine which user JWT is, whether it is legal or expired, and there is no need to confirm to the authentication server, and there is no problem of Session synchronization. JWT contains at least the following information:

Sub: Subject, which is usually the user's ID.

Exp: Expiration Time . Expiration time.

Signature: signature. Used to verify that JWT is legal.

Participant user browser participant application server participant authentication server user browser-> application server: access login page application server-> user browser: return login page user browser-> authentication server: login request Note right of user browser: provide user name, Password authentication server-- > user browser: prompt the user to log in successfully Note left of authentication server: return JWT Contains user ID, expiration time and signature user browser-> application server: obtain data Note right of user browser: header carries JWT application server-> application server: parse JWT Note right of application server: verify whether JWT is legal by signature, determine whether it expires, and obtain user ID application server-> user browser: return data

Access Token and Refresh Token

Access Token needs to be put into the header of http to access various resources. Due to frequent use and complex usage scenarios, the risk of leakage is high, so the expiration time will be relatively short, such as 30 minutes. If you let the user log back in every 30 minutes, it is obvious that the user experience is very poor. So when the authentication server returns Access Token, it will also return a Refresh Token. Refresh Token is not usually used, but is only used to obtain new Access Token from the authentication server, which is much safer.

Refresh Token validity period

Refresh Token is usually valid for 30 days. But in many mobile APP apps, they don't want users to log in every 30 days. If the validity period is set to 1 year or even 2 years, the risk is a little higher.

Add a certification validity period (e.g. 30 days) to Refresh Token, while the validity period can be longer (e.g. 1 year). As long as you refresh within the authentication validity period, you can obtain a new Refresh Token, and the certification validity period is recalculated, and the validity period is calculated according to the previous Refresh Token. If you refresh the authentication validity period, the Refresh Token will not be refreshed, and you can only get the Access Token with Remember Me permission.

As long as the user uses APP within 30 days, the Refresh Token is automatically refreshed without the need to log in again. You don't need to log in again until the refresh period expires after 1 year.

When the Access Token is refreshed, the new Refresh Token is returned automatically. There is no need to specifically refresh the Refresh Token.

Remember Me (remember me)

And when browsing a website, there are usually two levels of permissions, one is to remember my permissions, and the other is to log in.

Add Remember Me logo to Access Token. If the Refresh Token is refreshed after the validity period of the authentication, you can only get the Access Token of Remember Me permission.

Automatic expiration of 30 minutes

When using a browser to access, Refresh Token cannot be saved for a long time (security considerations). Refresh Token must be deleted when the browser closes or the user exits.

To simulate the mode in which the Session expires in 30 minutes, you can specify that the authentication validity of the returned Refresh Token is 30 minutes when accessed by the browser, and then refresh the Refresh Token after the user's operation to maintain the validity of the Refresh Token.

Refresh Token can be saved to Cookie or sessionStorage to ensure that the Refresh Token is deleted when the page is closed.

Refresh Token timing

Token can be refreshed automatically every 5 minutes (when automatic expiration is not required). If it needs to expire automatically, it should be refreshed according to the user's action. If the Token is refreshed more than 5 minutes after each operation, the Token will be refreshed automatically.

Refreshing the Token every 5 minutes can more accurately monitor the number of people online and better meet the requirements of simulated automatic expiration. If you think 5 minutes is too short, try 10 minutes.

Timing of re-login

In order to avoid a sudden re-login when the Refresh Token expires while the user is operating, the user should be required to log in again when the user reopens the APP in the last 30 days of the Refresh Token expiration.

Number of people online

If you need to monitor the number of people online, the authentication server should write the logged in data to the database. Because the validity of Access Token is very short, it usually takes 5 minutes to refresh to the application server. Therefore, it is easy to monitor the current online personnel.

The key to how to associate a large number of Access Token and Refresh Token with a user's login is that the user needs to generate a login ID when logging in, and write this ID to all subsequent Refresh Token and Access Token, then you can know which login of any Token belongs to which user.

Refresh Token leak monitoring

Since the same series of Refresh Token has the same login ID, and each Refresh Token will refresh the Access Token in 5 minutes or more, as long as the Refresh Token with the same login ID refreshes the Access Token twice in 5 minutes, it can be determined that Refresh Token has been compromised.

Forced offline

Refresh Token forced offline: you need to record all the published Refresh Token within the refresh validity period on the authentication server (you can only record the login ID), and check whether the login ID is forced offline each time you refresh the token. Since the Refresh Token is refreshed every 5 minutes and the Access Token is valid for 30 minutes, this referral does not take effect immediately. But the cost is low, as long as it is processed in the authentication server.

Access Token forced offline: high timeliness, immediate offline, but the cost is also high. When verifying the JWT, each application server is required to verify to the authentication server to check whether the login ID corresponding to the Access Token is forced offline. This has violated the original intention of JWT's self-described design, and the performance loss may be very large. However, it is available when the authentication server and the application server are the same server.

OAuth 2

Mainly used for third-party login, such as Wechat login, QQ login, Weibo login and so on. All applications must first file with the authentication server (such as Wechat, QQ, Weibo) and obtain the client ID (Client ID) and client key (Client Secret).

Participant user browser participant application server participant authentication server user browser-> application server: login request application server-> user browser: redirect to authentication server Note left of application server: provide Client ID user browser-> authentication server: allow authorized Note right of user browser: provide user name, Password and Client ID authentication server-- > user browser: return authorization code and redirect to application server Note left of authentication server: authorization code is passed in browser Could be leaked. So it can only be used to obtain Token user browser-> application server: provide authorization code application server-> authentication server: get Token Note right of application server: provide authorization code, Client ID, Client Secret authentication server-- > application server: return Token application server-> authentication server: get user information Note right of application server: provide Token authentication server-- > application server: return the information of the corresponding Token user application server-- > user browser: prompt the user to log in successfully

Thank you for reading, the above is the content of "what are the characteristics of Session, JWT and OAuth2". After the study of this article, I believe you have a deeper understanding of what are the characteristics of Session, JWT and OAuth2, and the specific use needs to be verified in practice. Here is, the editor will push for you more related knowledge points of the article, welcome to follow!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.