Eight Comics understanding single sign-on system with JWT design

Last time in the JSON web Token-securely passing information between Web applications I mentioned that JSON Web Token can be used to design a single sign-on system. I try to use eight cartoons first to let you 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 applications, I strongly recommend that you take 10 minutes to read it and understand the JWT generation process and principles. user authentication eight steps away

The so-called user authentication (authentication), is lets the user log in, and in the next time lets the user visit the website to be possible to use its account, but does not need to log in again the mechanism.

Little knowledge: Do not confuse user authentication with user authorization (Authorization). User authorization refers to the provision and allows users to use their own permissions, such as posting posts, management sites and so on.

First, the server application (hereinafter referred to as "Application") lets users send their username and password to the server's interface through a Web form. This process is typically an HTTP POST request. The recommended approach is to encrypt the transmission via SSL (HTTPS protocol), thereby avoiding sensitive information being sniffed.

Next, apply and database check user name and password.

After checking the user name and password successfully, the user's ID (user_id in the figure) is used as an attribute of the JWT payload, and the BASE64 code is spliced with the head respectively to form a JWT. The JWT here is a string of lll.zzz.xxx.

The application returns the JWT string as part of the request cookie to the user. Note that the HttpOnly property must be used here to prevent the cookie from being read by JavaScript, thereby avoiding Cross-site scripting attacks (XSS attacks).

Before the cookie is invalidated or deleted, the application will receive a cookie containing JWT each time the user accesses the application. Thus the application can extract the JWT from the request.

The application examines the effectiveness of JWT through a series of tasks. For example, check that the signature is correct, check that the token is expired, and check that the recipient of the token is on its own (optional).

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

Apply the information from the database to the user ID 1025, load into memory, perform a series of low-level logic initialization such as ORM.

The application responds based on user requests.

differences in storage IDs with session mode

The biggest drawback to storing user IDs in session mode is that it takes up a lot of server memory and may save a lot of state for larger applications. In general, large applications also need to use a number of KV database and a series of caching mechanisms to implement session storage.

And the JWT mode will spread the user state to the client, can reduce the memory pressure of the service side obviously. In addition to the user ID, you can store other user-related information, such as whether the user is the administrator, the user's bucket (see ["You Should know the" A/b test base] (/2015/08/27/introduction-to-ab-testing/), etc.

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. Specific use, need to use the data in different scenarios to speak. single point of entry

Session mode to store the user ID, and the first user sessions are stored on only one server. For sites with multiple subdomains, each subdomain will correspond to at least one different server, for example: www.taobao.com nv.taobao.com nz.taobao.com login.taobao.com

So if you want to implement the login.taobao.com login, you can still take the session under other subdomains, which requires us to synchronize sessions on multiple servers.

There is no such problem with JWT, because the user's state has been transferred to the client. Therefore, we only need to set the domain of the cookie containing JWT as the top-level domain name, for example

set-cookie:jwt=lll.zzz.xxx; HttpOnly; max-age=980000; Domain=.taobao.com

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

The author of this article: John Wu original link: http://blog.leapoahead.com/2015/09/06/understanding-jwt/

Copyright belongs to the author, reprint please indicate the source