Eight comics understanding design of single sign-on system using JSON Web token

The last time I mentioned the JSON Web token-securely passing information between Web Apps-I referred to the ability to design a single-sign-on system with the help of a one-point login. I try to use eight cartoons to first understand how to design a normal user authentication system, and then extend to the single sign-on system.

If you haven't read the JSON Web Token-securely passing information between Web apps, I highly recommend that you spend 10 minutes reading it to understand the process and principles of JWT generation.

User authentication eight steps away

The so-called user authentication (authentication) is a mechanism that allows users to log in and use their accounts for the next period of time, without having to sign in again.

Tip: Don't confuse user authentication with user authorization (Authorization). User authorization refers to rules and allows users to use their own permissions, such as posting posts, managing sites, and so on.

First, the server application (hereinafter referred to as the "app") lets the user send their user name and password to the server's interface through a Web form. This process is typically an HTTP POST request. The recommended approach is to use SSL-encrypted transmissions (HTTPS protocol) to avoid sniffing sensitive information.

Next, the app and database check the user name and password.

After checking the user name and password successfully, the application will use the user's id (pictured user_id ) as a property of the JWT payload, and then sign the Base64 with the head separately, and form a JWT. The JWT here is a lll.zzz.xxx string of the same shape.

The app returns the JWT string as part of the request cookie to the user. Note that attributes must be used here HttpOnly to prevent cookies from being read by JavaScript, thus avoiding cross-site scripting attacks (XSS attacks).

Before the cookie expires or is deleted, each time the user accesses the app, the app will accept jwt the cookie contained. This enables the application to extract the JWT from the request.

The app checks the validity of the JWT through a series of tasks. For example, check that the signature is correct, check that tokens are out of date, and check to see if the token receiver is itself (optional).

After the application confirms that the JWT is valid, the JWT is Base64 decoded (possibly completed in the previous step) and then reads the user's ID value, which is the attribute, in payload user_id . The user here id is 1025.

Apply information from the database to id 1025 of users, load into memory, and perform a series of underlying logic initializations such as ORM.

The app responds based on user requests.

and session mode Store ID differences

The biggest disadvantage of storing user IDs in session mode is that it takes up a lot of server memory, and many states may be saved for larger applications. In general, large applications also need to use some KV databases and a series of caching mechanisms to implement session storage.

And the JWT mode will spread the user state to the client, which can reduce the memory pressure of the server obviously. In addition to the user ID, you can also store other user-related information, such as whether the user is an administrator, the user's bucket (see the "A/b test basis you should Know" article) (/2015/08/27/introduction-to-ab-testing/), and so on.

Although the JWT approach gives the server some computational pressure (such as encryption, encoding, and decoding), these pressures may be Dora compared to disk I/O. Whether or not to use, you need to use data to speak in different scenarios.

Single Sign-on

Session to store the user ID, the user's session will only be stored on a single server at the beginning. For sites with multiple subdomains, each subdomain will at least correspond to a different server, for example:

• Www.taobao.com
• Nv.taobao.com
• Nz.taobao.com
• Login.taobao.com

So if you want to implement login.taobao.com after logging in, the other sub-domain can still be taken to the session, which requires us to synchronize the session on multiple servers.

The way to use JWT does not exist because the user's state has been routed to the client. Therefore, we only need to set the cookie containing JWT domain as the top-level domain, for example

1	Domain=.taobao.com

Note domain You must set the top-level domain name to a point, that is .taobao.com . In this way, both taobao.com and *.taobao.com can accept this cookie and get a JWT.

For questions about two of JWT's articles, please talk to me directly in the comments section below (do not email discussion). If you are interested, you can subscribe to my fortnightly below, I will send you more wonderful content;)

Eight comics understanding design of single sign-on system using JSON Web token