A token is a special frame that controls the station's possession of the media, distinguishing data frames from other control frames. Token is actually more popular and can be called secret code. Before some data transmission, the secret code must be checked first. Different secret codes are authorized for different data operations. Below we will introduce the tutorial about Token-based authentication in detail. .
I recently learned about Token-based authentication and shared it with you. Many large websites are also using it, such as Facebook, Twitter, Google+, Github, etc. Compared with traditional authentication methods, Token is more scalable and more secure, which is very suitable for use in web applications or mobile applications. Token is translated into "token" in Chinese. I think it is very good. It means that you can pass some levels with this token.
Traditional Authentication Methods
HTTP is a stateless protocol, that is, it does not know who is accessing the application. Here we regard the user as a client. The client uses the username and password to pass the authentication, but the next time the client sends a request, it has to be verified again.
The solution is that when the user requests to log in, if there is no problem, we will generate a record on the server side. This record can indicate who the logged in user is, and then send the ID number of this record to the client. After receiving it, the client stores the ID number in the cookie. The next time the user sends a request to the server, he can take the cookie with him, so that the server will verify the information in the cookie to see if it can be used in the service. The client finds the corresponding record here. If yes, it means that the user has passed the authentication, and returns the data requested by the user to the client.
The above is the Session. We need to store the Session generated for the logged-in user on the server side. These Sessions may be stored in memory, disk, or database . We may need to periodically clean up expired sessions on the server side. (Of course, we can also use redis for corresponding logic verification)
Token-based authentication method
With the Token-based authentication method, there is no need to store the user's login record on the server. The approximate process is as follows:
The client uses the username and password to request to log
in to the server.
After receiving the request to verify the user name and password, the server will issue a Token, and then send the Token to the client.
After receiving the Token, the client can store it. For example, when it is placed in a cookie or in Local Storage, the
client needs to bring the Token issued by the
server to receive the request every time the client requests resources from the server, and then verifies the Token carried in the client request.
If successful, return the requested data JWT to the client
There are many ways to implement token verification, and there are some standard methods, such as JWT, pronounced: jot, which means: JSON Web Tokens. The JWT standard Token has three parts:
header
payload
signature
The middle is separated by a dot, and both use Base64 encoding, so the real Token looks like this:
eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJpc3MiOiJuaW5naGFvLm5ldCIsImV4cCI6IjE0Mzg5NTU0NDUiLCJuYW1lIjoid2FuZ2hhbyIsImFkbWluIjp0cnVlfQ.SwyHTEx_RQppr97g4J5lKXtabJecpejuef8AqKYMAJc
Header
The header part mainly consists of two parts, one is the type of Token, and the other is the algorithm used. For example, the following type is JWT, and the algorithm used is HS256.
{
"typ": "JWT",
"alg": "HS256"
}
The above content needs to be encoded in Base64, so it becomes like this:
eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9
Payload
Payload contains the specific content of the Token, some of which are standard fields, and you can also add other required content. The following are standard fields:
iss: Issuer, issuer
sub: Subject, subject
aud: Audience, audience
exp: Expiration time, expiration time
nbf: Not before
iat: Issued at, issue time
jti: JWT ID For
example, the following payload uses iss issuer and also There is an exp expiration time. There are also two custom fields, one is name, and the other is admin.
{
"iss": "ninghao.net",
"exp": "1438955445",
"name": "wanghao",
"admin": true
}
After using Base64 encoding, it becomes like this:
eyJpc3MiOiJuaW5naGFvLm5ldCIsImV4cCI6IjE0Mzg5NTU0NDUiLCJuYW1lIjoid2FuZ2hhbyIsImFkbWluIjp0cnVlfQ
Signature
The last part of the JWT is the Signature, which has three parts. First, the header.payload encoded with Base64, and then encrypted with an encryption algorithm. When encrypting, a Secret should be put in, which is equivalent to a password, which is stored secretly. on the server side.
header
payload
secret
var encodedString = base64UrlEncode(header) + "." + base64UrlEncode(payload); HMACSHA256(encodedString, 'secret');
After processing it looks like this:
SwyHTEx_RQppr97g4J5lKXtabJecpejuef8AqKYMAJc
The final token that is generated on the server and sent to the client looks like this:
eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJpc3MiOiJuaW5naGFvLm5ldCIsImV4cCI6IjE0Mzg5NTU0NDUiLCJuYW1lIjoid2FuZ2hhbyIsImFkbWluIjp0cnVlfQ.SwyHTEx_RQppr97g4J5lKXtabJecpejuef8AqKYMAJc
After the client receives this Token, it stores it, and it will carry this Token when it sends a request to the server next time. The server receives the Token, then verifies it, and returns to the resource that the client wants after passing.