What is site authentication, what is the purpose?
Generally, a website can not be only one operating authority. For example, there may be operating authority not logged in, log on operating authority, and management of
operating authority and other members. The purpose of the site is the former user authentication during the operation, to identify the user's identity and determine whether it has had the privilege of operating
processes.
Web site authentication in several ways
where we will simplify the problem, namely operating authority only to distinguish whether the user login.
Session manner
(1) Session implement authentication
1> user to log in first, such as the login is successful, the background will generate a unique sessionId, and user information stored in the background corresponding
write (redis, databases, etc.), and sessionId to Cookie.
2> The next time the browser visits, will first determine Cookie, and then determine whether the user login operation.
(2) Session consistency
that is required to be placed in the user information stored in the server together (with a redis, mysql, etc.), it may appear on a machine login,
and save the data on the machine, but in when a request for access to another server, you need to re-sign in the case.
JWT embodied and
(1) a simple authentication process JWT
JWT divided into three parts: Header (containing encryption, etc.), Payload (containing the necessary user information, and expiration date, etc.),
the Signature (generated by the first of two parts).
1> After the user logs in successfully, the user information with a background in accordance with a user unique key value, generating a string of the string, i.e. Token string, which is provided
in the Cookie;
2> with a user Token next access, the system will first according to the first two parts and the key value of the Token validity and correctness of the verification, if the
verification is passed, then the next step ...
(2) Thinking about the timing of authentication
provides two methods below, you can according to the specific needs of the site selection:
1> interfaces include interfaces to the authentication (auth), does not require authentication interface (API), and then through a filter of the interface auth
Unified process that login access, unknown jump back to the login page and so logical.
2> One problem with the above approach is impossible to define the interface appears when the interface that can be accessed login is not logged in. Then, according to the
method of the interface surface can only be split into auth api and interfaces.
So, another way is to simply not use the filter to process, when you need to log in to access, or can not be defined interface
waiting for token for authentication and access, and then followed by the following logic.
(3) the issue of Token refresh
generally valid Token time is set to 1-2 hours, then after if expires, you need to log in to reacquire Token. To avoid this
situation, we can refresh valid for a Token setting, as long as the Token effective in this refresh time inside, using the old Token be accessed
ask, it will return to a new Token. In this way, the problem can be resolved.
oauth authentication, look at (Application: Sign in)
oauth Simply put, in order to solve an application (client) in order to obtain another application (ISP) resources, without requiring the user to
provide the service provided by the client such a problem business account password information. Between the client and the service provider, there is a layer of authorization application, the client carries
Token access to resources through an authorized service provider layer.
Sign in on the use of the authorization is oauth2, there are third-party code to achieve QQ and Github log in through the Go language
Summary
We are here simply to explore the next several ways on authentication, in the actual development, for security, and the complexity of the site, may exist
in a variety of different user rights and so on, then it is possible It requires certain design and modification of these methods.
Original link: https: //blog.csdn.net/leeezm/article/details/80464847
I. Overview
What landing and certification is? They are the identification of the user's identity. This is how to identify identify which user? Or, what is the way that only the user knows (safe enough), but to say this is his own? Then there is the "username + password", "username + phone number" of modalities. The following analyzes the "username + password" login authentication methods:
- For security reasons, we can not all use the "username + password" in all requests in.
- "Username + password" can not be stored anywhere, the safest way is stored in the user's own mind, that if you want to use "username + password" you have to allow users to provide their own.
So how do we do it can not provide a user name and password for it? When we logged in user, based on the user's identity information to produce a user can mark the token.
With the authentication token information later, a new problem is how to ensure this token is safe? If other people got this token can falsify the identity of the user. The solution is to identify the token is not in the user's own use, we usually following ways, if we can guarantee the following two verification information is not changed or has been within the acceptable range, we can think that this user has been use our issued token.
- Location information (ip, latitude and longitude)
- Device Information
Now that we've done token + (location, device information) to identify the user's identity. Must identify this information to confirm the user's identity if we each request, is bound to affect the performance of our services. Then such determination how to reduce it?
- Randomly selected server a request identifying the timing or
- The client requests a timing of identification
The first approach is not recommended, the timing of each user server maintenance complex, random performance problems may have a large number of users simultaneously identified. It is the second, and the timing of client requests once identified, the server needs to force the client to request a regular appraisal, and this is a safety factor in regular time, if token leak can cause users of information security issues during the time can not be too long and not too short, the reference micro-channel is 7200s is 2 hours.
So how do you force the client from time to time to do a verification of it? Quite simply, we set up a token to the effective time, the expiration time the client must request a new token, so there is a refresh token.
Second, the authentication mode
After the user logs on, every time a client requests a service request must contain authentication information, the server queries the user information and authentication information based on its legality. Currently the authentication information can be as follows:
1. Centralized session mode
After completion of login, the server returns a random authentication as an authentication token will not be repeated, each time the client requests to bring the token (header generally placed inside request). End user service information corresponding token query to the token.
2. Token way
After you log in, the server encryption according to user information and other safety factors to generate a security token (ie JWTS, JSON Web Tokens), the token contains a user's identity information, authentication only when the authentication token verification legitimacy to, you can take to decrypt the user information.
3. Compare
| Authentication mode | advantage | insufficient |
|---|---|---|
| Centralized session mode | 1. The server maintains user state, can manage user status, and user information is not consistent failure problem; 2. Security is relatively high |
Session 1. The server maintains state information about the user needs to obtain high performance requirements in accordance with Token |
| Token way | 1. The client records the user state, the service is stateless, there is no centralized performance issues. 2. Business decoupled, relatively simple logic multi authentication, a token on the performance and reliability technology is relatively easier |
Token mandatory or failure to renew the problem, a token force the update fails or requires additional work (such as banning users) 2. When the user information is updated, the synchronization problem in the user's token |
Third, the authentication implementation
1. Centralized session mode Sequence Timing
- Client requests business services in the unregistered state, the direct return 401 when the gateway does not obtain authentication information, inform the client need to be logged.
- Clients use "phone number + password", "phone number + code" approach to request access to services.
- Gateway is found after landing service request login authentication services.
- Login authentication service inquiry via mobile phone number user information, while generating token.
- Gateway returns token, gateway token back to the client.
- The client request with token gateway, the gateway will pass token authentication service, authentication by token service to query the user information and return to the gateway, users will be transferred to the business information service, complete the following business processes.
2. Process a token sequence
- Client requests business services in the unregistered state, the direct return 401 when the gateway does not obtain authentication information, inform the client need to be logged.
- Clients use "phone number + password", "phone number + code" approach to request access to services.
- Gateway is found after landing service request login authentication services, while generating token (JWT information), and the token is returned to the client.
- The client request token with the gateway, according to the decrypted token user information (information of the JWT), and transfer the information to the user business services, business processes complete the next.
Fourth, the authentication technology program
1. Centralized Authentication aspect Session
Session centralized authentication to authenticate users of the following ways:
| achieve | Explanation | advantage | Shortcoming |
|---|---|---|---|
| RPC calls | Gateway authentication service via RPC call, acquire user information token | Architecture logic is simple, does not require additional work | RT increase response |
| Redis direct reading | Gateway authentication service directly read the Redis, validate and obtain user information | high performance | Gateway authentication verification need be integrated logic, and configuration maintenance Redis |
| Nginx Lua | In Nginx was achieved by the authentication logic lua script | Best performance | 1. Before gateway, a request for an invalid signature authentication verification also needs to be done. 2. Nginx transformation, lua development costs |
2. Authentication Token embodiment aspect
Way authentication token to achieve much simpler, gateway information acquiring resolve directly JWT user information, and user information to the request with the traffic data.