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.
- 客户端带着 token 请求网关，网关将 token 传给鉴权服务，鉴权服务通过 token 查询用户信息并返回给网关，网关将用户信息转给业务服务，完成接下来的业务流程。
2. 令牌方式流程时序
- 客户端在未登录的状态下请求业务服务，在网关没有获取到认证信息时直接返回 401，告知客户端需要登录。
- 客户端使用“手机号+密码”、“手机号+验证码”的方式请求登陆服务。
- 网关发现是登陆服务后，请求登陆认证服务，同时生成 token（JWT信息），并将 token 返回给客户端。
- 客户端带着 token 请求网关，网关根据 token（JWT信息）解密得到用户信息，并将用户信息转给业务服务，完成接下来的业务流程。
四、鉴权技术方案
1. 集中式Session鉴权技术方案
集中式Session鉴权验证用户身份有如下的实现方式：
| 实现 | 说明 | 优点 | 缺点 |
|---|---|---|---|
| RPC调用 | 网关通过RPC调用鉴权服务，通过token获取用户信息 | 架构逻辑简单，不需要额外工作 | 增加响应 RT |
| Redis 直读 | 网关直接读取鉴权服务的 Redis，验证并获取用户信息 | 高性能 | 需要网关也集成鉴权验证逻辑，并且维护 Redis 的配置 |
| Nginx Lua | 在 Nginx 里通过 lua 脚本实现鉴权逻辑 | 性能最好 | 1. 在网关之前，对签名无效的请求也需要做鉴权验证。 2. Nginx 改造，lua 开发成本 |
2. 令牌方式鉴权技术方案
令牌方式鉴权的实现就简单的多， 网关直接解析 JWT 信息获取用户信息，然后带着用户信息去请求业务数据。