身份认证

  对于所有多用户信息系统，用户身份认证永远是系统安全的基础功能。区块链平台目前实现的身份认证组件支持两种认证方式：传统的用户名口令方式和区块链增强认证方式，后者用于需要“强认证”的场景，如资产确权、资产交易等。

（一）用户名口令方式

  用户名口令认证方式一般用于用户界面登录。用户在注册时设置用户名、口令，用户界面前端将口令哈希后和用户名一起传到后台保存。登录时，用户输入用户名、口令，口令在前端哈希后与用户名一起发送到后台，后台检查这个用户名和口令哈希是否与库中用户注册时设置的用户名、口令哈希一致，如果一致则通过身份认证，系统返回访问令牌，之后的用户界面访问都需要在HTTP请求中带上这个令牌。区块链平台使用JWT格式访问令牌。

  企业用户可以启用开发者账号。启用后，企业开发者可以通过在应用中调用区块链平台的Rest API来使用平台功能。相比仅通过界面访问区块链平台，使用Rest API调用方式可以将企业应用与区块链平台无缝集成在一起，从而打通供应链、链接消费者等。

  Rest API认证使用API-Key和API-Secret，这种认证本质上也是一种用户名口令认证。企业用户可以通过界面启用开发者账号，然后申请API-Key和API-Secret。类似于用户名口令方式，开发者应用调用API前，需要用API-Key和API-Secret换取JWT令牌，然后在调用Rest API的请求中带上JWT令牌。

  用户名口令方式很成熟，但它是传统的中心化方案，立足于用户对系统运维方的绝对信任。只要系统运维方愿意，很容易模拟某用户登录和访问系统并确保不留下登录和访问痕迹。

（二）区块链增强认证方式

  区块链增强认证，指当用区块链账号、私钥代替传统的用户名、口令，让用户证明自己对区块链账号有控制权。在浪潮区块链平台中，区块链账号私钥默认被平台托管，区块链增强认证过程中会利用托管私钥（托管钱包）向区块链签署交易。区块链增强认证的步骤如下：

1.用户向区块链平台的身份认证组件请求区块链增强认证；

2.平台返回一个随机数作为挑战，要求用户用自己的区块链账号将该随机数写入区块链；

3.用户向托管钱包申请写入指定随机数；

4.钱包要求用户输入钱包密码。如果没有启用托管私钥的加密存储，则这一步被省略；

5.托管钱包通过区块链客户端SDK（已配置好私钥）向区块链的认证智能合约发起写链请求，要求将挑战随机数写入区块链，即发起一个新交易。智能合约处理交易请求，新交易通过区块链共识机制检验后被打包成区块；

6.身份认证组件收到区块链事件消息后检查区块链的认证智能合约，发现挑战随机数已经被写入区块链，验证写链的账号与用户绑定的区块链账号是否一致；

7.平台返回访问令牌给用户。用户就可以使用令牌访问平台或应用。

  区块链增强认证比传统的用户名口令方式更安全，因为认证过程在区块链上写链留痕，用户获得访问令牌的行为不可否认、痕迹不能删除。

  目前采用的“挑战-响应”模式需要用户客户端与区块链平台多次交互，未来计划升级为非交互认证方式，即一次请求就完成写链留痕和令牌获得。

（三）认证的使用场景

  对于浪潮区块链平台来说，身份认证组件需要完成的任务， 一是平台自身界面和API的身份认证；二是基于平台开发的第三方应用的身份认证；三是对数据网关（后续章节讲到）用户的身份认证。

  任务一的平台自身的界面和API认证比较好理解不再冗述。

  任务二：当平台上聚拢了大量企业和个人用户后，第三方应用可能会以企业开发者身份调用平台API进行定制开发，这时需要以企业账号登录后激活开发者账号，取得API-Key和API-Secret，换取JWT访问令牌，再利用令牌调用平台API。这描述的实际上是OAuth授权的客户端信任授权模式。

  任务二的另一种场景是OAuth授权的用户授权模式，这种授权模式是为了保护用户的隐私数据，用户隐私数据只有在得到用户授权后才可以被第三方应用调用API访问。在这种模式下，需要弹出平台的授权界面，用户点击授权后，平台才发放JWT访问令牌给第三方应用。

  任务三是后文的“数据网关”章节中描述。