鉴权系统的流量压力

一个场景🎬

你是一个软件开发工程师🧑‍💻，你正在开发一个非常有棒的应用，这个应用只有有限个用户，不同的用户有不同的权限去浏览不同的数据。需要设计一个鉴权中心去管理用户。

最初的想法💡

由于仅有有限个客户，最初的想法就是使用sessionId来管理用户的信息，当用户成功登录后，服务器会为该用户生成一个唯一的 sessionId，并将其返回给客户端。客户端在随后的请求中将 sessionId 作为凭据发送给服务器进行鉴权。由于客户端仅指存储了sessionId，用户的信息存储在服务端，这样也可以防止用户信息泄漏。

需求变更🔝

由于这个应用非常棒，吸引了大量的用户使用，并且这个应用也有了很多的子模块，随之而来的问题是每次请求都需要在存储sessionId的缓存中去查找用户信息，这个造成了非常大的性能压力，另外这个鉴权模块被强耦合到各个系统子模块当中，所有的子模块都需要使用这个鉴权模块。

一些思考🤔

在OAuth2.0中将参与方分为客户端，资源拥有者，授权服务器以及资源服务器，其中授权服务器和资源服务器是解耦的。当然资源服务器和健全服务器可以共用数据库来查询资源服务器生成的token，也可以使用JWT，使得资源服务器可以直接获取到用户的信息，这样在请求方只要提供了JWT，资源服务器就可以根据自定义的payload获取用户的信息。

假冒token

任何人都可以生成一个JWT，并将自己在payload中设置成admin。好在JWT提供了签名，资源服务器和授权服务器可以通过共享密钥，或者适应RSA等方式来确保token确实是授权服务器颁发的。

信息不足

JWT中自定义的payload信息可能只包含少量非敏感内容，资源服务器同样可以通过内省的方式调用授权服务器去获取用户的敏感信息。比如用户的电话号码，身份证ID。

撤回token

由于JWT本身是无状态的，意味着它们不会在被颁发后进行撤回或失效，token就相当于一张车票，有了它就可以乘坐公交车，售票员并不会检查这张票是不是你本人买的，只要出示了，并且这张票是真的，就认为合法。如果一张token被冒领，失主想要撤销token，在之前的设计中，可以新增revoke接口来使sessionId失效。但是在JWT中想要实时检查会很困难，通常的做法是将低令牌的有效期，通过使用refresh_token来获取新的令牌。当然通过内省的方式调用授权服务器去获取实时的状态也是一个选择，不过这样做又会增加授权服务器的流量压力。