Last time IN JSON Web Tokens – Securely transferring Information between Web Applications I mentioned that JSON Web tokens can be used to design single sign-on systems. I try to use eight cartoons to give you an idea of how to design a normal user authentication system and then extend it to a single sign-on system.

If you haven’t already read JSON Web Token – Securely Transferring Information between Web Applications, I highly recommend that you spend ten minutes reading it to understand how JWT is generated and how it works.

There are eight steps for user authentication

The so-called user Authentication (Authentication), is to allow users to log in, and in the following period of time to allow users to access the website to use their account, without the need to log in again mechanism.

Tip: Don’t confuse user authentication with Authorization. User authorization refers to specifying and allowing users to use their own rights, such as Posting, managing a site, etc.

First, the server application (hereinafter referred to as the “application”) lets users send their user name and password to the server’s interface via a Web form. This process is typically an HTTP POST request. The recommended method is ssl-encrypted transmission (HTTPS protocol) to avoid sensitive information being sniffed.

Next, the application and database check the username and password.

After the user name and password are verified successfully, the application regards the user ID (user_id in the figure) as an attribute of the JWT Payload, concatenates the user ID with the header, and signs the JWT. Here JWT is a string like ll.zzz.xxx.

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

Each time the user accesses the application, the application will receive a Cookie containing JWT before the Cookie expires or is deleted. The application can then extract the JWT from the request.

The application checks the validity of the JWT through a series of tasks. For example, check whether the signature is correct. Check whether the Token expires. Check whether the recipient of the Token is itself (optional).

After confirming that the JWT is valid, the JWT decodes Base64 (which was probably done in the previous step) and reads the user’S ID value, the user_id attribute, in the Payload. The user ID is 1025.

The application fetches information about the user with ID 1025 from the database, loads it into memory, and performs a series of low-level logic initializations like ORM.

The application responds to user requests.

The storage ID is different from that in Session mode

The biggest drawback to storing user ids in the Session mode is that it takes up a lot of server memory and may store a lot of state for larger applications. Generally speaking, large applications also need to use some KV databases and a series of caching mechanisms to realize Session storage.

JWT disperses the user state to the client, which can significantly reduce the memory pressure on the server. In addition to the user ID, other user-related information can be stored, such as whether the user is an administrator and which bucket the user belongs to (see “All you need to know about A/B testing basics” /2015/08/27/introduction-to-ab-testing/).

While the JWT approach imposes some computational pressures on the server (such as encryption, encoding, and decoding), these pressures may be of equal importance to disk I/O. You need to use data in different scenarios.

Single sign-on (sso)

Session mode stores user ids. At first, user sessions are stored on only one server. If a site has multiple subdomain names, each subdomain name must correspond to at least one server. For example:

  • www.taobao.com
  • nv.taobao.com
  • nz.taobao.com
  • login.taobao.com

Therefore, in order to realize that the Session can still be obtained from other sub-domain names after logging in at login.taobao.com, we need to synchronize the Session on multiple servers.

JWT does not have this problem because the user’s state is already transmitted to the client. Therefore, we only need to set the domain containing JWT cookies to a top-level domain, for example

Set-Cookie: jwt=lll.zzz.xxx; HttpOnly; max-age=980000; domain=.taobao.comCopy the code

Note that domain must be set to a dot plus top-level domain, i.e..taobao.com. In this way, taobao.com and *. Taobao.com can receive this Cookie and get JWT.

If you have questions about the two JWT articles, please discuss them directly with me in the comments section below (please do not email them). If you’re interested, you can subscribe to my bi-monthly newsletter below and I’ll have more great content for you;)