通用接口开放平台设计与实现——（24）消息服务之登录流程

登录流程

客户端与服务端互相推送消息的前提是双方互信，也就是说，需要身份认证。
身份认证同样有多种方案，这里我们采用比较常规的方式，即客户端使用账号和密钥来发送1条登录请求消息，服务端收到后进行认证，认证通过后，向客户端推送一条登录成功的响应消息，并将当前通道放到全局容器，用于后续从服务端主动向客户端推送消息；客户端收到登录成功消息后，将通道保存到全局容器，用于后续从客户端主动推送消息到服务端。

身份认证，涉及到密码的存储和处理，由于我们接口开放平台这里的“用户”，实际是对接的系统，我们给每个系统分配一个密钥，而不是常规意义上的密码。这个密钥是明文存储在数据库中的，因为在系统调用API服务时，需要使用这个密钥进行签名运算，如数据库中存放加密后的密钥，反而不是那么便利。当然，如果对安全性要求很高，可以考虑使用对称加密算法加密后存库。在这里我们认为加密存储的必要性不大。如果数据库都被攻破或泄露了，也就谈不上什么数据安全了，直接篡改数据库中数据就行了，没必要再去拿密钥做文章。如果要防止“家贼”，其实在这种场景下，密钥泄露的危害也非常有限，同样是因为对接的是系统而不是用户，即使拿到密钥，仍然需要按照系统对接方式去调用API服务。

上面说了，这个密钥我们是明文存储的，在API调用服务时需要使用进行签名运算，消息服务是否可以加强下安全呢？

在大多数场景下，通常是客户端发送原始密码，服务端数据库中存储是加密后的密码，如果服务端存的是明文，这里我们做了一个变通，客户端将密码进行加密，然后二者比对。