Home >
Article > Are you still confused about Cookie, Session, Token, and JWT?
Are you still confused about Cookie, Session, Token, and JWT?
coldplay.xixiforward
2020-08-19 12:01:295777browse
What is Authentication
In layman terms, it meansVerify the identity of the current user, proving that "you are yourself" (For example: when you clock in and out every day, you need to clock in with your fingerprint. When your fingerprint matches the fingerprint entered in the system, you will clock in successfully)
Authentication in the Internet:
Login with username and password
Send login link via email
Receive verification code via mobile number
As long as you can receive the email/verification code, you will be the owner of the account by default
What is Authorization
The user grants third-party applications permission to access certain resources of the user
When you install the mobile application, the APP will ask whether to grant permissions (access to photo albums, geographical location, etc.)
When you access the WeChat applet, when logging in, the applet will ask whether Allow permission to be granted (obtain personal information such as nickname, avatar, region, gender, etc.)
The ways to achieve authorization are: cookie, session, token, OAuth
What are Credentials
The prerequisite for achieving authentication and authorization is that a media (certificate) is needed to mark the identity of the visitor
During the Warring States Period, Shang Yang carried out his reform and invented the photo-taking post. The photo sticker is issued by the government and is a smooth and finely polished bamboo board with the holder's profile picture and place of birth engraved on it. Chinese people must have it. If they don't have it, they are considered to be undercover, or spies.
In real life, everyone will have an exclusive resident ID card, which is a legal document used to prove the identity of the holder. Through the ID card, we can apply for mobile phone cards/bank cards/personal loans/transportation, etc. This is the certificate of certification.
In Internet applications, general websites (such as Nuggets) have two modes, guest mode and login mode. In guest mode, you can browse the articles on the website normally. Once you want to like/collect/share articles, you need to log in or register an account. When the user logs in successfully, the server will issue a token to the browser used by the user. This token is used to indicate your identity. Each time the browser sends a request, it will bring this token with you and you can use it. Features not available in guest mode.
What is Cookie
HTTP is a stateless protocol (no memory for transaction processing, each time the client and service When the client session is completed, the server will not save any session information): Each request is completely independent. The server cannot confirm the identity information of the current visitor, and cannot distinguish the sender of the last request from this one. Is the sender the same person? Therefore, in order to track sessions (know who is visiting me), the server and browser must actively maintain a state. This state is used to inform the server whether the two requests before and after are from the same browser. This state needs to be achieved through cookies or sessions.
Cookie is stored on the client: A cookie is a small piece of data sent by the server to the user's browser and saved locally. It will be used the next time the browser makes a request to the same server. is carried and sent to the server.
Cookies are not cross-domain: Each cookie will be bound to a single domain name and cannot be obtained and used under other domain names. Between the first-level domain name and the second-level domain name It is that allows shared use ( depends on domain).
Cookie important properties
Attribute
Description
##name=value
Key-value pair, the name of the cookie and the corresponding value must be
String type- If the value is a Unicode character, the character encoding is required. - If the value is binary data, BASE64 encoding is required.
domain
Specify the domain name to which the cookie belongs. The default is the current domain name
path
Specifies the path (routing) under which the cookie will take effect. The default is '/'. If set to /abc, only routes under /abc can access the cookie, such as: /abc/read.
maxAge
The cookie expiration time, in seconds. If an integer, the cookie expires after maxAge seconds. If it is a negative number, the cookie is a temporary cookie and will expire when you close the browser, and the browser will not save the cookie in any form. If 0, delete the cookie. Default is -1.
- Easier to use than expires.
expires
Expiration time, the cookie will expire after a certain point in time.
General browser cookies are stored by default. When the browser is closed and the session is ended, the cookie will be deleted
secure
Whether this cookie is only transmitted using secure protocols. Security protocols include HTTPS, SSL, etc., which encrypt data before transmitting it on the network. The default is false.
When the secure value is true, the cookie is invalid in HTTP and only valid in HTTPS.
httpOnly
If the httpOnly attribute is set for a cookie, the cookie information cannot be read through JS script , but you can still modify the cookie manually through Application, so it can only prevent XSS attacks to a certain extent, but it is not absolutely safe
session is another The mechanism for recording the session status of the server and client
session is implemented based on cookies. The session is stored on the server side, and the sessionId will be stored in the client's cookie
session authentication process:
When the user requests the server for the first time, the server will Create the corresponding Session
Return the unique identification information of this Session, SessionID, to the browser when the request returns
After the browser receives the SessionID information returned by the server, it will store this information in Cookie , and the cookie records which domain name this SessionID belongs to
When the user accesses the server for the second time, the request will automatically determine whether there is cookie information under this domain name. If there is, the cookie information will also be automatically sent to the server. The server will obtain the SessionID from the Cookie, and then search for the corresponding Session information based on the SessionID. If it is not found, it means that the user is not logged in or the login is invalid. If the Session is found, it proves that the user has logged in and can perform the following operations.
According to the above process, SessionID is a bridge connecting Cookie and Session. Most systems also use this principle to verify user login status.
Security: Session is more secure than Cookie. Session is stored on the server side, and Cookie is stored on the client side.
Different types of access values: Cookie only supports storing string data. If you want to set other types of data, you need to convert it into a string. Session can store any data type.
Different validity periods: Cookies can be set to be maintained for a long time, such as the default login function we often use, Session generally has a short expiration time, the client is closed (by default) or the Session times out All will fail.
Different storage sizes: The data saved by a single Cookie cannot exceed 4K. Session can store much more data than Cookie, but when there are too many visits, it will occupy too many server resources.
What is Token
Acesss Token
##The resource credentials required to access the resource interface (API)
The composition of a simple token: uid (user’s unique identity), time (time stamp of the current time), sign (signature, the first few digits of the token are compressed with a hash algorithm) A hexadecimal string of a certain length)
Features:
The server is stateless and has good scalability
Support mobile devices
Security
Support cross-program call
token authentication Process:
The client uses the user name and password to request login
The server receives the request and verifies the user Name and password
After successful verification, the server will issue a token and send the token to the client
After the client receives the token, it will store it, such as in a cookie In or in localStorage
Every time the client requests resources from the server, it needs to bring the token issued by the server
The server receives the request, and then verifies that the client request contains token, if the verification is successful, the requested data will be returned to the client
Every request needs to carry the token, and the token needs to be placed in the HTTP Header
Token-based user authentication is a server-side stateless authentication method, and the server does not need to store token data. The calculation time of parsing the token is exchanged for the storage space of the session, thereby reducing the pressure on the server and reducing frequent queries to the database
The token is completely managed by the application, so it can avoid the same-origin policy
Refresh Token
Another kind of token——refresh token
refresh token is a token specifically used to refresh access tokens. If there is no refresh token, you can also refresh the access token, but each refresh requires the user to enter the login user name and password, which will be very troublesome. With the refresh token, this trouble can be reduced. The client directly uses the refresh token to update the access token without requiring the user to perform additional operations.
The validity period of Access Token is relatively short. When Access Token becomes invalid due to expiration, you can use Refresh Token to obtain it. New Token, if the Refresh Token also expires, the user can only log in again.
Refresh Token and expiration time are stored in the server database and will only be verified when applying for a new Access Token. It will not affect the response time of the business interface and does not need to be kept in the same state as the Session. in memory to handle a large number of requests.
The difference between Token and Session
Session is a mechanism to record the session status of the server and client, making the server stateful and able to record the session information. And Token is Token, The resource credential required to access the resource interface (API). Token makes the server stateless and does not store session information.
Session and Token are not contradictory. As an identity authentication Token, the security is better than Session, because each request is signed and can prevent monitoring and replay attacks, while Session must rely on the link layer. to ensure communication security. If you need to implement a stateful session, you can still add Session to save some state on the server side.
The so-called Session authentication simply stores User information in the Session. Because of the unpredictability of the SessionID, it is considered safe for the time being. And Token, if it refers to OAuth Token or a similar mechanism, provides authentication and authorization. Authentication is for users, and authorization is for App. The purpose is to give an app the right to access a user's information. The Token here is unique. It cannot be transferred to other apps or to other users. Session only provides a simple authentication, that is, as long as there is this SessionID, it is considered that this User has all the rights. It needs to be kept strictly confidential. This data should only be stored on the site and should not be shared with other websites or third-party apps. So to put it simply: If your user data may need to be shared with a third party, or allow a third party to call the API interface, use Token. If it is always just your own website and your own App, it doesn’t matter what you use.
What is JWT
JSON Web Token (JWT for short) is currently the most popular cross-domain authentication solution.
is a authentication and authorization mechanism.
JWT is a JSON-based open standard (RFC 7519) implemented to transfer statements between network application environments. JWT claims are generally used to pass authenticated user identity information between identity providers and service providers in order to obtain resources from resource servers. For example, used for user login.
You can use the HMAC algorithm or the RSA public/private key to sign JWT. Because of the existence of digital signatures, the transmitted information is credible.
Teacher Ruan Yifeng’s introductory tutorial on JSON Web Token is very easy to understand, so I won’t go over the details here
Generate JWT
jwt.io/ www.jsonwebtoken.io/
Principle of JWT
JWT authentication process:
User enters username/password to log in, server After successful authentication, a JWT will be returned to the client
The client saves the token locally (usually localstorage is used, but cookies can also be used)
When the user wants to access a protected route or When requesting resources, you need to use the Bearer mode to add JWT in the Authorization field of the request header. Its content looks like the following
Authorization: Bearer <token>复制代码</token>
The server-side protected routing will be checked The JWT information in the request header Authorization, if legal, allows the user's behavior
Because JWT is self-contained (it contains some session information), it reduces the need to query the database
Because JWT does not use cookies, you can use any domain name to provide your API services without worrying about cross-domain resource sharing (CORS)
Because the user's status is no longer stored in the server's memory , so this is a stateless authentication mechanism
How to use JWT
The client receives the JWT returned by the server, which can be stored in Cookie or Stored in localStorage.
When a user wants to access a protected route or resource, they can put it in a cookie and send it automatically. However, this cannot cross domains, so a better approach is to put it in the HTTP request header. In the Authorization field of the message, add the JWT using Bearer mode.
GET /calendar/v1/events
Host: api.example.com
Authorization: Bearer <token>复制代码</token>
The user's status will not be stored in the server's memory. This is a stateless authentication mechanism
The server's protection route will be checked The JWT information in the Authorization request header, if legal, allows the user's behavior.
Because JWT is self-contained, it reduces the need to query the database
These features of JWT allow us to rely entirely on its stateless features to provide data API services, or even create a Download streaming services.
Because JWT does not use cookies, you can use any domain name to provide your API services without needing to worry about cross-domain resource sharing (CORS)
Method 2
When crossing domains, you can put the JWT in the data body of the POST request.
Method 3
Transfer through URL
http://www.example.com/user?token=xxx复制代码
Use JWT in the project
Project address
The difference between Token and JWT
is the same:
They are both tokens for accessing resources
Both can record user information
Both make the server stateless
Both can only access protected resources on the server after successful verification
the difference:
Token: When the server verifies the Token sent by the client, it also needs to query the database to obtain user information, and then verify whether the Token is valid.
JWT: The Token and Payload are encrypted and stored on the client. The server only needs to use key decryption for verification (verification is also implemented by JWT itself). There is no need to query or reduce the query database. Because JWT contains user information and encrypted data.
Common front-end and back-end authentication methods
Session-Cookie
Token verification (including JWT, SSO)
OAuth2.0 (open authorization)
Common Encryption algorithm
Hash Algorithm, also known as hash algorithm, hash function, hash function, is a method that extracts data from any kind of data. A way to create small digital "fingerprints". Hash algorithms re-shuffle the data to create a new hash value.
The hash algorithm is mainly used to ensure data authenticity (ie integrity), that is, the sender sends the original message and the hash value together, and the recipient uses the same hash function to verify whether the original data is authentic. .
Hash algorithms usually have the following characteristics:
Fast: the original data can quickly calculate the hash value
Reverse difficulty: it is basically difficult to pass the hash value It is possible to deduce the original data
Input sensitivity: As long as the original data changes a little, the hash value obtained is very different
Conflict avoidance: It is difficult to find different original data to get the same hash Value, the number of atoms in the universe is approximately between 10 to the 60th power and 80th power, so 2 to the 256th power has enough space to accommodate all possibilities. If the algorithm is good, the probability of collision is very low:
The 128th power of
2 is 340282366920938463463374607431768211456, which is 10 to the 39th power level. The 160th power of
2 is 1.4615016373309029182036848327163e 48, which is 10 of 48. Power level
2 The 256th power is 1.1579208923731619542357098500869 × 10 to the 77th power, which is 10 to the 77th power
## The above does not guarantee that the data will be malicious Tampering, both the original data and the hash value may be maliciously tampered with. To ensure that they are not tampered with, you can use the RSA public key and private key scheme, combined with the hash value.
The hash algorithm is mainly used to prevent errors during computer transmission. Early computers used the first 7 bits of data and the 8th bit parity check code to protect it (12.5% waste efficiency is low). For a piece of data or file , generate a 128-bit or 256-bit hash value through a hash algorithm. If there is a problem with the verification, retransmission is required.
FAQIssues to consider when using cookies
Because it is stored on the client, it is easily tampered with by the client, and it needs to be verified before use. Sex
Do not store sensitive data, such as user passwords and account balances
Use httpOnly to improve security to a certain extent
Minimize the size of cookies and the amount of data that can be stored Cannot exceed 4kb
Set the correct domain and path to reduce data transmission
Cookies cannot cross domains
A browser can store up to 20 cookies for one website Cookies, browsers generally only allow 300 cookies to be stored
The mobile terminal does not support cookies very well, and the session needs to be implemented based on cookies, so the mobile terminal commonly uses token
Issues to consider when using sessions
Store sessions in the server. When a large number of users are online at the same time, these sessions will occupy more memory and need to be used in the service The client regularly cleans up expired sessions
When the website adopts
cluster deployment, you will encounter the problem of how to share sessions between multiple web servers. Because the session is created by a single server, but the server that handles user requests is not necessarily the server that created the session, then the server cannot get information such as login credentials that have been put into the session before.
When multiple applications want to share sessions, in addition to the above problems, they will also encounter cross-domain problems, because different applications may deploy different hosts, and each application needs to handle cross-domain cookies.
sessionId is stored in a cookie. What if the browser prohibits cookies or does not support cookies? Generally, the sessionId will be followed by the url parameter to rewrite the url, so the session does not necessarily need to be implemented by cookies.
The mobile terminal does not support cookies very well, and the session needs to be based on cookies. Implementation, so tokens are commonly used on mobile terminals
Issues to consider when using tokens
If you think that using a database to store tokens will cause the query time to be too long long, you can choose to put it in the memory. For example, redis is very suitable for your token query needs.
Token is completely managed by the application, so it can avoid the same-origin policy
Token can avoid CSRF attacks (because no cookies are needed)
The mobile terminal does not support cookies very well, and session needs to be implemented based on cookies, so the mobile terminal commonly uses token
You need to consider this when using JWT The problem
Because JWT does not rely on cookies, you can use any domain name to provide your API services without worrying about cross-domain resource sharing issues (CORS)
JWT default It is not encrypted, but it can be encrypted. After generating the original Token, it can be encrypted again with the key.
JWT Secret data cannot be written to a JWT without encryption.
JWT can be used not only for authentication, but also for exchanging information. Effective use of JWT can reduce the number of times the server queries the database.
The biggest advantage of JWT is that the server no longer needs to store Session, so that the server authentication and authentication business can be easily expanded. But this is also the biggest disadvantage of JWT: since the server does not need to store the Session state, it cannot discard a Token or change the Token's permissions during use. That is to say, once a JWT is issued, it will always be valid until it expires, unless the server deploys additional logic.
The JWT itself contains authentication information. Once leaked, anyone can obtain all permissions of the token. In order to reduce theft, the validity period of JWT should be set relatively short. For some more important permissions, users should be authenticated again when using them.
JWT is suitable for one-time command authentication. A JWT with a very short validity period is issued. Even if the risk is exposed, the risk is very small. Since each operation will generate a new JWT, there is no need to save the JWT. It is truly seamless. state.
In order to reduce theft, JWT should not be transmitted in plain code using HTTP protocol, but should be transmitted using HTTPS protocol.
Issues to consider when using encryption algorithms
Never store in clear textPassword
Always use ha Use the hash algorithm to process passwords. Never use Base64 or other encoding methods to store passwords. This is the same as storing passwords in clear text. Use hashes instead of encoding . Encoding and encryption are both two-way processes, while the password is confidential and should only be known by its owner. This process must be one-way. Hashing is used to do this. There is never such a thing as decoding a hash, but there is decoding when there is encoding, and there is decryption when there is encryption.
Never use weak or compromised hashing algorithms like MD5 or SHA1, only use strong password hashing algorithms.
Never display or send a password in clear text, even to the owner of the password. If you need the "forgot password" feature, you can randomly generate a new one-time (this is very important) password, and then send this password to the user.
Session sharing scheme under distributed architecture
1. Session replication
If the session on any server changes (addition, deletion or modification), the node All contents of this session will be serialized and then broadcast to all other nodes, regardless of whether other servers need the session, to ensure session synchronization
Advantages: Fault-tolerant , sessions between various servers can respond in real time. Disadvantages: It will put a certain pressure on the network load. If the number of sessions is large, it may cause network congestion and slow down server performance.
2. Sticky session/IP binding strategy
Uses the ip_hash mechanism in Ngnix to direct all requests for a certain IP to the same server. The user is bound to the server. When the user requests for the first time, the load balancer forwards the user's request to server A. If the load balancer sets a sticky session, then every subsequent request of the user will be forwarded to server A, which is equivalent to forwarding the user's request to server A. The user and server A are stuck together. This is the sticky session mechanism.
Advantages: Simple, no need to do any processing on the session. Disadvantages: Lack of fault tolerance. If the currently accessed server fails and the user is transferred to the second server, his session information will be invalid. Applicable scenarios: Failure has a small impact on customers; server failure is a low-probability event
. Implementation method: Taking Nginx as an example, sticky session can be achieved by configuring the ip_hash attribute in the upstream module.
3. Session sharing (commonly used)
Use distributed caching solutions such as Memcached and Redis to cache the session, but Memcached or Redis must be a cluster
Put the session in Storage in Redis, although the architecture becomes complex and requires one more access to Redis, the benefits brought by this solution are also great:
realizes session sharing;
can be used horizontally Extension (adding Redis server);
The session will not be lost when the server is restarted (but please also pay attention to the session refresh/invalidation mechanism in Redis);
Not only can it be shared across server sessions, it can even be shared across Platform (such as web page and APP)
#4. Session persistence
Storage session to the database to ensure the persistence of the session
Advantages: If there is a problem with the server, the session will not be lost Disadvantages: If the number of visits to the website Very large. Storing sessions in the database will put a lot of pressure on the database, and additional overhead will be required to maintain the database.
As long as you close the browser, will the session really disappear?
wrong. For sessions, unless the program notifies the server to delete a session, the server will keep it. The program usually sends an instruction to delete the session when the user logs off. However, the browser never actively notifies the server that it is about to close before closing, so the server has no chance to know that the browser has been closed. The reason for this illusion is that most session mechanisms use session cookies. The session id is saved, and the session id disappears after closing the browser, and the original session cannot be found when connecting to the server again. If the cookie set by the server is saved on the hard disk, or some method is used to rewrite the HTTP request header sent by the browser and send the original session id to the server, the original session can still be opened when the browser is opened again. Exactly Since closing the browser will not cause the session to be deleted, forcing the server to set an expiration time for the session. When the time since the client last used the session exceeds this expiration time, the server will consider the client The session will be deleted only after the activity has stopped to save storage space.
Project address
Using JWT in the project
Postscript
This article is only based on my own I understand that I talked about theoretical knowledge, because I am not very familiar with back-end/algorithm knowledge. If there are any fallacies, please let me know. Thank you very much
If this article is helpful to you, please give it a like~~
