Difference Token, Cookie and Session of

This article Go  http://blog.csdn.net/tobetheender/article/details/52485948

In doing interface testing, we often encounter the type of token request parameters, but most testers may distinguish between token, cookie, session is still little understood.

A cookie is a very specific thing, A data refers to the browser which can be permanently stored, is merely a data storage function of the browser implementation.

cookie generated by the server, sent to the browser, the browser cookie saved to a text file in a directory to kv form, will send a cookie to the server the next time you request the same site. Since the cookie exists on the client, the browser adds some restrictions to ensure the cookie will not be used maliciously, but will not take up too much disk space, so the number of cookie per domain is limited.

Session

Literally session is a session. This is similar to you and talk to a person, how do you know you talk to current and Joe Smith, not John Doe is it? There must be some other characteristics (appearance, etc.) that he is Joe Smith.

session is a similar reason, the current server you want to know who made the request to his yes. In order to make this distinction, going to a different server for each client is assigned "identity", and then sent to the server each time the client requests the time, are put on the "identity", the server knows that the request comes from who had. As for the client how to save this "identity" can have a variety of ways, for browser clients, we are using the default cookie manner.

The server uses the user's session information temporarily stored in the server, user session after leaving the site will be destroyed. This user information is stored relatively cookie is more secure, but the session has a flaw: If the web server to do load balancing, then the next operation request to another server when the session will be lost.

Token

The introduction of the Token: Token is frequently requested data to the server at the client, the server frequently to database queries the user name and password and compared to determine the user name and password are correct or not, and make the appropriate prompts, in this context, Token They have come into being.

Token Definition: Token is a server-generated string of string, as a token to the requesting client, when the first time you log in, the server generates a Token Token will return this to the client, the client only after Token need to bring this to come to request data without the need to bring the user name and password again. The simplest token consisting of: uid (user's unique identity), time (timestamp of the current time), sign (Signature by several former salt + hash algorithm to compress into a certain length of hexadecimal characters token string, a malicious third party can be prevented splicing request token server).

The purpose of using a Token: Token purpose is to relieve pressure on the server, reducing the frequent queries the database, the server more robust.

 

Traditional authentication

HTTP is a stateless protocol, that is, it does not know who is accessing the application. Here we put the user as a client, the client uses the user name as well as password authentication, but the next time the client sends a request again when then have to verify.

The solution is that when the user requests a login, if there is no problem, we generated a record on the server side, this record where you can explain who the user is about to log, and then send the ID number of records to put the client, after the client receives a Cookie, the service again next time the user sends a request to store the ID number, you can take the Cookie, so the server will verify the information in a Cookie this, see if you can in the service here ends the corresponding record is found, and if so, indicating the user has been authenticated, the user put the requested data is returned to the client.

Session is said above, we need to generate a user is logged on the server to store Session, the Session may be stored in memory, disk, or database. We may need to end the regular service to clear expired Session.

Token-based identity verification

Use the Token-based authentication methods, logon recorded in the server does not need to store the user. Probably the process is this:

  • The client uses the user login name with the password request
  • Server receives a request to verify the user name and password
  • After successful authentication, the server will issue a Token, then the Token is sent to the client
  • After receiving the client Token it can be stored, such as on the inside or Local Storage in Cookie
  • Every time a client requests a resource to the server needs with the server issued Token
  • Data server receives the request, and then to verify that the client requests inside with the Token, if authentication is successful, it is returned to the client's request

When APP log transmits the encrypted user name and password to the server, the server to authenticate the user name and password, if successful, in some way, such as a randomly generated 32-bit string as the token, is stored in the server, and returns the token to the APP, after APP when requested, those who need to verify where we must bring this token, then the server-side validation token, successfully returned the desired results, failure to return an error message, let him log in again. Wherein the server provided a valid token, each time APP authentication token and a request are valid.

So, my question here: token stored on the server 1 to the database, each query will not be very time-consuming. If not stored in the database, to where it should be stored. 2. Client sure to get the token stored encrypted, decrypted when sending token again. Stored in the database or configuration file it?

token is a volatile data, lost nothing more than allow users to log in again about Weibo frequently let me log back in, anyway, this thing I am does not matter.
So if you think that the general database table barely can put MSSQL / MySQL memory table (but is said to enhance memory table performance mysql limited), you can put Memcache in (say really, this is a very common strategy ), you can put redis years (I've done this to achieve), even variable dictionary can be put OpenResty's (as long as you have the confidence not burst memory).

token was a slip, but it is more gentle than the tickets, lost tickets to spend money again, lost his re-token authentication operation in a can, and therefore the cost of the lost token can be tolerated - provided that you do not lose too frequently, and if you allow users to authenticate once it bursts loss of user experience.

Based on this starting point, if you think to keep the token with a database query time is too long, it will become a bottleneck or risk your system, you can put the memory of them.
Such as memcached, redis, KV way it is suitable for your needs token query.
This is not too much memory, such as your token is a string of 32, if your subscribers in one million or ten million, that was how much memory.
If a large amount of data into a stand-alone memory really could not carry, or feel down all lost a big risk, as long as the token generation is sufficiently uniform, high and low cut at assigned on different machines on the line, the memory will not be a problem.

The client aspect of this unless you have a very safe way, such as privacy data storage operating system, it will certainly be problematic token leak. For example, I got your phone, put your token copy them, you can log in somewhere else before it expires to your identity.
A simple solution to this problem
1, when stored in the storage token symmetric encryption, use the time to unlock.
2, the request URL, timestamp, token merge the three salt signing, the server verification effectiveness.
The starting point of the two approaches are: steal your stored data more easily, and disassemble your program hack your signature and encryption and decryption algorithm is more difficult. But in fact that is difficult it is difficult, so a gentleman after all, is not anti-anti-villain practices. Saying stored encrypted if you are a client who clawed to see will not be stored in plain text ...... spray
method it get stored ciphertext untied, it does not know your method signature algorithm and salt, both of which can be combined consumption.
However, if the token was handcuffed man away, he naturally also be implanted into their cell phones, that when the time his cell phone can also be used with your identity, it will blind you.
So we can provide a user can make a similar initiative expire past token mechanism to remotely stop when stolen.

token transmitted in the clear over the network level, then will be very dangerous, so be sure to recommend the use of HTTPS, and the token on the post body inside.

 

supplement:

The difference between the cookie and session

1, cookie data is stored on the client, session data on the server.

2, cookie is not very safe, people can analyze stored locally COOKIE COOKIE cheat and
   take into account security should use the session.

3, session will be stored on the server within a certain period of time. When accessing the increase would be more take up the performance of your server
   take into account mitigating server performance, you should use COOKIE.

4, a single cookie stored data can not exceed 4K, many browsers are limited to a maximum of 20 sites saved cookie.

5, so personal recommendations:
   the login information and other important information is stored as SESSION
   additional information if necessary, it can be placed in COOKIE

 

The difference between the session and token

  oauth token session and not contradictory, as the authentication token security better than the session, because each request signature also prevents eavesdropping and replay attacks, and the session would have to rely on the link layer to protect the security of communications. As mentioned above, if you need to implement stateful session, you can still increase the session to save some of the state on the server side

  App usually dealing with a restful api with the server. Rest is stateless, that is not like the app browser as a cookie to store the session, hence the session token to mark themselves enough, session / state by the logic api server processing. If you are not stateless backend of rest api, then you may need to save the session in the app. Webkit can be embedded in the app, with a hidden browser to manage the cookie session.

  HTTP Session is a storage mechanism, mechanism for persistent object stateless HTTP provided. The so-called Session of the certification simply storing information to the User Session, because of the unpredictability of the SID, for the time being considered safe. This is a means of authentication. The Token, when it refers to OAuth Token or similar mechanism, then, is to provide authentication and authorization, certification is for the user, is authorized for App. Its purpose is to allow a right of access to information App a user. Token here is unique. Can not be transferred to another on the App, you can not go to the other users. Turn around and say Session. Session provides only one simple authentication, that this SID, that is considered to have all the rights of this User. Is the need for strict confidentiality of this data should only be stored in the station square, you should not be shared with other sites or third-party App. So simple, if your user data and may require a third-party share, or allow third parties to call API interface, with a Token. If you always just your own website, their own App, what it does not matter.

 

Break misconceptions:

"Just close your browser, session disappeared?"

wrong. For the session, unless the program notifies the server to delete a session, otherwise the server will remain, procedures are generally done in the user log off when issuing a command to delete session.

However, the browser will never take the initiative to inform the server to shut down before closing, so the server will not have the opportunity to know the browser has been closed, the reason why there is such an illusion, is that most session mechanisms use a session cookie to store the session id , and the browser is closed after this session id is gone, you can not find the original session when connecting to the server again. If the cookie HTTP server settings are saved on the hard disk, or use some means to rewrite the browser makes a request header, sending the original session id to the server, open the browser again still able to open the original session.

Precisely because closing the browser does not result in session is deleted, forcing the server to set up a time to failure for the session, when the session is first used on the client from time to time over this failure, the server can be that the client has ceased its activities, the session will be deleted to save storage space.

Guess you like

Origin www.cnblogs.com/ella-li/p/12008069.html