What is Authentication?

  • In layman’s terms, it means to verify the current user’s identity and prove that “you are yourself” (for example, when you clock in and out every day, you need to clock in with your fingerprint, and when your fingerprint matches the fingerprint entered in the system, you clock in successfully).
  • Authentication on the Internet:
    • User name and password for login
    • Email sends the login link
    • Mobile phone number Receiving verification code
    • As long as you receive the email/verification code, you are the account owner by default

What is Authorization?

  • A user grants third-party applications the permission to access certain resources of the user
    • When you install an APP on your phone, the APP asks you if you can grant permissions (access to albums, geolocation, etc.)
    • When you access the wechat mini program, when you log in, the mini program will ask whether you are allowed to grant permissions (to obtain personal information such as nickname, avatar, region and gender).
  • The authorization modes are cookie, session, Token, and OAuth

What are Credentials?

  • The premise of authentication and authorization is the need for a medium (certificate) to mark the identity of the visitor
    • During the Warring States Period (475-221 BC), Shang Yang invented the Post. The photo stickers, issued by the government, are a finely polished piece of bamboo engraved with the owner’s head and hometown information. They have to have it. If they don’t have it, they’re considered unregistered, or a spy or something.
    • In real life, everyone will have their own resident identity card, which is a legal document used to prove the identity of the holder. Through the ID card, we can handle mobile card/bank card/personal loan/transportation and so on, which is the certificate of authentication.
    • In Internet applications, general websites (such as nuggets) will have two modes, tourist mode and login mode. In tourist mode, you can browse articles on the website normally. Once you want to like/favorite/share an article, you need to log in or register an account. When the user logs in successfully, the server issues a token to the browser that the user is using. This token identifies you. Every time the browser sends a request, it carries this token and can use functions that are not available in tourist mode.

What is a Cookie

  • HTTP is a stateless protocol (for the transaction without memory, each time the client and the server session is complete, the server will not save any session information) : each request is completely independent, the server can’t confirm the identity of visitors to the current information, unable to distinguish between the last request of the sender and the sender is not the same person at this time. So in order for the server and browser to do session tracking (to know who is visiting me), they must actively maintain a state that tells the server whether the previous two requests came from the same browser. This state needs to be implemented through cookies or sessions.
  • Cookie stored on the client: A cookie is a small piece of data that the server sends to the user’s browser and keeps locally. It is carried and sent to the server the next time the browser makes a request to the same server.
  • Cookies are not cross-domain: each cookie is bound to a single domain name and cannot be used under other domain names. First-level domain names and second-level domain names are allowed to be shared (depending on domain).

Cookie Important properties

What is a Session

  • Session is another mechanism for recording the state of the session between the server and client
  • The session is implemented based on cookies. The session is stored on the server, and the sessionId is stored in the cookie of the client

  • Session authentication process:
    • When a user requests the server for the first time, the server creates a Session based on the information submitted by the user
    • The Session id is returned to the browser when the request is returned
    • After receiving the SessionID information from the server, the browser stores the information in the Cookie, and the Cookie records the domain name of the SessionID
    • When the user accesses the server for the second time, the request will automatically determine whether there is Cookie information under the domain name. If there is Cookie information, the server will automatically send the Cookie information to the server, and the server will obtain the SessionID from the Cookie. If the Session id is not found, the user is not logged in or the login is invalid. If the Session id is found, the user is logged in and you can perform the following operations.

According to the above process, SessionID is a bridge between Cookie and Session, and most systems also verify user login status based on this principle.

The difference between cookies and sessions

  • Security: The Session is more secure than the Cookie. The Session is stored on the server and the Cookie is stored on the client.
  • The value types are different: Cookies only support string data. If you want to set other types of data, you need to convert them into strings. Session can store any data type.
  • Different validity periods: Cookies can be set to hold for a long time. For example, the default login function that we often use, the Session usually expires for a short time, and the client shuts down (by default) or the Session times out will be invalid.
  • Different storage sizes: The data stored by a single Cookie cannot exceed 4K, and the data stored by a Session is much higher than that stored by cookies. However, if there are too many visits, too many server resources will be occupied.

What is a Token?

Acesss Token

  • Resource credentials needed to access a resource interface (API)
  • Simple token composition: UID (unique user identification), time(timestamp of the current time), sign (signature, the first few digits of the token are hashed into a certain length of hexadecimal string)
  • Features:
    • Stateless server and good scalability
    • Supports mobile devices
    • security
    • Support for cross-program calls
  • Token authentication process:

  1. The client requests login using the username and password
  2. The server receives a request to verify the user name and password
  3. After the authentication succeeds, the server issues a token and sends the token to the client
  4. After receiving the token, the client stores it, for example, in a cookie or localStorage
  5. Each time a client requests resources from the server, it must carry a token signed by the server
  6. The server receives the request and verifies the token in the request. If the verification succeeds, it returns the requested data to the client
  • Each request needs to carry the token, which needs to be put in the HTTP Header
  • Token-based user authentication is a stateless authentication mode on the server. The server does not need to store token data. The computation time of token parsing is used to exchange the storage space of session, thus reducing the pressure on the server and reducing the frequent query of the database
  • The token is completely managed by the application, so it can bypass the same-origin policy

Refresh Token

  • Refresh Token is another kind of token
  • Refresh Token Is a token dedicated to refreshing access tokens. If you do not have refresh token, you can refresh the Access token, but each refresh requires the user to enter the login user name and password, which can be troublesome. With the refresh token, this hassle can be reduced. The client directly uses the Refresh token to update the Access token without additional operations by the user.

  • The Access Token has a short validity period. When the Acesss Token becomes invalid, the user can obtain a new Token by using the Refresh Token. If the Refresh Token also becomes invalid, the user can only log in again.
  • The Refresh Token and expiration time are stored in the server database and verified only when a new Acesss Token is applied for. It does not affect the service interface response time and does not need to be kept in memory to handle a large number of requests like the Session.

The difference between Token and Session

  • Session is a mechanism for recording the Session status between the server and the client. The server is stateful and can record Session information. Tokens are tokens, resource credentials needed to access resource interfaces (apis). Token makes the server stateless and does not store session information.
  • Session and Token are not contradictory. As an authentication Token, Session security is better than Session security, because each request has a signature and can prevent listening and replay attacks, while Session must rely on the link layer to ensure communication security. If you need to implement stateful sessions, you can still add sessions to store some state on the server side.
  • Session authentication is simply storing User information in the Session. Because of the unpredictability of the SessionID, it is considered safe for the time being. Tokens, if referred to as OAuth tokens or similar mechanisms, provide authentication and authorization, authentication for the user and authorization for the App. The goal is to give an App access to a user’s information. The Token here is unique. It cannot be transferred to other apps, nor can it be transferred to other users. Session provides only a simple authentication, that is, as long as the SessionID is present, the User is considered to have full rights. This data should only be kept 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 an API, use Token. If it’s always just your own website, your own App, it doesn’t matter what you use.

What is the JWT

  • JSON Web Token (JWT) is currently the most popular cross-domain authentication solution.
  • It is an authentication and authorization mechanism.
  • JWT is an open jSON-based standard (RFC 7519) implemented for passing declarations between network application environments. JWT declarations are typically used to pass authenticated user identity information between the identity provider and the service provider to facilitate resource retrieval from the resource server. For example, for user login.
  • JWT can be signed using either the HMAC algorithm or RSA’s public/private key. These messages are trusted because of digital signatures.

Generate JWT

  • jwt.io/
  • www.jsonwebtoken.io/\

The principle of JWT

  • JWT certification process:
    • After a user enters the user name and password to log in, the server returns a JWT to the client after successful authentication
    • The client saves the token locally (usually using localstorage, but can also use cookies)
    • When a user wishes to access a protected route or resource, the JWT is added using a Bearer mode in the Authorization field of the request header, which looks like this
Authorization: Bearer <token>
Copy the code
  • The protected route on the server side will check the JWT information in the request header Authorization and, if valid, allow the user’s behavior
  • Because JWT is self-contained (internally containing some session information), it reduces the need to query the database
  • Since 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 state is no longer stored in server memory, this is a stateless authentication mechanism

How JWT is used

  • The client receives the JWT returned by the server, which can be stored in cookies or localStorage.

Methods a

  • When users wish to access a protected route or resource, they can automatically send it in a Cookie, but this is not cross-domain, so it is better to place it in the Authorization field of HTTP request headers and add JWT in Bearer mode.

    GET /calendar/v1/events
Host: api.example.com
Authorization:Bearer 
        
Copy the code
    • The user’s state is not stored in server memory, which is a stateless authentication mechanism
    • The protected route on the server side will check the JWT information in the request header Authorization and, if valid, allow 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 nature to provide data API services and even create a download stream service.
    • Since JWT does not use cookies, you can use any domain name to provide your API services without worrying about cross-domain resource sharing (CORS).

Way 2

  • When cross-domain, JWT can be placed in the data body of the POST request.

Methods three

  • Transfer by URL
http://www.example.com/user?token=xxx
Copy the code

Difference between Token and JWT

The same:

  • Are tokens to access resources
  • Can record user information
  • Both make the server stateless
  • The client can access the protected resources on the server only after the authentication is successful

The difference between:

  • Token: When authenticating the Token sent from the client, the server also needs to query the database to obtain user information and verify whether the Token is valid
  • JWT: encrypts the Token and Payload and stores them on the client. The server only needs to use key decryption for verification (which is also implemented by the JWT itself). The JWT does not need to query or reduce the query database, because the JWT contains user information and encrypted data.

Common front – end authentication modes

  1. Session-Cookie
  2. Token verification (including JWT, SSO)
  3. OAuth2.0 (Open Authorization)

Common encryption algorithms

  • A Hash Algorithm, also known as a Hash Algorithm, Hash function, or Hash function, is a method of creating small digital “fingerprints” from any kind of data. The hash algorithm remixes the data and recreates a hash.
  • Hash algorithm is mainly used to ensure data authenticity (integrity), that is, the sender sends the original message and hash value together, and the recipient verifies the authenticity of the original data through the same hash function.
  • Hash algorithms usually have the following characteristics:
    • 2 power of 128 to 340282366920938463463374607431768211456, that is, 10 39 power levels
    • 2 160 1.4615016373309029182036848327163 e+48, namely 10 48 power levels
    • 2 256 77 of 1.1579208923731619542357098500869 x 10 square, also is 10 to the 77 joules
    • Just as fast: Raw data can be quickly hashed
    • Reverse difficulty: It is almost impossible to derive the original data from hashes
    • Input sensitivity: Hash values can vary greatly if the original data is changed even a little
    • Collision avoidance: It is very difficult to find different raw data to get the same hash value, the number of atoms in the universe is about 10 to the power of 60 to the power of 80, so 2 to the power of 256 has enough space to accommodate all possibilities, and the probability of collisions is low with good algorithms:

Note:

  1. Both original data and hash values may be maliciously tampered. To prevent tampering, you can use the RSA public and private key scheme and hash values.
  2. Hash algorithm is mainly used to prevent errors in the process of computer transmission. Early computers use parity check code of the first 7 bits of data (low waste efficiency of 12.5%). For a piece of data or file, hash algorithm generates hash value of 128bit or 256bit.

Q&A

Considerations when using cookies

  • Because the storage is stored on the client, it is easy to be tampered with by the client. Therefore, you need to verify the validity before using the storage
  • Don’t store sensitive data, such as user passwords and account balances
  • Using httpOnly improves security to some extent
  • Minimize the size of cookies. The amount of data that can be stored cannot exceed 4KB
  • Set the domain and path correctly to reduce data transfer
  • Cookies cannot cross domains
  • A browser can store a maximum of 20 cookies for a website, and a browser is generally allowed to store only 300 cookies
  • The mobile terminal does not support cookies very well, and the session needs to be implemented based on cookies, so the mobile terminal is commonly used by token

Issues to consider when using sessions

  • Sessions are stored on the server. When a large number of users are online at the same time, these sessions occupy a large amount of memory. You need to periodically clear expired sessions on the server
  • When a website is deployed in a cluster, session sharing among multiple Web servers is a problem. Because sessions are created by a single server, but the server that handles user requests is not necessarily the same server that created the session, that server cannot retrieve information such as login credentials that was previously put into the session.
  • When multiple applications want to share sessions, in addition to the above problems, cross-domain problems may also occur. Because different applications may deploy different hosts, cross-domain cookie processing needs to be done in each application.
  • Sessionids are stored in cookies. What if the browser disables cookies or does not support cookies? The sessionId is usually written after the URL argument, so the session doesn’t have to rely on cookies
  • The mobile terminal does not support cookies very well, and the session needs to be implemented based on cookies, so the mobile terminal is commonly used by token

Considerations when using tokens

  • If you think that using a database to store tokens will take too long to query, you can choose to store them in memory. For example, Redis is a good fit for your token query needs.
  • The token is completely managed by the application, so it can bypass the same-origin policy
  • Tokens can avoid CSRF attacks (because cookies are no longer needed)
  • The mobile terminal does not support cookies very well, and the session needs to be implemented based on cookies, so the mobile terminal is commonly used by token

Considerations when using JWT

  • Since JWT does not rely on cookies, you can use any domain name to provide your API services without worrying about cross-domain resource sharing (CORS).
  • JWT is not encrypted by default, but it can be encrypted. Once the original Token is generated, it can be encrypted again with the key.
  • Secret data cannot be written to the JWT without encryption.
  • JWT can be used not only for authentication, but also for information exchange. Using JWT effectively can reduce the number of times the server queries the database.
  • The biggest advantage of JWT is that servers do not need to store sessions, which facilitates the expansion of server authentication and authentication services. However, this is the biggest drawback of JWT: since the server does not need to store Session state, there is no way to discard a Token or change its permissions during use. That is, once a JWT is issued, it remains valid until expiration, unless the server deploys additional logic.
  • The JWT itself contains authentication information, and if it is disclosed, anyone can gain full access to the token. To reduce theft, JWT expiration dates should be shorter. For some important permissions, the user should be authenticated again.
  • JWT is suitable for one-time command authentication. Issuing a JWT with a very short validity period is very dangerous even if exposed. Since new JWT is generated every time, there is no need to save the JWT to achieve true statelessness.
  • To reduce theft, JWT should use HTTPS instead of HTTP.

Considerations when using encryption algorithms

  • Never store passwords in clear text
  • Always hash passwords and never store them in Base64 or any other encoding. This is the same as storing passwords in plain text. Hash, not encode. Encoding, as well as encryption, is a two-way process, while passwords are secret and should only be known by their owners. The process must be one-way. That’s what hashing is for, there’s never been such a thing as solving hashing, but decoding is where encoding is, decrypting is where encryption is.
  • Never use weak hashes or cracked hashes like MD5 or SHA1, only use strong password hashes.
  • Passwords should never be displayed or sent in clear text, even to the password owner. If you need the “forget password” feature, you can randomly generate a new one-time (and this is important) password and send it to the user.

Session sharing scheme in distributed architecture

1. Session replication

  • If a session is changed on any server, that node serializes all the contents of that session and broadcasts them to all other nodes, regardless of whether the other servers need the session or not, to ensure session synchronization

Advantages: Fault-tolerant, real-time response of sessions between servers. Disadvantages: It may cause pressure on the network. If the number of sessions is large, network congestion may occur, slowing down the server performance.

2. Sticky session /IP binding policies

  • The IP_hash mechanism of Ngnix is adopted to direct all requests from a CERTAIN IP address to the same server, that is, bind the user to the server. When A user makes A request for the first time, the load balancer forwards the request to server A. If A sticky session is configured for the load balancer, each subsequent request from the user will be forwarded to server A. This is the sticky session mechanism.

Advantages: Simple, no session processing is required.

Disadvantages: Lack of fault tolerance. If the currently accessed server fails and the user is moved to the second server ****, his session information will be invalid.

**** Application scenario: A fault has little impact on customers. Server failure is a low probability **** rate event.

**** Implementation: Using Nginx as an example, configure the IP_hash attribute in upstream to implement a sticky session.

3. Session Sharing (common)

  • Use distributed caching solutions such as Memcached or Redis to cache sessions, but Memcached or Redis must be clustered
  • Storing sessions in Redis is architecturally complex and requires a second visit to Redis, but the benefits are significant:
    • Realizing session sharing;
    • Horizontal scaling (adding Redis servers);
    • The session is not lost when the server restarts (note the session refresh/invalidation mechanism in Redis).
    • It can be shared not only across server sessions, but also across platforms (e.g. web and APP).

4. Session persistence

  • The session is stored in the database to ensure its persistence

**** Advantage: If the server is faulty, the session is not lost

Disadvantages of **** : If the site receives a lot of visits, storing sessions in the database will cause a lot of pressure on the **** database, and additional overhead is needed to maintain the database.

Just close the browser and the session really disappears, right?

Not right. In the case of sessions, the server will remain in place until the application notifies the server to delete a session. Generally, the application sends a command to delete a session when the user logs off.

However, the browser never actively notifies the server that it is closing before closing, so the server never has a chance to know that the browser has closed. The reason for this illusion is that most session mechanisms use session cookies to store session ids. The session ID disappears when the browser is closed, and the original session cannot be found when the server is connected again. If the cookie set by the server is saved on the hard disk, or the HTTP request header sent by the browser is rewritten in some way to send the original session ID to the server, the browser can still open the original session again.

It is precisely because closing the browser does not cause the session to be deleted that the server sets an expiration date for the session. When the client last used the session, the server assumes that the client has ceased to be active. Delete session to save storage space.

Source: suo. Im / 5 yknrs