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

Source: John Wu

I mentioned the last time that JSON web token– securely passed information between Web apps, and I mention that JSON web tokens can be used to design a single sign-on system. 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 uses the user's ID (user_id in the figure) as a property of the JWT payload, and then signs it with the head separately BASE64 encoded stitching, forming a JWT. The JWT here is a string of the same lll.zzz.xxx.

The app returns the JWT string as part of the request cookie to the user. Note that the HttpOnly property must be used here 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 receive a cookie containing JWT. 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 in payload, which is the user_id attribute. Here the user's ID is 1025.

The application takes information from the database to a user with ID 1025, loads into memory, and initializes a series of underlying logic 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 in the login.taobao.com login, under the other sub-domain can still be taken to the session, which requires us to synchronize the session on more than one server.

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 domain of the cookie containing the JWT as the top-level domain, for example

1	Set-Cookie: jwt=lll.zzz.xxx; HttpOnly; max-age=980000; domain=.taobao.com

Note Domain must be set to a dot plus top-level domain name, which is. taobao.com. In this way, both taobao.com and *.taobao.com can accept this cookie and get a JWT.

From:http://www.importnew.com/25271.html

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