用于授权访问的客户端装置、服务器装置和访问控制系统的制作方法

本公开涉及信息安全和访问控制技术，更具体地，涉及利用去中心化的公共数据库来实现安全授权访问的客户端装置、服务器装置、访问控制系统和相应的方法。

背景技术：

访问控制是所有计算机系统都需要涉及的机制，无论是客户端/服务器系统，客户端/浏览器系统，还是云系统，从最简单的用户名/密码，到广泛使用的认证码/验证码(CAPTCHA)，以及现在广泛使用的短信验证码和基于硬件的UKey等，其中，短信验证码和UKey都需要外部设备的支持。访问控制环节最主要的内容是确认访问申请的真实性和有效性。通过真实性和有效性的判断可以有效地抵御部分网络攻击，如重放攻击，中间人攻击，进而也可以降低拒绝服务攻击的风险。

技术实现要素：

在下文中给出了关于本公开的简要概述，以便提供关于本公开的某些方面的基本理解。但是，应当理解，这个概述并不是关于本公开的穷举性概述。它并不是意图用来确定本公开的关键性部分或重要部分，也不是意图用来限定本公开的范围。其目的仅仅是以简化的形式给出关于本公开的某些概念，以此作为稍后给出的更详细描述的前序。

鉴于以上问题，本公开的目的是提供一种能够有效地抵御部分网络攻击的用于授权访问的客户端装置、服务器装置、访问控制系统和相应的方法。

根据本公开的一方面，提供了一种用于授权访问的客户端装置，包括：请求生成单元，被配置成生成用于受保护资源的授权访问的请求，并且将该请求发送到服务器装置；记录单元，被配置成将请求记录在公共数据库中，其中，公共数据库是去中心化的分布式数据库，并且公共数据库中的 记录是不可更改的；以及访问单元，被配置成利用服务器装置响应于请求而发送的响应信息，执行用于访问受保护资源的相应操作。

根据本公开的优选实施例，公共数据库包括区块链(Blockchain)。

根据本公开的另一优选实施例，请求生成单元进一步被配置成利用客户端私钥对请求进行签名并将签名后的请求发送给服务器装置，并且记录单元进一步被配置成将签名后的请求记录在公共数据库中。

根据本公开的另一优选实施例，请求生成单元进一步被配置成还将请求在公共数据库中的位置信息发送给服务器装置。

根据本公开的另一优选实施例，访问单元进一步被配置成利用服务器公钥对响应信息在公共数据库中的记录进行验证，并且根据验证的结果而执行相应操作。

根据本公开的另一优选实施例，服务器装置包括授权服务器和资源服务器。

根据本公开的另一优选实施例，请求包括发送给授权服务器的对于授权访问凭证的请求，并且响应信息包括来自授权服务器的授权访问凭证。

根据本公开的另一优选实施例，授权访问凭证包括与受保护资源有关的限制信息。

根据本公开的另一优选实施例，限制信息包括受保护资源的管理者的标识、允许客户端装置访问的资源以及授权访问凭证的有效期。

根据本公开的另一优选实施例，限制信息还包括在有效期内的访问次数设置，并且访问单元根据访问次数设置而执行用于访问受保护资源的相应操作。

根据本公开的另一优选实施例，请求包括发送给资源服务器的数据访问请求，并且响应信息包括来自资源服务器的数据资源。

根据本公开的另一优选实施例，授权服务器和所述资源服务器是同一服务器。

根据本公开的另一方面，还提供了一种用于授权访问的服务器装置，包括：响应生成单元，被配置成响应于来自客户端装置的对于受保护资源的授权访问的请求而生成相应的响应信息，并且将响应信息发送到客户端装置；以及记录单元，被配置成将响应信息记录在公共数据库中，其中，公共数据库是去中心化的分布式数据库，并且公共数据库中的记录是不可 更改的。

根据本公开的另一方面，还提供了一种用于授权访问的访问控制系统，该访问控制系统包括客户端装置、服务器装置和公共数据库，其中，公共数据库是去中心化的分布式数据库，并且公共数据库中的记录是不可更改的，并且其中，客户端装置包括：请求生成单元，被配置成生成用于受保护资源的授权访问的请求，并且将请求发送到服务器装置；第一记录单元，被配置成将请求记录在公共数据库中；以及访问单元，被配置成利用服务器装置响应于请求而发送的响应信息，执行用于访问受保护资源的相应操作；以及服务器装置包括：响应生成单元，被配置成响应于请求而生成相应的响应信息，并且将响应信息发送到客户端装置，以及第二记录单元，被配置成将响应信息记录在公共数据库中。

根据本公开的另一方面，还提供了一种在客户端装置执行的用于授权访问的方法，该方法包括：生成用于受保护资源的授权访问的请求，并且将请求发送到服务器装置；将请求记录在公共数据库中，其中，公共数据库是去中心化的分布式数据库，并且公共数据库中的记录是不可更改的；以及利用服务器装置响应于请求而发送的响应信息，执行用于访问受保护资源的相应操作。

根据本公开的另一方面，还提供了一种在服务器装置执行的用于授权访问的方法，该方法包括：响应于来自客户端装置的对于受保护资源的授权访问的请求而生成相应的响应信息，并且将响应信息发送到客户端装置；以及将响应信息记录在公共数据库中，其中，公共数据库是去中心化的分布式数据库，并且公共数据库中的记录是不可更改的。

根据本公开的另一方面，还提供了一种电子设备，该电子设备可包括收发机和一个或多个处理器，这一个或多个处理器可被配置成执行上述根据本公开的用于授权访问的方法。

根据本公开的其它方面，还提供了用于实现上述根据本公开的方法的计算机程序代码和计算机程序产品以及其上记录有该用于实现上述根据本公开的方法的计算机程序代码的计算机可读存储介质。

根据本公开的实施例，可以通过利用去中心化的公共数据库而有效地实现对于受保护资源的安全授权访问。

在下面的说明书部分中给出本公开实施例的其它方面，其中，详细说明用于充分地公开本公开实施例的优选实施例，而不对其施加限定。

附图说明

本公开可以通过参考下文中结合附图所给出的详细描述而得到更好的理解，其中在所有附图中使用了相同或相似的附图标记来表示相同或者相似的部件。所述附图连同下面的详细说明一起包含在本说明书中并形成说明书的一部分，用来进一步举例说明本公开的优选实施例和解释本公开的原理和优点。其中：

图1是示出根据本公开的实施例的访问控制系统的架构的示例的示意图；

图2是示出根据本公开的实施例的客户端装置的功能配置示例的框图；

图3是示出根据本公开的实施例的服务器装置的功能配置示例的框图；

图4是示出根据本公开的实施例的用于授权访问的交互流程的示例的示意图；

图5是示出根据本公开的实施例的基于区块链的访问控制实现的示例的示意图；

图6是示出根据本公开的实施例的区块链中的记录项的格式和内容的示例的示意图；

图7是示出根据本公开的实施例的用于授权访问的方法的过程示例的流程图；

图8是示出根据本公开的实施例的基于区块链和OAuth协议的访问控制系统的架构的示例的示意图；

图9是示出根据本公开的实施例的基于区块链的OAuth协议实现的示例的示意图；

图10是示出应用本公开的技术的用于实现有限次授权访问的交互过程的示例的流程图；

图11A和图11B是示出应用本公开的技术的用于实现有限次授权访问的示例的示意图；

图12是示出根据本公开的实施例的在客户端装置执行的用于授权访 问的方法的过程示例的流程图；

图13是示出根据本公开的实施例的在服务器装置执行的用于授权访问的方法的过程示例的流程图；

图14是示出根据本公开的技术的第一应用示例的示意图；

图15是示出根据本公开的技术的第二应用示例的示意图；以及

图16是作为本公开的实施例中可采用的信息处理设备的个人计算机的示例结构的框图。

具体实施方式

在下文中将结合附图对本公开的示范性实施例进行描述。为了清楚和简明起见，在说明书中并未描述实际实施方式的所有特征。然而，应该了解，在开发任何这种实际实施例的过程中必须做出很多特定于实施方式的决定，以便实现开发人员的具体目标，例如，符合与系统及业务相关的那些限制条件，并且这些限制条件可能会随着实施方式的不同而有所改变。此外，还应该了解，虽然开发工作有可能是非常复杂和费时的，但对得益于本公开内容的本领域技术人员来说，这种开发工作仅仅是例行的任务。

在此，还需要说明的一点是，为了避免因不必要的细节而模糊了本公开，在附图中仅仅示出了与根据本公开的方案密切相关的设备结构和/或处理步骤，而省略了与本公开关系不大的其它细节。

接下来，将参照图1至图16详细描述本公开的实施例。

图1是示出根据本公开的实施例的访问控制系统的架构的示例的示意图。

如图1所示，根据该实施例的访问控制系统可包括公共数据库100、客户端装置200和服务器装置300。

在本公开的实施例中，为了保证客户端装置200对于受保护资源的安全访问，可使得在授权访问过程中的客户端装置200和服务器装置300的关键操作分别记录在公共数据库100中，由于公共数据库100是去中心化的分布式数据库，其中的数据一经记录便不可更改和删除，因此有利于抵抗网络攻击，实现安全访问控制。下面，将分别参照图2和图3详细描述客户端装置200和服务器装置300的功能配置示例。

图2是示出根据本公开的实施例的客户端装置的功能配置示例的框图。

如图2所示，根据该实施例的客户端装置200可包括请求生成单元210、记录单元220和访问单元230。

请求生成单元210可被配置成生成用于受保护资源的授权访问的请求，并且将该请求发送到服务器装置300。

记录单元220可被配置成将上述请求记录在公共数据库100中。

访问单元230可被配置成利用服务器装置300响应于请求而发送的响应信息，执行用于访问受保护资源的相应操作。

优选地，为了增强安全性，请求生成单元210可进一步利用密钥生成中心针对客户端装置200所生成的身份密钥对(包括私钥(private key，记为SK)和公钥(public key，即为PK))中的私钥对该请求进行签名，将签名后的请求发送给服务器装置300，并且记录单元220可将签名后的请求记录在公共数据库100中。该过程例如可通过以下表达式(1)来表示：

Record 1＝Sign_{SK of Client}(Hash(Request)) (1)

其中，Request表示来自客户端装置的请求，SK of Client表示客户端装置200的私钥，Hash()表示哈希函数，Sign_{SK of Client}表示利用客户端装置200的私钥进行签名，并且Record1表示该签名后的请求在公共数据库中的记录。

优选地，请求生成单元210还可将上述请求记录在公共数据库中的位置信息(这里例如记为Addr1)发送给服务器装置300。这样，服务器装置300可以根据所接收到的位置信息而在公共数据库100中查找签名后的请求在公共数据库100中的记录(上述Record1)，并且利用客户端装置200的公钥验证来自客户端装置200的请求的真实性，该验证过程例如可通过以下表达式(2)来表示：

Addr 1→Record 1

Verify(Rec ord 1)＝Verify_{PK of Client}(Record 1)＝？Hash(Request) (2)

其中，Verify()表示所采用的验证函数，并且PK of Client表示客户端装置200的公钥。

然后，针对经验证合理的请求，服务器装置300可生成相应的响应信 息(这里记为Response)以发送给客户端装置200，并且还将该响应信息记录在公共数据库100中。优选地，为了进一步保证安全性，服务器装置300也可利用服务器私钥对响应信息进行签名，将签名后的响应信息发送给客户端装置200，并且将签名后的响应信息记录在公共数据库100中。该过程例如可通过以下表达式(3)来表示：

Record 2＝Sign_{SK of Server}(Hash(Response)) (3)

其中，Response表示服务器装置生成的响应信息，SK of Server表示服务器装置300的私钥，Hash()表示哈希函数，Sign_{SK of Server}表示利用服务器装置300的私钥进行签名，并且Record2表示该签名后的响应信息在公共数据库100中的记录。

此外，与上述类似，服务器装置300也可将签名后的响应信息在公共数据库中的位置信息(这里例如记为Addr2)发送给客户端装置200，从而客户端装置200的访问单元230可根据所接收的位置信息而在公共数据库100中查找签名后的响应信息在公共数据库100中的记录，利用服务器公钥对该记录进行验证，并且根据验证结果而执行相应操作。该过程例如可通过以下表达式(4)来表示：

Addr 2→Record 2

Verify(Rec ord2)＝Verify_{PK of Server}(Record 2)＝？Hash(Response) (4)

其中，Verify()表示所采用的验证函数，并且PK of Server表示服务器装置300的公钥。

以上参照图2描述了用于授权访问的客户端装置的功能配置示例，相对应地，下面将参照图3描述用于授权访问的服务器装置的功能配置示例。图3是示出根据本公开的实施例的服务器装置的功能配置示例的框图。

如图3所示，根据本实施例的服务器装置300可包括响应生成单元310和记录单元320。

响应生成单元310可被配置成响应于来自客户端装置的对于受保护资源的授权访问的请求而生成相应的响应信息，并且将响应信息发送到客户端装置200。

优选地，如上所述，响应生成单元310可利用客户端公钥(即，上述PK of Client)对客户端装置200的请求在公共数据库中的记录(即，上 述记录Record1)进行验证，并且根据验证的结果而生成响应信息(即，Response)。该过程可通过例如上述表达式(2)来表示。

记录单元320可被配置成将响应信息记录在公共数据库100中。

优选地，如上所述，响应生成单元310可进一步被配置成利用服务器私钥对响应信息进行签名并将签名后的响应信息发送给客户端装置200，并且记录单元320可进一步被配置成将签名后的响应信息记录在公共数据库100中。该过程例如可由上述表达式(3)来表示。此外，响应生成单元310还可将响应信息在公共数据库中的位置信息(即，上述Addr2)发送给客户端装置200。

应理解，服务器装置300的功能配置示例是与上述客户端装置200的功能配置示例相对应的，因此在此未详细描述的内容可参见以上相应位置的描述，在此不再重复。

为了有助于理解上述授权访问的实现过程，下面将参照图4描述用于授权访问的客户端装置200、服务器装置300以及公共数据库100之间的交互流程。图4是示出根据本公开的实施例的用于授权访问的交互流程的示例的示意图。

如图4所示，首先，在步骤S101中，客户端装置200利用客户端私钥对请求进行签名以生成用于受保护资源的授权访问的请求，并且在步骤S102中将该请求记录在公共数据库100中。在步骤S103中，公共数据库100将上述请求添加到其记录中，并且该记录(即，Record1)的位置例如为Addr1。然后，在步骤S104中，客户端装置200将签名后的请求及其在公共数据库100中的位置信息Addr1发送给服务器装置300。接下来，在步骤S105中，服务器装置300根据位置信息Addr1，利用客户端公钥对上述请求记录Record1进行验证，并且如果验证该请求是合理的，则在步骤S106中生成相应的响应信息并且利用服务器私钥对该响应信息进行签名。然后，在步骤S107中，服务器装置300将该签名后的响应信息记录在公共数据库100中，并且在步骤S108中，公共数据库100将该响应信息记录添加到其记录中，并且该记录(即，Record2)的位置例如为Addr2。接下来，在步骤S109中，服务器装置300将该签名后的响应信息及其在公共数据库中的位置信息Addr2发送给客户端装置200。如果需要，则客户端装置200可在步骤S110(可选的，如虚线所示)中根据位置信息Addr2，利用服务器公钥对响应信息在公共数据库100中的记录Record2进行验证，并且根据验证结果而执行相应的操作，例如，访问受 保护资源等。

应理解，上述交互过程仅为示例而非限制，并且所示出的各个步骤的执行顺序也仅是为了描述方便而不限于此，根据需要，一些步骤可并行地执行或者其执行顺序可改变。

根据以上描述的过程可以看出，由于客户端装置200和服务器装置300的交互过程被记录在公共数据库100中，而该公共数据库100是一个去中心化的分布式数据库，并且其中的记录是不可更改(即，不可删除和/或修改)的，因此通过分别利用客户端私钥和服务器私钥对交互过程进行签名并且记录在公共数据库中，可以有效地抵抗网络攻击。在这里，应指出，由于公共数据库100是由所有网络实体共享的分布式数据库，因此从理论上来讲，如果一半以上或者三分之二以上的网络实体都同意更改公共数据库中的数据记录，则可以允许对其中的记录进行更改。然而，实际上，很难使得一半以上或三分之二以上的网络实体都同意更改数据记录，因此这里通常认为公共数据库中的数据一经记录便不可修改和删除。

优选地，作为示例，上述公共数据库可包括区块链。区块链(Blockchain)被视为比特币(Bitcoin)背后的主要技术创新。因为它作为一个无需信任的证明机制，用于去证明网络中所有的交易。区块链是一种“非信任”架构。“非信任”架构就是在整个系统中的多个参与方无需互相信任就能够完成各种类型的交易和协作。这恰恰一直是传统互联网到目前为止最薄弱的一项。与需要建立和维持与交易对方(其他人)或第三方中介(如银行)的信任相比，用户可以信任由“挖矿者-审计(miner-accountants)”维持的、在世界范围内存储在多个不同的去中心化节点上的公共账务系统。作为用于去中心化的非信任的新交易系统的架构的区块链是关键创新。区块链允许在全球的所有实体之间进行无需干预的和去中心化的任何类型的所有交易。区块链像是用于在因特网协议的现有栈上运行的另一应用层，为因特网增加了全新的层以实现经济交易，包括即时数字货币支付(在全球广泛地使用加密货币的情况下)和更长期、更复杂的经济合约。任何货币、经济合约或者硬或软资产都可通过区块链系统进行交易。此外，区块链不仅可用于交易，并且还可用作用于记录、跟踪、监视和交易所有资产的登记和库存系统。区块链在字面上像是用于登记所有资产的巨大扩展表以及用于在全球范围交易这些资产的记账系统，包括世界范围的所有实体持有的所有形式的资产。因此，区块链可以用于任何形式的资产登记、存量和交换，包括金融、经济和金钱的各个领 域；硬资产(物理财产)和无形资产(投票、构思、名誉、意图、健康数据等等)。比特币点对点网络将所有的交易历史都储存在“区块链”(Blockchain)中。区块链在持续延长，而且新区块一旦加入到区块链中，就不会再被移走。区块链实际上就是一个P2P网络平台，也就是一群分散的用户端节点，并由所有参与者组成的分布式数据库，是对所有比特币交易历史的记录。然而，随着区块链技术的发展，它也不仅仅只是应用在虚拟货币的支付领域。区块链技术的去中心化无需信任的点到点模型意味着,在最基本的水平,无中间人交易。区块链是比特币的网络基础，但区块链本身意味着更多。如果说区块链技术1.0是为虚拟货币而生，则区块链技术2.0的核心特性信用信任成为目前的重要应用方向，被建议做区块链合同、公证等。而区块链技术3.0则被定位为金融应用以外的应用领域，如在政府领域、健康、科学、文化和艺术等。

区块链是一个去中心化的、分布式的、按时间顺序排列的公共记录，或称为公共账务系统。区块链由所有用户共享以及共同维护。区块链中的记录可以被用来验证双重消费，如果区块链被应用于虚拟货币的账单，则可以用来验证比特币交易的永久性并防止双重消费。区块链在本发明中则可以用于避免同一认证码的多次使用，将区块链技术应用在授权服务平台，则可通过按时间顺序的公共记录集，验证授权协议相关的步骤以及防止重放攻击。

除了比特币之外，根据本公开的实施例的公共数据库还可采用诸如莱特币这样的基于去中心化区块链的公共账务(public ledger)平台，还有Hyperledger这样采用“共识”而非挖矿的去中心化的分布式账务系统。

本发明的授权服务同样可以基于Hyperledger平台实现应用，例如，将请求和响应信息记录在Hyperledger的共识池中，例如测试池(testpool)、用户池(custompool)等，testpool对所有人都免费开放，custompool则是允许用户自定义池子。通过Hyperledger的“共识”机制，确认记录有效后，该记录则不可被删改。

下面将以区块链为例来描述根据本公开的实施例的访问控制实现，但是应理解，本公开当然不限于此，而是可应用于任何去中心化的、分布式的且其中的记录不可删除和修改的数据库系统。图5是示出了根据本公开的实施例的基于区块链的访问控制实现的示例的示意图。

如图5所示，客户端装置200和服务器装置300分别将各自的签名后的请求和响应信息添加到区块链中，这些记录按照时间先后顺序排列在区 块链中，并且一经记录则不可修改和删除，从而客户端装置200和服务器装置300可根据请求和响应信息在区块链中的位置信息而查找相应记录，利用公钥分别对区块链中的记录进行验证，以确保访问控制的安全性。

图6是示出根据本公开的实施例的区块链中的记录项的格式和内容的示例的示意图。

如图6所示，区块链中的记录可包括地址、内容创建者的签名以及其它应用相关信息。例如，客户端装置200记录在区块链中的请求记录包括请求在区块链中的位置信息(Addr1)和请求的签名，并且在服务器装置300将其响应信息记录在区块链中之后，此时的区块链中的记录项包括响应信息在区块链中的位置信息(Addr2)、响应的签名、请求在区块链中的位置信息(Addr1)、请求的签名等等，即，区块链中的记录按照记录的时间顺序而增长，并且不可删除和修改。

应理解，这里所给出的记录项的格式和内容仅为示例，可根据实际应用需求而设置其中的记录项的格式和内容，本公开对此不作限制。

与上述交互过程相对应的，下面将参照图7描述根据本公开的实施例的用于授权访问的方法的过程示例。图7是示出根据本公开的实施例的用于授权访问的方法的过程示例的流程图。

如图7所示，该方法开始于步骤S701，然后进行到步骤S702。在步骤S702中，客户端装置200生成用于受保护资源的授权访问的请求，利用客户端私钥签名后记录到区块链中，并得到该请求在区块链中的位置信息。然后，该方法进行到步骤S703。在步骤S703中，客户端装置200将其签名后的请求以及该请求在区块链中的位置信息发送给服务器装置300。接下来，在步骤S704中，服务器装置300根据所接收的位置信息而得到区块链中的请求记录，并且利用客户端公钥验证该记录。然后，该方法进行到步骤S705，在步骤S705中判断该记录是否有效。如果判断无效，则该方法结束。如果判断有效，则方法进行到步骤S706，在步骤S706中，服务器装置300针对有效的请求而生成响应信息，利用服务器私钥签名后记录在区块链中，并得到该响应信息在区块链中的位置信息。接下来，在步骤S707中，服务器装置300将签名后的响应信息及其在区块链中的位置信息发送给客户端装置200，并且该方法结束。

以上参照图7描述了根据本公开的用于授权访问的方法的过程示例，但是应理解，这仅是示例而非限制，并且本领域技术人员可根据需要而对 上述过程进行修改。例如，如上所述，如果需要，则客户端装置200还可在接下来的步骤中根据所接收的位置信息而得到区块链中的响应信息记录，利用服务器公钥验证该记录，并且根据验证结果而执行相应操作。

以上参照图1至图7描述了授权访问控制的一般示例，下面将结合OAuth(开放授权,http://oauth.net/)标准来描述应用本公开的技术的授权访问控制的实现。

在具体描述OAuth协议与本发明的技术的结合之前，在此先简要介绍一下OAuth协议。OAuth是一个关于授权(authorization)的开放网络协议(标准)。在OAuth协议中，引入了授权层并且将客户端的角色与资源所有者的角色分离，客户端请求对由资源所有者控制的并且由资源服务器拥有的资源的访问，并且被发放与资源所有者的凭证不同的凭证集合。在OAuth协议中，定义了以下四个角色：资源所有者，其是能够授权对受保护资源的访问的实体，当资源所有者是人时，也可称为终端用户；资源服务器，其是拥有受保护资源的服务器，能够使用访问令牌接受和响应对受保护资源的访问请求；客户端，其是代表资源所有者并且利用资源所有者的授权而进行受保护资源请求的应用，其并不暗示任何特定的实现特性(例如，该应用在服务器、台式机还是其它装置上执行)；以及授权服务器，其是在成功认证了资源所有者并且获得了授权之后对客户端发放访问令牌的服务器，其可以与资源服务器是同一服务器或者也可以是不同的实体，并且单个授权服务器可发出由多个资源服务器接受的访问令牌。

OAuth的发展促进了开放API领域的新应用的开发。OAuth为应用提供了一种访问受保护资源的方法。在应用访问受保护资源之前，它必须先从资源所有者处获取授权(访问许可)，然后用访问许可交换访问令牌(代表访问许可的作用域、持续时间和其它属性)。应用通过向资源服务器出示访问令牌来访问受保护资源。目前被推荐使用的是OAuth 2.0标准。然而，OAuth 2.0协议本身不提供安全性和完整性保护机制，开发者在使用OAuth 2.0时，需要额外提供通信安全性的保护机制。

OAuth 2.0协议本身无法抵御重放攻击和中间人攻击，例如网络传输时的重放攻击，认证码可能被截取并用来多次申请授权访问凭证等。如上所述，通过将授权的交互过程记录在公共数据库(例如，区块链)中，即，通过将OAuth协议与区块链技术相结合，可以有效地抵抗中间人攻击和重放攻击。作为示例，下面将详细描述基于区块链和OAuth协议的授权访问控制的实现的示例。

图8是示出根据本公开的实施例的基于区块链和OAuth协议的访问控制系统的架构的示例的示意图。

如图8所示，根据该实施例的访问控制系统可包括区块链100、客户端装置200、授权服务器400、资源服务器500和资源所有者600。其中，区块链100和客户端装置200与上述公共数据库100和客户端装置200具有相同的配置，在此不再重复。授权服务器400和资源服务器500可具有与上述服务器装置300相同的配置，即，服务器装置300可包括授权服务器400和资源服务器500，并且这两个服务器也可以是同一个服务器装置，因此在此不再重复描述其配置。下面将仅简单介绍在OAuth协议中上述各个装置的作用。

资源所有者600是能够授权许可对受保护资源的访问的实体；资源服务器500是拥有受保护资源的服务器，其能够接受和响应使用访问令牌的对受保护资源的请求；客户端装置200是代表资源所有者并且利用资源所有者的授权对受保护资源进行请求的应用，其并不限于任何特定实现形式，即，其可以在服务器、计算机、便携式设备或者其它装置上实现；以及授权服务器400是在成功认证了资源所有者并且获得授权之后对客户端装置200发出访问令牌的服务器。

下面将参照图9详细描述基于区块链的OAuth协议的实现过程的示例。图9是示出根据本公开的实施例的基于区块链的OAuth协议实现的示例的示意图。

如图9所示，首先，在步骤S901中，客户端装置200向资源所有者600发起授权请求，然后，在步骤S902中，资源所有者600将用户授权凭证发送给客户端装置200。接下来，在步骤S903中，客户端装置200根据用户授权凭证，向授权服务器400发送对于授权访问凭证的请求(即，申请数据访问授权)，并且在步骤S904中，客户端装置200将该请求记录在区块链100中。应指出，该对于授权访问凭证的请求包含客户端装置200的签名信息，即，客户端装置200利用客户端私钥对该请求进行了签名。然后，在步骤S905中，授权服务器400验证用户授权凭证，并且如果验证有效，则生成授权访问凭证，并且将该授权访问凭证记录在区块链100中。应指出，这里的授权访问凭证包含授权服务器400的签名信息，即，授权服务器400利用其服务器私钥对该授权访问凭证进行了签名。接下来，在步骤S906中，授权服务器400将该授权访问凭证返回给客户端装置200，然后在步骤S907中，客户端装置200利用授权访问凭证向资 源服务器500发送数据访问请求(即，申请数据访问)，并且在步骤S908中将该数据访问请求记录在区块链100中。应指出，该数据访问请求也包含客户端装置200的签名信息，即，客户端装置200利用客户端私钥对该数据访问请求进行了签名。接下来，在步骤S909中，资源服务器500通过检查区块链中的信息(包括在上述步骤S904、S905和S908中记录到区块链100中的信息)来确定该数据访问请求的有效性，并且如果确定有效，则将相应的数据资源提供给客户端装置200。同时，在步骤S910中，资源服务器500将自己的响应操作也记录到区块链100中，该记录同样也包含资源服务器500的签名信息(使用资源服务器的私钥)。最后，在步骤S911中，客户端装置200可以将相应的数据资源提供给资源所有者600供其进行使用。

应理解，上述交互过程仅为示例而非限制，并且所示出的各个步骤的执行顺序也仅是为了描述方便而不限于此，根据需要，一些步骤可并行地执行或者其执行顺序可改变。

从以上基于区块链的OAuth协议实现的交互过程可以看出，在该情况下，服务器装置可包括授权服务器和资源服务器，来自客户端装置的请求可包括针对授权服务器的对于授权访问凭证的请求和针对资源服务器的数据访问请求，并且来自服务器装置的响应信息可包括来自授权服务器的授权访问凭证和来自资源服务器的数据资源。此外，应指出，尽管在这里将授权服务器和资源服务器示出为分开的服务器装置，但是这两者实际上也可以是同一服务器。

优选地，上述授权访问凭证可包括与受保护资源有关的限制信息，该限制信息例如可包括受保护资源的管理者的标识、允许客户端装置访问的资源以及授权访问凭证的有效期等信息。

此外，优选地，限制信息还可包括在授权访问凭证的有效期内的访问次数设置，客户端装置200的访问单元230可根据访问次数设置而执行用于访问受保护资源的相应操作，并且服务器装置300的响应生成单元310可根据客户端装置200对受保护资源的访问而递减访问次数设置，并且记录单元320可将递减后的访问次数记录在公共数据库中。这样，可以防止重放攻击，有效地实现对于受保护资源的有限次授权访问。下面，将参照图10、图11A和图11B详细描述应用本公开的技术的用于实现有限次授权访问的处理过程。图10是示出应用本公开的技术的用于实现有限次授权访问的交互过程的示例的流程图，并且图11A和图11B是示出应用本 公开的技术的用于实现有限次授权访问的示例的示意图。

如图10所示，首先，在步骤S1001中，客户端装置200向授权服务器400申请N次授权访问(其中，N是大于或等于1的正整数)。然后，在步骤S1002中，授权服务器400针对这N次授权访问可生成两个比特币账户(或者也可使用已有账户)Account1和Account2，这两个账户分别对应两个密钥对，并且账户Account1由授权服务器400管理，账户Account2由资源服务器500管理，然后，授权服务器400将N个虚拟货币从账户Account1转至账户Account2(如图11A所示)，这N个虚拟货币即对应N次授权访问，同时授权服务器400将这次转账操作记录在区块链100中。

接下来，在步骤S1003中，授权服务器400将N次授权访问凭证和区块链100中的记录一起发送给客户端装置200，然后在步骤S1004中，客户端装置200可利用授权访问凭证访问资源服务器500，并且同时将区块链中的记录提供给资源服务器500。在步骤S1005中，资源服务器500可验证区块链中的记录以确认授权访问凭证是否有效，并且在步骤S1006中，如果确认有效，则资源服务器500为客户端装置200提供相应数据服务，并且如果无效，则资源服务器500拒绝提供相应服务。接下来，在步骤S1007中，针对每次访问，资源服务器500可从账户Account2转1个虚拟币至账户Account1(如图11B所示)，并同时将该转账操作记录在区块链100中。该转账信息也可同时提供给客户端装置200，以方便客户端装置200进行查验。重复上述操作，直到N次授权访问完成，即，完成了N次从账户Account2至账户Account1的转账操作，这样整个授权访问过程结束。

可以看出，在上述过程中，由于客户端装置200、授权服务器400和资源服务器500的操作以及访问次数限制均被记录在区块链100中，因此，各个装置可以通过检查区块链100中的相应记录信息来对各种信息进行核验，这样，可以有效地抵抗重放攻击和中间人攻击，提高授权访问过程的安全性，有效地实现有限次安全授权访问。

应理解，以上参照图10至图11B描述了基于区块链来实现有限次授权访问的处理过程，但是这仅是示例而非限制，并且本领域技术人员可以根据本公开的原理而对上述过程进行修改。例如，尽管以上描述了建立两个账户利用虚拟币来记录每次授权访问，但是也可不必如此，只要能够实现将客户端装置的每次授权访问都记录在公共数据库中，以供系统内的各 个装置进行查询、核验即可。

此外，还应指出，尽管以上以区块链为例描述了应用本公开的技术的OAuth协议的实现，但是显然也可利用除区块链之外的其它公共数据库(如上述Hyperledger的共识池等)来保证OAuth协议的通信安全性。

与上述装置实施例相对应的，下面将参照图12和图13分别描述根据本公开的实施例的在客户端装置和服务器装置侧执行的用于授权访问的方法的过程示例。图12是示出根据本公开的实施例的在客户端装置执行的用于授权访问的方法的过程示例的流程图。

如图12所示，根据该实施例的方法开始于步骤S1201，在步骤S1201中，客户端装置生成用于受保护资源的授权访问的请求并且将该请求发送到服务器装置，然后方法进行到步骤S1202。优选地，在步骤S1201中，客户端装置还可利用客户端私钥对该请求进行签名，并将签名后的请求发送给服务器装置。在步骤S1202中，客户端装置将所生成的请求记录在公共数据库中，该公共数据库是去中心化的分布式数据库并且其中的记录是不可更改的，优选地，该公共数据库包括区块链。然后，方法进行到步骤S1203。在步骤S1203中，客户端装置利用服务器装置响应于请求而发送的响应信息，执行用于访问受保护资源的相应操作。

优选地，客户端装置还将请求在公共数据库中的位置信息发送给服务器装置，并且可利用服务器公钥对服务器装置的响应信息在公共数据库中的记录进行验证，并且根据验证结果而执行相应操作。

优选地，在应用于OAuth协议时，上述服务器装置可包括授权服务器和资源服务器，并且这两个服务器也可以是同一服务器，请求可包括发送给授权服务器的对于授权访问凭证的请求和发送给资源服务器的数据访问请求，并且响应信息包括来自授权服务器的授权访问凭证和来自资源服务器的数据资源。优选地，授权访问凭证可包括与受保护资源有关的限制信息，该限制信息可包括受保护资源的管理者的标识、允许客户端装置访问的资源以及授权访问凭证的有效期。此外，优选地，限制信息还可包括在有效期内的访问次数设置，并且客户端装置可根据访问次数设置而执行用于访问受保护资源的相应操作。

这里描述的在客户端装置执行的方法是与上述装置实施例相对应的，因此在此未详细描述的内容可参见以上相应位置的描述，在此不再重复。

图13是示出根据本公开的实施例的在服务器装置执行的用于授权访 问的方法的过程示例的流程图。

如图13所示，根据该实施例的方法开始于步骤S1301，在步骤S1301中，服务器装置响应于来自客户端装置的对于受保护资源的授权访问的请求而生成相应的响应信息，并且将该响应信息发送到客户端装置。优选地，服务器装置可利用服务器私钥对该响应信息进行签名，并且将签名后的响应信息发送给客户端装置。然后，该方法进行到步骤S1302，在步骤S1302中，服务器装置将响应信息记录在公共数据库中。

优选地，服务器装置还将响应信息在公共数据库中的位置信息发送给客户端装置，并且利用客户端公钥对客户端装置的请求在公共数据库中的记录进行验证，并根据验证结果而生成响应信息。

这里描述的在服务器装置执行的方法是与上述装置实施例相对应的，因此在此未详细描述的内容可参见以上相应位置的描述，在此不再重复。

应指出，尽管以上描述了根据本公开的实施例的用于授权访问的方法的过程示例，但是这仅是示例而非限制，并且本领域技术人员可根据本公开的原理对以上实施例进行修改，例如可对各个实施例中的步骤进行添加、删除或者组合等，并且这样的修改均落入本公开的范围内。

根据本公开的技术还可以应用于其它领域，如医疗、通信、电力等。下面将参照图14和图15分别描述根据本公开的技术的应用示例。

图14是示出根据本公开的技术的第一应用示例的示意图。

在医疗领域中，需要存储大量用户的数据或记录，如何确保这些数据或记录可以通过安全授权访问的方式提供给用户或用户授权的第三方平台是当前要解决的问题之一。

如图14所示，该系统可包括用户、客户端、授权服务器、资源服务器和网络记录平台。用户是医疗数据的主体，即资源所有者；客户端是第三方应用软件(如健康管理软件等)；授权服务器是医疗机构或者医疗机构委托服务商提供服务；资源服务器是医疗机构或者医疗机构委托服务商提供服务；网络记录平台相当于上述公共数据库，其可以采用分布式或P2P、去中心化的网络平台，用于授权访问的关键数据一经记录在该平台上就不能被恶意篡改。此外，该记录平台为每条记录生成一条地址信息，该地址信息可以是序号或其它编码信息以便于进行检索。此外，尽管图中未示出，但是该系统还可包括密钥管理中心，用于为在网络记录平台上记录数据的实体生成密钥对(公钥和私钥)。密钥管理中心可以是第三方安 全平台，如公钥基础设施(Public Key Infrastructure，PKI)/认证中心(Certificate Authority，CA)等，也可以是基于网络记录平台的上层安全应用系统。

在具体实施时，首先进行系统初始化，从而密钥管理中心至少为授权服务器和资源服务器分配密钥对，分别记作(PK_AS,SK_AS)和(PK_RS,SK_RS)。

在初始化之后，各个实体按照图14所示的示例实施步骤而执行用于医疗数据的安全授权访问的处理：

①用户向授权服务器申请授权凭证。

②授权服务器向用户发放授权凭证。

③用户向客户端提供授权凭证。

④客户端向授权服务器提供用户的授权凭证，申请数据访问凭证。

⑤授权服务器验证授权凭证有效后，依据授权凭证的信息，生成对应的数据访问凭证，该数据访问凭证至少包含需要访问的目标数据、访问期限等信息。同时，授权服务器用自己的私钥SK_AS对该数据访问凭证进行签名，把签名后的信息记录在网络记录平台中。

⑥授权服务器将数据访问凭证以及该凭证在网络记录平台的地址信息返回给客户端。

⑦客户端持数据访问凭证和网络记录平台的地址信息向资源服务器申请数据资源。

⑧资源服务端根据地址信息，检索到对应数据访问凭证的记录，通过授权服务器的公钥PK_AS验证客户端发来的数据访问凭证的有效性。

⑨资源服务器依据数据访问凭证，向客户端提供对应的数据资源，同时把对于数据访问凭证的响应操作记录在网络记录平台中，即，使用私钥SK_RS对数据访问凭证进行签名，并且也可加入响应日志信息，一并签名后记录在网络记录平台。

⑩客户端得到对应的数据。

客户端将整理后的数据呈现给用户，例如，将该用户在多家医疗机构的医疗信息汇总、分类、整理后整体呈现给用户。

类似地，上述过程也可应用于诸如电力、通信或电商等存储了大量用户数据或记录的行业，在此不再一一详细进行描述。

图15是示出根据本公开的技术的第二应用示例的示意图。

3D打印是当前关注的热门技术，如何保证3D模型授权打印的安全性也是需要解决的问题之一。如图15所示，该用于3D模型授权打印的系统可包括用户、授权服务器、客户端、资源服务器、网络记录平台和3D打印机。其中，用户是购买3D模型数据的自然人或机构；客户端是第三方应用软件；授权服务器是3D模型网络交易平台；资源服务器是3D模型数据服务器；网络记录平台与以上参照图14描述的网络记录平台相同。此外，尽管未示出，该系统还包括与以上参照图14描述的相同的密钥管理中心。

在实施3D模型授权打印时，图15所示的步骤①～⑩中的操作与上述图14中的相应步骤中的操作相同，在此不再重复。接下来，在步骤中，客户端把授权得到的3D模型数据发送至3D打印机，并且在步骤中，用户得到打印出的3D物品。

在以上过程中，用户得到某个3D模型的打印授权(可以是免费或交易得到)，通过客户端连接授权服务器和资源服务器，通过本发明的授权协议方法得到3D模型数据，并且将该数据发送至3D打印机以得到打印出的3D物品。通过应用本公开的技术，可以保证授权访问的安全性和抗抵赖性，有效地抵抗了网络攻击。

尽管以上参照图14和图15给出了本公开的技术的应用示例，但是本公开并不限于此，而是也可应用于其它任何需要授权访问数据的平台。

此外，根据本公开的实施例，还提供了一种电子设备，该电子设备可包括收发机和一个或多个处理器，这一个或多个处理器可被配置成执行上述根据本公开的实施例的方法或相应单元的功能。

应理解，根据本公开的实施例的存储介质和程序产品中的机器可执行的指令还可以被配置成执行与上述装置实施例相对应的方法，因此在此未详细描述的内容可参考先前相应位置的描述，在此不再重复进行描述。

相应地，用于承载上述包括机器可执行的指令的程序产品的存储介质也包括在本发明的公开中。该存储介质包括但不限于软盘、光盘、磁光盘、存储卡、存储棒等等。

另外，还应该指出的是，上述系列处理和装置也可以通过软件和/或固件实现。在通过软件和/或固件实现的情况下，从存储介质或网络向具有专用硬件结构的计算机，例如图16所示的通用个人计算机1600安装构 成该软件的程序，该计算机在安装有各种程序时，能够执行各种功能等等。图16是示出作为本公开的实施例中可采用的信息处理设备的个人计算机的示例结构的框图。

在图16中，中央处理单元(CPU)1601根据只读存储器(ROM)1602中存储的程序或从存储部分1608加载到随机存取存储器(RAM)1603的程序执行各种处理。在RAM 1603中，也根据需要存储当CPU 1601执行各种处理等时所需的数据。

CPU 1601、ROM 1602和RAM 1603经由总线1604彼此连接。输入/输出接口1605也连接到总线1604。

下述部件连接到输入/输出接口1605：输入部分1606，包括键盘、鼠标等；输出部分1607，包括显示器，比如阴极射线管(CRT)、液晶显示器(LCD)等，和扬声器等；存储部分1608，包括硬盘等；和通信部分1609，包括网络接口卡比如LAN卡、调制解调器等。通信部分1609经由网络比如因特网执行通信处理。

根据需要，驱动器1610也连接到输入/输出接口1605。可拆卸介质1611比如磁盘、光盘、磁光盘、半导体存储器等等根据需要被安装在驱动器1610上，使得从中读出的计算机程序根据需要被安装到存储部分1608中。

在通过软件实现上述系列处理的情况下，从网络比如因特网或存储介质比如可拆卸介质1611安装构成软件的程序。

本领域的技术人员应当理解，这种存储介质不局限于图16所示的其中存储有程序、与设备相分离地分发以向用户提供程序的可拆卸介质1611。可拆卸介质1611的例子包含磁盘(包含软盘(注册商标))、光盘(包含光盘只读存储器(CD-ROM)和数字通用盘(DVD))、磁光盘(包含迷你盘(MD)(注册商标))和半导体存储器。或者，存储介质可以是ROM 1602、存储部分1608中包含的硬盘等等，其中存有程序，并且与包含它们的设备一起被分发给用户。

以上参照附图描述了本公开的优选实施例，但是本公开当然不限于以上示例。本领域技术人员可在所附权利要求的范围内得到各种变更和修改，并且应理解这些变更和修改自然将落入本公开的技术范围内。

例如，在以上实施例中包括在一个单元中的多个功能可以由分开的装置来实现。替选地，在以上实施例中由多个单元实现的多个功能可分别由 分开的装置来实现。另外，以上功能之一可由多个单元来实现。无需说，这样的配置包括在本公开的技术范围内。

在该说明书中，流程图中所描述的步骤不仅包括以所述顺序按时间序列执行的处理，而且包括并行地或单独地而不是必须按时间序列执行的处理。此外，甚至在按时间序列处理的步骤中，无需说，也可以适当地改变该顺序。

虽然已经详细说明了本公开及其优点，但是应当理解在不脱离由所附的权利要求所限定的本公开的精神和范围的情况下可以进行各种改变、替代和变换。而且，本公开实施例的术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、物品或者设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、物品或者设备所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括所述要素的过程、方法、物品或者设备中还存在另外的相同要素。