Token-based authentication

Session authentication requires the server to do a lot of work to ensure the consistency of session information and the storage of session. Therefore, modern Web applications tend to be client-oriented in authentication solutions. Cookie authentication is based on the client side, but the shortcomings of cookie are also obvious, which shortcomings can jump to the last article. Is there a compromise? some

Save the authentication information in the client, the key point is the security of the authentication information, if you can solve the security problem of the authentication information, you can save the authentication information in the client, the server has no authentication state, so that the extension of the server will be much more convenient. As for information security solutions, signature mechanism is now a common practice. For example, the verification method of wechat public interface is based on signature mechanism.

Signature is a number string that can only be produced by the sender of information and can not be forged by others. This number string is also an effective proof of the authenticity of the information sent by the sender of information.

When the user after successful login system and verify the effective, the server will use a mechanism to create a token string, the token can contain a lot of information, such as source IP, expiration time, user information and so on, put the string sent to the client, the client request every time after carrying this token, In fact, the carrying mode is very free, whether it is cookies or other methods, but it must be agreed with the server. Of course I don’t recommend cookies here. When the server receives the request, it takes out the token for verification (verification of source IP address, expiration time and other information). If it is valid, the operation is allowed.

Token-based authentication is also commonly used in the modern Internet, so what are its advantages?

  1. Cross-domain access is supported. Cookies do not allow cross-domain access. This does not exist for the Token mechanism, provided that the user authentication information is transmitted through HTTP headers.
  2. Stateless: The Token mechanism does not need to store session information on the server, because the Token itself contains information about all login users. The status information only needs to be stored in the cookie or local media of the client.
  3. Decoupling does not require binding to a specific authentication scheme. Tokens can be generated anywhere, as long as you can make Token generation calls when your API is called.
  4. Wider applicability: As long as the client supports THE HTTP protocol, the token authentication can be used.
  5. The server only needs to verify the token security and does not need to obtain the login user information, because the login user information is already in the token information.
  6. Standardisation based: Your API can use standardised JSON Web tokens (JWT). The standard already exists in several back-end libraries (.NET, Ruby, Java,Python,PHP) and is supported by several companies (e.g. Firebase,Google, Microsoft).

What are the disadvantages of token-based authentication?

  1. The amount of data transmitted on the network increases: Because the token stores a large amount of user and security-related information, it is much larger than the simple cookie information, which consumes more traffic and occupies more bandwidth during transmission.
  2. As with all client-side authentication methods, it is difficult to control the cancellation of tokens on the server side, and it is also difficult to solve the client hijacking problem.
  3. The token information adds an operation on the server to verify data integrity, thus increasing the CPU overhead compared with the session authentication mode.

But on the whole, token-based authentication has great advantages over session and cookie authentication. JWT is an excellent solution for token authentication known

jwt

JSON Web Token (JWT) is an open standard (RFC 7519) that defines a compact, self-contained way to securely transfer information between parties as JSON objects. This information can be authenticated and trusted because it is digitally signed.

A JWT is essentially a string made up of three parts, a header, a payload, and a signature.

The head

The header typically consists of two parts: the token type (” JWT “) and the algorithm name (such as HMAC SHA256 or RSA, etc.).

{
  "alg": "HS256",
  "typ": "JWT"
}
Copy the code
Payload

The Payload part is also a JSON object that stores the data that needs to be transmitted. JWT specifies seven official fields to choose from.

Iss (Issuer) : exp (expiration time) : expiration time sub (subject) : aud (audience) : NBF (Not Before) : iAT (Issued At) : Issue time JTI (JWT ID) : numberCopy the code

In addition to these fields, you can add any fields you want, but note that due to JWT standards, information is not encrypted, so it is best not to add sensitive information to JSON

{"Name":" Age":18}Copy the code
Signature

To get the signature part, you have to have an encoded header, an encoded payload, a secret key that only the server knows, and the signature algorithm specified in the header, and just sign them.

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

After calculating the Signature, add the Header, Payload, and Signature parts into a string, and use dots (.) between each part. Delimit, and it can be returned to the user. A word of caution: Base64 is an encoding method, not encryption.

Write in the last

The token-based authentication process is as follows:

  1. The client submits the request with the user’s login credentials (usually the user name and password)
  2. After receiving the login request, the server verifies the correctness of the credential. If the credential is correct, the server generates the token information according to the protocol, signs it, and returns it to the client
  3. After receiving the token information, the client can save it in a cookie or other place and carry the token information with each request
  4. After receiving the request, the service server verifies the token and goes to the next step if the token is correct

Again, whether token authentication, cookie authentication, or session authentication, once someone gets the client’s identity, they can still forge the operation. Therefore, when using any authentication mode, consider adding the source IP address or whitelist, expiration time, and use HTTPS when necessary.

More interesting articles

  • Distributed large concurrent series
  • Architectural Design Series
  • Series of interesting algorithms and data structures
  • Design Pattern series