用户验证三部曲2 - token

采用微服务的方式对用户验证和用户数据解耦 用户API涉及的库表 用户待办数据API涉及的库表 用户待办事项表 调用用户登录API
返回JSON数据 查询用户待办事项

上面的处理方式显然是不安全的，用户数据直接传输到了客户端，待办查询API只接收用户参数就能查询，无法进行验证是否请求来自参数中宣称的用户，很容易被伪造滥用。

要解决上面的问题就引入一个概念 Token(用户票据)，用户API负责颁发Token给客户端，当客户端调用 待办查询API时，需要携带Token,API将Token拿到用户API去验证。

用户信息不再返回给客户端，而是返回给数据API，客户端仅能获得Token

那Token又带来了什么问题

• 必要保留用户和Token之间的映射，要么在内存要么在数据库中
• 用户API还是稍微有点状态
• 用户API和其他服务耦合到一起

Token虽然解决了微服务模式下的用户验证问题，但是需要在服务端维护用户和Token映射，不能完全做到服务的无状态和服务间的低耦合，所以我们还需要继续探索。