Token of web Security

Learn about Token-based authentication recently and share it with everyone. Many large web sites are also used, such as Facebook,twitter,google+,github, and so on, compared to traditional authentication methods, Token is more extensible and more secure, it is very suitable for use in WEB applications or mobile applications. Token of the Chinese people translated into a "token", I think very good, meaning that you take this token, to get through some levels.

traditional methods of authentication

HTTP is a stateless protocol, meaning that it does not know who is accessing the app. Here we regard the user as the client, the client uses the username and password to pass the authentication, but the next time the client sends the request again, it has to be verified again.

The solution is that when the user requests to log in, if there is no problem, we generate a record on the server, this record can explain the user who logged in, and then send this record ID number to the client, the client receives the ID number stored in the Cookie, The next time the user sends a request to the server, it can take this cookie so that the server verifies the information in the cookie to see if it can find the corresponding record on the server, and if so, indicates that the user has passed the authentication and returns the user's requested data to the client.

This is the session, we need to store the server as a login user generated session, these sessions may be stored in memory, disk, or database. We may need to periodically clean out the expired Session on the server side.

JWT

There are a lot of ways to implement Token validation, and there are some standard methods, such as JWT, read: Jot, which means: JSON Web Tokens. The JWT standard Token has three parts:

• Header
• Payload
• Signature

The middle is separated by dots and will be encoded using BASE64, so the real Token looks like this:

Eyjhbgcioijiuzi1niisinr5cci6ikpxvcj9. Eyjpc3mioijuaw5nagfvlm5ldcisimv4cci6ije0mzg5ntu0nduilcjuyw1lijoid2fuz2hhbyisimfkbwluijp0cnvlfq. SWYHTEX_RQPPR97G4J5LKXTABJECPEJUEF8AQKYMAJC 

Header

The header part is mainly two parts, one is the Token type, the other is the use of the algorithm, such as the following type is JWT, the algorithm used is HS256.

{  "JWT",  "HS256"} 

The above content is encoded in Base64 form, so it becomes this:

Eyjhbgcioijiuzi1niisinr5cci6ikpxvcj9

Payload

Payload inside is the specific content of tokens, some of which are standard fields, you can also add other required content. The following are the standard fields:

• Iss:issuer, issuer
• Sub:subject, Theme
• Aud:audience, the audience.
• Exp:expiration time, expiration
• Nbf:not before
• Iat:issued at, release time
• JTI:JWT ID

For example, the following Payload, with the ISS issuer, and exp expiry time. There are also two custom fields, one is name and the other is admin.

True

After using BASE64 encoding, it becomes this way:

Eyjpc3mioijuaw5nagfvlm5ldcisimv4cci6ije0mzg5ntu0nduilcjuyw1lijoid2fuz2hhbyisimfkbwluijp0cnvlfq

Signature

The last part of JWT is Signature, this part of the content has three parts, first with the BASE64 encoded header.payload, and then encrypted with encryption algorithm, when the encryption to put in a Secret, which is equivalent to a password, This password is stored secretly on the server.

• Header
• Payload
• Secret

' Secret ');

It looks like this after processing is done:

Swyhtex_rqppr97g4j5lkxtabjecpejuef8aqkymajc

The last Token generated on the server and sent to the client looks like this:

Eyjhbgcioijiuzi1niisinr5cci6ikpxvcj9. Eyjpc3mioijuaw5nagfvlm5ldcisimv4cci6ije0mzg5ntu0nduilcjuyw1lijoid2fuz2hhbyisimfkbwluijp0cnvlfq. SWYHTEX_RQPPR97G4J5LKXTABJECPEJUEF8AQKYMAJC 

The client receives the token and stores it later, and carries the token when it sends the request to the server. This Token is received by the server, which is then validated and returned to the client after the desired resource.

RELATED LINKS

• http://jwt.io/
• Https://github.com/firebase/php-jwt
• Https://scotch.io/tutorials/the-anatomy-of-a-json-web-token
• Https://github.com/auth0/jwt-decode

Reference: http://blog.csdn.net/sum_rain/article/details/37085771

Token, the most important feature of tokens, is randomness, unpredictable. General hackers or software can not guess out.

So, what does token do? What is the principle of it?

Tokens are generally used in two places:

• 1) Prevent duplicate submissions of forms,
• 2) Anti CSRF attack (cross-site request forgery).

Both are based on the principle of the session token to achieve. When the client requests the page, the server generates a random number token, puts the token into the session, and then sends the token to the client (typically by constructing the hidden form). The next time the client submits the request, token is submitted to the server side as a single table.
Then, if applied to the "anti CSRF attack", the server side validates the token value and determines if it is equal to the token value in the session, and if it is equal, it can prove that the request is valid, not forged.
However, if you apply the "Prevent form repeat commit", after the server side first authentication is the same, the token value in session will be updated, if the user repeats the submission, the second validation judgment will fail because the token in the user submitted form has not changed, But token has changed in the server-side session.

The above session application is relatively safe, but also called cumbersome, and when multi-page multi-request, must use multi-token simultaneous generation method, so that the use of more resources, execution efficiency will be reduced. Therefore, cookies can also be used to store authentication information in place of Session tokens. For example, when a "duplicate commit" is submitted, the information that has been submitted is written to the cookie after the first commit, and when the second commit, the second commit fails because the cookie already has a record of its submission.
However, Cookie storage has a fatal weakness, and if a cookie is hijacked (an XSS attack can easily get a user cookie), then again Gameover. Hackers will directly implement CSRF attacks.

So, safe and efficient relative. Specific questions to deal with it.

In addition, in order to avoid "token but do not check" situation, added token in the session, but the service side did not verify token, there is no preventive role.

Also note that the database has changed the addition and deletion of the operation, need to add token verification, for the query operation, must not add token, to prevent the attacker through the query operation to obtain tokens for CSRF attack. However, it is not possible for an attacker to gain token, only to increase the cost of the attack.

Token of web Security