This is the ninth day of my participation in the August More text Challenge. For details, see: August More Text Challenge

1. User identity authentication

1.1 Single-server Mode

The general process is as follows:

  • 1. The user sends the user name and password to the server
  • 2. After authenticating the server, relevant data (user name, role) will be saved in the current session
  • 3. The server returns session_ID to the user, and the session information is written to the Cookie of the user
  • 4. Each subsequent request from the user will be passed to the server by extracting the session_ID from the Cookie
  • 5. The server receives the session_ID and compares it with the previous data to confirm the user’s identity

Disadvantages:

  • Single point performance pressure, not scalable
  • In distributed architecture, session sharing scheme is required, but session sharing scheme has performance bottleneck.

1.2 SSO mode

Distributed, SSO model: Single Sign-on, or SSO. Its resolution is that in multiple application systems, you only need to log in once to access other trusted application systems.

  • If service B needs to log in to the SSO system, the system switches to the SSO system
  • Service A and service B do not log in to the module
  • SSO has only the login module and no other business module

The general process is as follows:

  • 1. When service A and service B need to log in to the SSO system, add the bar to the SSO system
  • 2. SSO obtains the user information from the user information database and verifies the user information. The SSO system is logged in
  • 3. Then store the user information in the cache
  • 4. When A user accesses service A or service B and needs to check whether the user has logged in, the SSO system switches to the SSO system for user authentication. SSO checks whether the user identity information exists in the cache
  • 5. In this way, once one system is logged in, the other application systems are logged in as well. This is the definition of single sign-on

Advantages:

Independent management of user identity information, better distributed management. You can extend your own security policies

Disadvantages:

The authentication server is under heavy access pressure

1.3 Token mode

Advantages:

  • Stateless: A token is stateless and a session is stateful
  • Based on standardization: Your API can use standard JSON Web Tokens (JWT)

Disadvantages:

  • Take up broadband
  • Cannot be destroyed on the server

JWT token

2.1 What is a JWT token

JWT stands for JSON WEB TOKEN, or JSON WEB TOKEN, and is a self-contained TOKEN.

Usage scenarios of JWT:

  • One case is WebAPI, similar to the ali Cloud play credentials before the function

  • Another scenario is stateless distributed authentication with multiple Web servers

    • The JWT website has a picture of the certification process

The role of JWT:

  • The most important function of JWT is the anti-counterfeiting function of token information

How JWT works:

  • A JWT consists of three parts: the JWT header, the payload, and the signature hash
  • Finally, JWT is obtained by base64 encoding with the combination of the three

2.2 JWT token composition

Typically, a JWT looks like this

jwt.io/

The object is a long string with three substrings separated by a “.” delimiter.

Each substring represents a function block, which has three parts: the JWT header, payload, and signature

2.2.1 JWT head

The JWT header section is a JSON object that describes the JWT metadata, typically as shown below.

{"alg": "HS256", // encryption algorithm "typ": "JWT" // fixed type}Copy the code

In the above code, the alG attribute represents the algorithm used for the signature, which defaults to HMAC SHA256 (written as HS256). The TYP attribute indicates the type of the token, and JWT tokens are written as JWT. Finally, we use the Base64 URL algorithm to convert the above JSON object into a string for preservation.

2.2.2 Payload

The payload part, which is the body content part of the JWT, is also a JSON object that contains the data to be passed. JWT specifies seven default fields to select from.

Iss: JWT issuer sub: subject AUD: the party receiving the JWT EXP: The expiration time of the JWT, which must be greater than the issue time NBF: Defines the time before the JWT is unavailable Iat: JWT issue time JTI: JWT's unique identity is mainly used as a one-time token to avoid replay attacks.Copy the code

In addition to the above default fields, we can also customize private fields, as shown in the following example:

{
  "name": "Helen",
  "admin": true,
  "avatar": "helen.jpg"
}
Copy the code

Please note that by default JWT is unencrypted and anyone can interpret its contents, so do not build a private information field to store confidential information to prevent disclosure.

JSON objects are also saved as strings converted using the Base64 URL algorithm.

2.2.3 Signature hashing

The signature hash part is the signature of the above two parts of the data and the hash is generated by the specified algorithm to ensure that the data will not be tampered with.

First, you need to specify a password (secret). The password is stored on the server only and cannot be disclosed to the user. Then, using the signature algorithm specified in the header (HMAC SHA256 by default), the signature is generated according to the following formula.

HMACSHA256(base64UrlEncode(header) + "." + base64UrlEncode(claims), secret)
Copy the code

2.3 Base64 URL algorithm

As mentioned earlier, both the JWT header and the payload serialization algorithm use Base64URL. This algorithm is similar to the common Base64 algorithm, with some differences.

JWT as a token can be placed in a URL (for example, api.example/? Token = XXX). The three characters used in Base64 are “+”, “/” and “=”, and because they have special meanings in urls, they are replaced in Base64URL: “=” is removed, “+” is replaced with “-“, and “/” is replaced with “_”. This is the Base64URL algorithm.

Note: Base64 encoding, which is not encryption, just turns the plaintext into an invisible string. But base64 encoding can be broken down into plaintext with a few tools, so don’t put private information in JWT.

2.4 JWT usage

The client receives the JWT returned by the server and stores it in a cookie or localStroege

After that, the client will carry JWT in its interactions with the server. If it is stored in a Cookie, it can be sent automatically, but it will not cross domains, so it will generally be put in the Header Authorization field of the HTTP request

JWT can also be placed in the data body of a POST request when it is cross-domain.

JWT issues and trends

1. JWT does not encrypt by default, but can encrypt. Once the original token is generated, it can be encrypted again using that token.

2. When JWT is not encrypted, some private data cannot be transmitted through JWT.

3. JWT can not only be used for authentication, but also for information exchange. Making good use of JWT can help reduce the number of server requests to the database.

4. The biggest drawback of JWT is that the server does not save session state, so it is impossible to cancel or change privileges on a token during use. That is, once the JWT is issued, it will remain in effect for the duration of its validity.

5. JWT itself contains authentication information, so anyone can gain full access to the token if the information is leaked. In order to reduce theft, the validity period of JWT should not be set too long. For some important operations, users should authenticate every time they use it.

6. In order to reduce theft and theft, JWT does not recommend using HTTP to transmit code, but using the encrypted HTTPS protocol for transmission.