The HTTP protocol itself is stateless, requiring browsers and clients to solve this problem, and these three technologies have emerged to solve this problem

1. The cookie authentication

  • Is a piece of data sent by the server to the client to authenticate a session.
  • The cookie field of different websites is set by the server, and the session-ID or token value is usually added to verify the login status of the session.
  • The information exists in plaintext on the client
  • Information has a limitation problem

classification

  • The session cookies:

    • The key – value form,
    • When we visit the server with a browser, the server returns a session cookie. When we visit other pages on the site, we use this Coolie to authenticate our identity. You need to obtain the page again the next time you visit the page after the server restarts.
    • In general, when you visit a website, cookies don’t change,

  • Permenent cookies:

    • The value includes name, value, expiration time, and path
    • When accessing the server using a browser for the first time, the server generates permenent cookies and sends them to UA, which saves them in a certain directory.
    • The cookie is sent to the server the next time the same web site is requested

2. The session authentication

  • Encrypted data stored on the server side to store attributes and configuration information needed for a user’s particular session
  • The client initiates the request and the server generates and returns the sessionID, which can be set to expire even if the browser is not closed.
  • The session ID does not change when the user jumps between web pages of the application
  • Client to server: cookie
  • Request. Session from the server to the client

– Disadvantages: slow response and clustering issues (nginx: allocating resources between proxy servers)

2.1 Session Security Mechanism

  • Set the timeliness,
  • The browser is closed, and the session is invalid
  • When the IP address and UA of a user changes, the session expires

3 token authentication

  • Token is encrypted data generated by the server to the client to verify the login status of the user
  • In contrast to a session, tokens are authenticated and signed before being sent to the browser
  • There is a secret key, and the algorithm for claiming and verifying the token is one

3.1 Token Authentication Process

  1. The first time a client sends a request (username and password)
  2. After a successful login, the server digitally signs the login certificate, encrypts it, and returns the token value to the client
  3. The client sends the received token value to the cookie of the packet and sends the request to the server
  4. The server extracts the token value from the client, decrypts the token, authenticates the signature, and obtains the login certificate to determine its validity

JWT certification

That is, JSON Web Token authentication.

Json Web Token (JWT) is an open jSON-based standard (RFC 7519) implemented for the transfer of declarations between network application environments. The token is designed to be compact and secure, especially suitable for single sign-on (SSO) scenarios in distributed sites. The JWT declaration is generally used to pass authenticated user identity information between the identity provider and the service provider to obtain resources from the resource server, and to add some additional declaration information necessary for other business logic. The token can also be used directly for authentication or can be encrypted.

After a user registers or logs in, we want to record the user’s login status or create credentials for the user to authenticate. Instead of using Session authentication, we use Json Web Token authentication.

Composition of JWT certification

1. eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.
2. eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiYWRtaW4iOnRydWV9.
3. TJVA95OrM7E2cBab30RMHrHDcEfxjoYZgeFONFh7HgQ
Copy the code

• Header

  • Declaration type: GWT
  • Declaration visa algorithm: HS256
  • And encrypted: Base64 algorithm (decryptable)
{
  'typ': 'JWT',
  'alg': 'HS256'
}
Copy the code

• Payload

  • Stores valid information, including the following three parts
  • Standard Statement: Iss (JWT issuer), SUB (JWT user), AUD (JWT receiving party), exp (JWT expiration time, must be greater than issue time) NBF (scheduled before what time, The JWT is not available), IAT (JWT issue time), JTI (JWT unique identity representation, mainly used as a one-time token to avoid replay attacks)
  • Public declaration: You can add any information, such as user information or other necessary information required by services. Sensitive information is not recommended because it can be decrypted on the client
  • Private declaration: a declaration defined by both the provider and the consumer. It is generally not recommended to store sensitive information, meaning that it can be classified as sensitive information

• Visa (Signature)

  • Header (Base64)
  • Payload (base64)
  • Secret Secret (salt)

Note: Secret is stored on the server side, JWT generation is also on the server side, secret is used for JWT signing and JWT authentication, so it is your server side private key and should not be disclosed in any scenario. Once the client is aware of this Secret, it means that the client can issue the JWT itself.