CN114079645A - 注册服务的方法及设备 - Google Patents

注册服务的方法及设备 Download PDF

Info

Publication number
CN114079645A
CN114079645A CN202010812614.5A CN202010812614A CN114079645A CN 114079645 A CN114079645 A CN 114079645A CN 202010812614 A CN202010812614 A CN 202010812614A CN 114079645 A CN114079645 A CN 114079645A
Authority
CN
China
Prior art keywords
party server
server
information
domain name
public key
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Granted
Application number
CN202010812614.5A
Other languages
English (en)
Other versions
CN114079645B (zh
Inventor
罗振辉
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Huawei Device Co Ltd
Petal Cloud Technology Co Ltd
Original Assignee
Huawei Technologies Co Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Huawei Technologies Co Ltd filed Critical Huawei Technologies Co Ltd
Priority to CN202010812614.5A priority Critical patent/CN114079645B/zh
Priority to US18/041,367 priority patent/US20230299973A1/en
Priority to PCT/CN2021/110184 priority patent/WO2022033350A1/zh
Priority to EP21855403.8A priority patent/EP4203377A4/en
Publication of CN114079645A publication Critical patent/CN114079645A/zh
Application granted granted Critical
Publication of CN114079645B publication Critical patent/CN114079645B/zh
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/12—Applying verification of the received information
    • H04L63/126—Applying verification of the received information the source of the received data
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3247—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving digital signatures
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L61/00—Network arrangements, protocols or services for addressing or naming
    • H04L61/45—Network directories; Name-to-address mapping
    • H04L61/4505—Network directories; Name-to-address mapping using standardised directories; using standardised directory access protocols
    • H04L61/4511—Network directories; Name-to-address mapping using standardised directories; using standardised directory access protocols using domain name system [DNS]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/02—Protocols based on web technology, e.g. hypertext transfer protocol [HTTP]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/321—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving a third party or a trusted authority
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/40—Network security protocols
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/50—Network services
    • H04L67/55—Push-based network services

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computer Hardware Design (AREA)
  • Computing Systems (AREA)
  • General Engineering & Computer Science (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)
  • Information Transfer Between Computers (AREA)

Abstract

本申请提供一种注册服务的方法及设备，该方法包括：接收第三方服务器发送的注册请求，注册请求包括第一信息、第二信息和第三信息，第一信息用于指示第三方服务器的公钥地址，公钥地址包括第一域名，第二信息用于指示事件信息的投递地址，投递地址包括第二域名，第三信息用于指示目标DNS记录，目标DNS记录包括第三方服务器的数字签名；在第一域名与第二域名相同时，根据第一信息获取第三方服务器的公钥；根据第三信息获取目标DNS记录；在获取到第三方服务器的公钥和目标DNS记录时，根据第三方服务器的公钥对数字签名进行验签，得到验签结果；根据验签结果确定是否允许第三方服务器进行注册。该技术方案能够提升事件投递过程的安全性。

Description

注册服务的方法及设备
技术领域
本申请涉及通信技术领域，并且更具体地，涉及一种注册服务的方法及设备。
背景技术
随着通信技术和安全认证技术的不断发展，目前绝大部分的网站和应用程序都支持多种登录方式，即可以不用在该网络或应用程序的服务器上注册账号，而使用其他网站或应用的已有账号登录，例如社交账号、支付账号、开放的身份标识(open identitydocument，openID)账号等。即用户可以使用已有的非第三方应用或非第三方网站的账号登录第三方应用或第三方网站。
在一些场景下，为了保障账号安全或方便推送账号消息，第三方可以向账号所属方注册事件投递服务，当有第三方关注的事件或消息时，账号所属方将事件信息投递给第三方。
目前第三方向账号所属方提交注册请求后，账号所属方进行接口鉴权(interfaceauthentication)例如OAuth认证后，就完成了注册流程，而对注册请求中信息没有校验，导致存在一定安全风险。
发明内容
本申请提供注册服务的方法及设备，能够提升事件投递过程的安全性。
第一方面，提供了一种注册服务的方法，包括：接收第三方服务器发送的注册请求，所述注册请求用于请求注册事件投递服务，所述注册请求包括第一信息、第二信息和第三信息，其中，所述第一信息用于指示所述第三方服务器的公钥地址，所述公钥地址包括第一域名，所述第二信息用于指示事件信息的投递地址，所述投递地址包括第二域名，所述第三信息用于指示域名系统DNS服务器上的目标DNS记录，所述目标DNS记录包括所述第三方服务器使用所述第三方服务器的私钥创建的数字签名；在所述第一域名与所述第二域名相同的情况下，根据所述第一信息尝试获取所述第三方服务器的公钥；以及根据所述第三信息尝试获取所述目标DNS记录；在获取到所述第三方服务器的公钥和所述目标DNS记录的情况下，根据所述第三方服务器的公钥，对所述目标DNS记录中的数字签名进行验签，得到验签结果；根据所述验签结果确定是否允许所述第三方服务器进行注册。
本申请实施例中，提供事件投递服务的设备根据注册请求中的信息对第三方服务器的域名拥有权进行验证，可以减少事件投递信息被投递到未经校验的投递地址中而被恶意设备窃取的风险，提升事件投递过程的安全性。
具体地，本申请实施例提供的注册服务的方法中，在第三方服务器注册事件投递服务过程中，对第三方服务器对投递地址指定的域名的合法拥有权进行了校验，通过校验第三方服务器是否具备DNS记录增加权限以及校验第三方服务器的签名，可以有效提升事件投递过程中的安全性。当第一服务器确定第三方服务器对投递地址中的域名没有域名拥有权时，第一服务器可以拒绝第三方服务器注册服务。这样可以避免仿冒问题，减少投递事件被盗取的风险，保证事件投递过程的安全可靠，提升第一服务器将事件信息共享给第三方的安全性。
结合第一方面，在一种可能的实现方式中，所述第三信息包括关键词，所述根据所述第三信息尝试获取所述目标DNS记录，包括：根据所述关键词，在所述DNS服务器上查询所述目标DNS记录。
该关键词用于查询目标DNS记录。
结合第一方面，在一种可能的实现方式中，所述目标DNS记录包括基于JSON对象的网络令牌JWT，所述JWT包括所述数字签名。
JWT为自包含的访问令牌，能够在身份提供者和服务提供者间传递安全可靠的信息。
结合第一方面，在一种可能的实现方式中，所述JWT包括以下信息中的至少一种：第三域名，所述第三域名用于指示所述JWT的签发者；所述第三方服务器对应的第三方开发者的标识；所述第三方服务器对应的应用标识，其中所述应用标识用于标识所述第三方服务器对应的应用。
第三方服务器对应的第三方开发者的标识或第三方服务器对应的应用标识可用于标识第三方服务器对应的应用。
结合第一方面，在一种可能的实现方式中，所述根据所述第三方服务器的公钥，对所述目标DNS记录中的数字签名进行验签，包括：提取所述目标DNS记录中的校验串；在提取到所述校验串的情况下，根据所述第三方服务器的公钥对所述校验串进行验签。
结合第一方面，在一种可能的实现方式中，所述第一信息承载于第一字段，所述第三信息承载于第三字段，所述第一字段与所述第三字段属于同一节点。
结合第一方面，在一种可能的实现方式中，还包括：在所述第一域名与所述第二域名不同的情况下，确定不允许所述第三方服务器进行注册；或者，在未获取到所述第三方服务器的公钥和/或所述目标DNS记录的情况下，确定不允许所述第三方服务器进行注册。
在第一域名与第二域名不同时拒绝第三方服务器的注册，可以避免一些仿冒风险，提升事件投递过程的安全性。
在未获取到第三方服务器的公钥和/或目标DNS记录时拒绝第三方服务器的注册，可以避免一些仿冒风险，提升事件投递过程的安全性。
结合第一方面，在一种可能的实现方式中，还包括：在未提取到所述校验串的情况下，确定不允许所述第三方服务器进行注册。
结合第一方面，在一种可能的实现方式中，所述事件投递服务包括开放的身份标识openID账号风险事件投递。
第二方面，提供了一种注册服务的方法，包括：接收第三方服务器发送的注册请求，所述注册请求用于请求注册事件投递服务，所述注册请求包括第一信息、第二信息和第三信息，其中，所述第一信息用于指示所述第三方服务器的公钥地址，所述公钥地址包括第一域名，所述第二信息用于指示事件信息的投递地址，所述投递地址包括第二域名，所述第三信息用于指示域名系统DNS服务器上的目标DNS记录，所述目标DNS记录包括所述第三方服务器使用所述第三方服务器的私钥创建的数字签名和所述第三方服务器对应的应用标识，所述应用标识用于标识所述第三方服务器对应的应用；在所述第一域名与所述第二域名相同的情况下，根据所述第一信息尝试获取所述第三方服务器的公钥；以及根据所述第三信息尝试获取所述目标DNS记录；在获取到所述第三方服务器的公钥和所述目标DNS记录的情况下，根据所述第三方服务器的公钥，对所述目标DNS记录中的数字签名进行验签，得到验签结果；在所述验签结果通过的情况下，根据所述第三方服务器对应的应用标识，获取所述第三方服务器对应的应用的重定向地址，所述重定向地址包括第四域名；在所述第二域名与所述第四域名相同的情况下，确定允许所述第三方服务器进行注册。
本申请实施例中，提供事件投递服务的设备根据注册请求中的信息对第三方服务器的域名拥有权进行验证，可以减少事件投递信息被投递到未经校验的投递地址中而被恶意设备窃取的风险，提升事件投递过程的安全性。
具体地，本申请实施例提供的注册服务的方法中，在第三方服务器注册事件投递服务过程中，对第三方服务器对投递地址指定的域名的合法拥有权进行了校验，通过校验第三方服务器是否具备DNS记录增加权限以及校验第三方服务器的签名，可以有效提升事件投递过程中的安全性。当第一服务器确定第三方服务器对投递地址中的域名没有域名拥有权时，第一服务器可以拒绝第三方服务器注册服务。这样可以避免仿冒问题，减少投递事件被盗取的风险，保证事件投递过程的安全可靠，提升第一服务器将事件信息共享给第三方的安全性，并且可以避免将事件信息投递给未在第一服务器注册账号的第三方。
结合第二方面，在一种可能的实现方式中，所述第三信息包括关键词，所述根据所述第三信息尝试获取所述目标DNS记录，包括：根据所述关键词，在所述DNS服务器上查询所述目标DNS记录。
结合第二方面，在一种可能的实现方式中，所述目标DNS记录包括基于JSON对象的网络令牌JWT，所述JWT包括所述数字签名。
结合第二方面，在一种可能的实现方式中，所述JWT包括以下信息中的至少一种：第三域名，所述第三域名用于指示所述JWT的签发者；所述第三方服务器对应的第三方开发者的标识；所述第三方服务器对应的应用标识。
结合第二方面，在一种可能的实现方式中，所述根据所述第三方服务器的公钥，对所述目标DNS记录中的数字签名进行验签，包括：提取所述目标DNS记录中的校验串；在提取到所述校验串的情况下，根据所述第三方服务器的公钥对所述校验串进行验签。
结合第二方面，在一种可能的实现方式中，所述第一信息承载于第一字段，所述第三信息承载于第三字段，所述第一字段与所述第三字段属于同一节点。
结合第二方面，在一种可能的实现方式中，还包括：在所述第一域名与所述第二域名不同的情况下，确定不允许所述第三方服务器进行注册；或者，在未获取到所述第三方服务器的公钥和/或所述目标DNS记录的情况下，确定不允许所述第三方服务器进行注册；或者，在所述验签结果不通过的情况下，确定不允许所述第三方服务器进行注册；或者，在所述第二域名与所述第四域名不同的情况下，确定不允许所述第三方服务器进行注册。
结合第二方面，在一种可能的实现方式中，还包括：在未提取到所述校验串的情况下，确定不允许所述第三方服务器进行注册。
结合第二方面，在一种可能的实现方式中，所述事件投递服务包括openID账号风险事件投递。
第三方面，提供了一种注册服务的方法，包括：第三方服务器向第一服务器发送注册请求，所述注册请求用于请求注册事件投递服务，所述注册请求包括第一信息、第二信息和第三信息，其中，所述第一信息用于指示所述第三方服务器的公钥地址，所述公钥地址包括第一域名，所述第二信息用于指示事件信息的投递地址，所述投递地址包括第二域名，所述第三信息用于指示域名系统DNS服务器上的目标DNS记录，所述目标DNS记录包括所述第三方服务器使用所述第三方服务器的私钥创建的数字签名，其中，所述第三方服务器的公钥地址对应的公钥用于所述第一服务器在所述第一域名与所述第二域名相同的情况下，对所述数字签名进行验签，以确定是否允许所述第三方服务器进行注册。
第三方服务器注册事件投递服务时，向第一服务器提供上述第一信息、第二信息和第三信息，能够使第一服务器对第三方服务器对投递地址指定的域名的合法拥有权进行校验，从而有效提升事件投递过程中的安全性。
结合第三方面，在一种可能的实现方式中，在所述第三方服务器向第一服务器发送注册请求之前，还包括：所述第三方服务器将所述目标DNS记录写入所述DNS服务器中。
结合第三方面，在一种可能的实现方式中，所述第一信息承载于第一字段，所述第三信息承载于第三字段，所述第一字段与所述第三字段属于同一节点。
结合第三方面，在一种可能的实现方式中，所述事件投递服务包括openID账号风险事件投递。
第四方面，提供了一种注册服务的方法，包括：第三方服务器向第一服务器发送注册请求，所述注册请求用于请求注册事件投递服务，所述注册请求包括第一信息、第二信息和第三信息，其中，所述第一信息用于指示所述第三方服务器的公钥地址，所述公钥地址包括第一域名，所述第二信息用于指示事件信息的投递地址，所述投递地址包括第二域名，所述第三信息用于指示域名系统DNS服务器上的目标DNS记录，所述目标DNS记录包括所述第三方服务器使用所述第三方服务器的私钥创建的数字签名和所述第三方服务器对应的应用标识，其中所述第三方服务器的公钥地址对应的公钥用于所述第一服务器在所述第一域名与所述第二域名相同的情况下对所述数字签名进行验签，所述第三方服务器对应的应用标识用于指示所述第三方服务器对应的应用的重定向地址，所述重定向地址用于标识所述第三方服务器对应的应用，所述重定向地址包括第四域名，所述第四域名与所述第二域名是否相同用于确定是否允许所述第三方服务器进行注册。
第三方服务器注册事件投递服务时，向第一服务器提供上述第一信息、第二信息和第三信息，能够使第一服务器对第三方服务器对投递地址指定的域名的合法拥有权进行校验，从而有效提升事件投递过程中的安全性。
结合第四方面，在一种可能的实现方式中，在所述第三方服务器向第一服务器发送注册请求之前，还包括：所述第三方服务器将所述目标DNS记录写入所述DNS服务器中。
结合第四方面，在一种可能的实现方式中，所述第一信息承载于第一字段，所述第三信息承载于第三字段，所述第一字段与所述第三字段属于同一节点。
结合第四方面，在一种可能的实现方式中，所述事件投递服务包括openID账号风险事件投递。
第五方面，提供了一种设备，包括用于执行上述第一方面或第一方面中任一种可能实现方式中的方法的模块或单元，或者用于执行上述第二方面或第二方面中任一种可能实现方式中的方法的模块或单元。该模块或单元可以是硬件电路，也可是软件，也可以是硬件电路结合软件实现。
可选地，该设备可以为上文提及的第一服务器。
第六方面，提供了一种设备，包括用于执行上述第三方面或第三方面中任一种可能实现方式中的方法的模块或单元，或者包括用于执行上述第四方面或第四方面中任一种可能实现方式中的方法的模块或单元。该模块或单元可以是硬件电路，也可是软件，也可以是硬件电路结合软件实现。
可选地，该设备可以为上文提及的第三方服务器。
第七方面，提供了一种装置，包括处理器和存储器，所述存储器存储有指令，所述处理器用于从所述存储器中调用并执行所述指令，使得所述装置执行上述第一方面或第一方面中任一种可能实现方式中的方法，或者执行上述第二方面或第二方面中任一种可能实现方式中的方法。
可选地，所述装置还包括收发器。
第八方面，提供了一种装置，包括处理器和存储器，所述存储器存储有指令，所述处理器用于从所述存储器中调用并执行所述指令，使得所述装置执行上述第三方面或第三方面中任一种可能实现方式中的方法，或者执行上述第四方面或第四方面中任一种可能实现方式中的方法。
可选地，所述装置还包括收发器。
第九方面，提供了一种装置，所述装置包括：至少一个处理器和通信接口，所述通信接口用于所述装置与其他装置进行信息交互，当程序指令在所述至少一个处理器中执行时，使得所述装置执行上述第一方面或第一方面中任一种可能实现方式中的方法，或者执行上述第二方面或第二方面中任一种可能实现方式中的方法。
可选地，所述通信接口可以为收发器、电路、总线、模块、管脚或其它类型通信接口。
可选地，该装置还包括存储器，所述存储器用于存储指令和数据，所述处理器执行所述存储器中存储的指令时，可以实现上述第一方面或第一方面的任一种可能的实现方式中描述的方法，或者执行上述第二方面或第二方面中任一种可能实现方式中的方法。
第十方面，提供了一种装置，所述装置包括：至少一个处理器和通信接口，所述通信接口用于所述装置与其他装置进行信息交互，当程序指令在所述至少一个处理器中执行时，使得所述装置执行上述第三方面或第三方面中任一种可能实现方式中的方法，或者执行上述第四方面或第四方面中任一种可能实现方式中的方法。
可选地，所述通信接口可以为收发器、电路、总线、模块、管脚或其它类型通信接口。
可选地，该装置还包括存储器，所述存储器用于存储指令和数据，所述处理器执行所述存储器中存储的指令时，可以实现上述第三方面或第三方面中任一种可能实现方式中的方法，或者执行上述第四方面或第四方面中任一种可能实现方式中的方法。
第十一方面，提供一种计算机可读存储介质，所述计算机可读存储介质中存储有计算机程序，当所述计算机程序在计算机上运行时，使得所述计算机执行上述第一方面或第一方面的任一种可能的实现方式所述的方法，或者执行上述第二方面或第二方面中任一种可能实现方式中的方法。
第十二方面，提供一种计算机可读存储介质，所述计算机可读存储介质中存储有计算机程序，当所述计算机程序在计算机上运行时，使得所述计算机执行上述第三方面或第三方面的任一种可能的实现方式所述的方法，或者执行上述第四方面或第四方面中任一种可能实现方式中的方法。
第十三方面，提供一种包含指令的计算机程序产品，当该计算机程序产品在计算机上运行时，使得计算机执行上述第一方面或第一方面的任一种可能的实现方式所述的方法，或者执行上述第二方面或第二方面中任一种可能实现方式中的方法。
第十四方面，提供一种包含指令的计算机程序产品，当该计算机程序产品在计算机上运行时，使得计算机执行上述第三方面或第三方面的任一种可能的实现方式所述的方法，或者执行上述第四方面或第四方面中任一种可能实现方式中的方法。
第十五方面，提供一种注册服务的系统，包括上述第一方面描述的第一服务器和第三方面描述的第三方服务器；或者该系统包括第二方面描述的第一服务器和第四方面描述的第三方服务器。
附图说明
图1是本申请实施例的一种应用场景的示意图；
图2是本申请实施例提供的一种RISC服务架构的示意性框图；
图3是现有一种RISC流程的示意性交互图；
图4是本申请实施例提供的注册服务的方法的示意性流程图；
图5是本申请实施例提供的注册服务的方法的示意性流程图；
图6是本申请实施例提供的注册服务的方法的示意性流程图；
图7是本申请实施例提供的一种注册服务的方法的示意性交互图；
图8是本申请实施例提供的一种设备的示意性框图；
图9是本申请实施例提供的另一种设备的示意性框图；
图10是本申请实施例提供的一种装置的示意性框图；
图11是本申请实施例提供的一种装置的示意性框图。
具体实施方式
下面将结合附图，对本申请中的技术方案进行描述。为方便理解，下面首先介绍本申请中涉及的相关概念。
统一资源标识符(uniform resource identifier，URI)：用来标识抽象或物理资源的字符串，用于唯一标识一个资源。URI一般包括三部分：访问资源的命名机制、存放资源的主机名、资源自身的名称。
统一资源定位符(uniform resource locator，URL)：为一种定位资源的主要访问机制的字符串，不仅可以唯一标识一个资源，还可以提供定位该资源信息。URL一般包括三部分：协议(或称为服务方式)、存有该资源的主机IP地址、主机资源的具体地址例如目录和文件名等。URI属于父类，URL属于URI的子类，是URI概念的一种实现方式。
开放的身份标识(open identity document，OpenID)：是一个以URL为身份标识的分散式身份验证解决方案，具有开放性和分散性。一个OpenID身份就是一个URL，用户可以通过一个URL在多个网站进行登录，作为用户的身份认证。OpenID账号的获取流程主要为，用户在OpenID服务器网站进行注册，然后获得一个URL，该URL即为用户名，相应的密码存储于OpenID服务网站上。拥有了合法的OpenID账号后，用户可以使用该OpenID账号登录任何一个支持OpenID验证的网站。在登录时，登录网站会请求OpenID服务网站验证用户身份，验证通过后即成功登录。OpenID系统可以应用于所有需要身份验证的地方，既可以应用于单点登录系统，也可以用于共享敏感数据时的身份认证。
公钥密码(public key cryptography)：也称为非对称密码，是一类密码算法，需要两个单独的密钥，其中之一是保密的私有密钥(私钥)，另一个是公开密钥(公钥)。公私钥这两个部分在数学上是联系在一起的。公钥用于加密明文或验证数字签名(即验签)；而私钥用于解密密文或创建数字签名(即签名)。
数字签名(digital signature)：用于演示数字消息或文档的真实性的数学方案。有效的数字签名可以让接收者判定该消息是由已知的发送者(认证)创建的，发送方不能否认对消息签过名(不可否认性)。同时验证数字签名还可以确认消息在传输(完整性)中未被更改。
证书(certificate)和证书授权(certificate authority，CA)：在密码学中，证书授权CA中心是颁发数字证书的实体。数字证书通过证书的指定主题证明公钥的所有权。这允许其他(依赖方)依赖签名或关于对应于认证公钥的私钥的断言。在这种信任关系模型中，CA是受信任的第三方，由证书的主体(所有者)和依赖证书的一方信任。许多公钥基础设施(public key infrastructure，PKI)方案都采用CA。
签名和验签过程：1)发送端对需要传输的原文做哈希(HASH)运算，得到数字摘要；2)发送端使用自己的私钥加密数字摘要，被加密的数字摘要即为签名；3)发送端将原文和数字签名发送给接收端；4)接收端使用发送端的公钥解密签名，得到数字摘要；5)接收端使用与发送端相同的方法对原文计算摘要值，并与解密得到的数字摘要进行对比，二者完全一致，证明原文在传输过程中没有被篡改过。
基于JSON对象的网络令牌(json web token，JWT)：是一个自包含的访问令牌，一般被用来在身份提供者和服务提供者间传递安全可靠的信息，常用于跨域身份验证。JWT以JSON对象的形式安全传递信息，由于存在数字签名，因此所传递的信息是安全的。一个JWT实际上是一个字符串，它包含了使用(.)分隔的三部分：头部(header)、负载(payload)、签名(signature)(格式：header.payload.signature)。其中签名(signature)被用来确认JWT信息的发送者是谁，并保证信息没有被篡改。签名是使用header中指定的算法将编码后的header、编码后的payload、一个私钥进行加密得到的。
域名系统(domain name system，DNS)：是建立在数据库上的分层命名系统，用于完成域名和IP地址的转换工作。资源记录(resource records)，也称DNS记录，是指每个域所包含的与之相关的资源，如具有特殊功能的一个个数据条目。根据使用场景，DNS记录可以分成不同的类型(type)，例如地址(address，A)记录、邮件交换(mail exchanger，MX)记录、域名服务器(name server，NS)记录、别名(canonical name，CNAME)记录、文本(TXT)记录、存留时间(time-to-live，TTL)记录、指针(pointer，PTR)记录、公钥(KEY)记录等。只有具有域名拥有权的人才能在域名系统中增加DNS记录，即具备域名的DNS维护权限可以证明具有该域名拥有权。
域名解析工具：包括dig命令、host命令、nslookup命令、whois命令等。其中dig命令可以单独查看每一级域名的NS记录；host命令可以返回当前请求域名的各种记录；nslookup命令用于互动式地查询域名记录；whois命令用来查看域名的注册情况。
图1示出了本申请实施例的一种应用场景的示意图。如图1中的(a)所示，该应用场景中可以包括第一服务器110、第三方服务器120和终端设备130。
第一服务器110和第三方服务器120用于为终端设备130提供计算或应用服务，例如可以为应用服务器、通信服务器(例如邮件服务器、传真服务器、文件传输协议(filetransfer protocol，FTP)服务器等)、网站服务器、数据库服务器等，还可以是工作组级服务器、部门级服务器、企业级服务器等。
终端设备130为能够在服务器上注册服务的设备，例如手机、平板电脑、可穿戴设备、车载设备、增强现实(augmented reality，AR)/虚拟现实(virtual reality，VR)设备、笔记本电脑、超级移动个人计算机(ultra-mobile personal computer，UMPC)、上网本、个人数字助理(personal digital assistant，PDA)、电视等。
本申请实施例中第一服务器110既可以为用户提供账号身份管理和认证服务，还可以提供账号事件投递服务。用户可以在第一服务器110上注册账号，以更好地体验第一服务器110对应的网站(website，Web)或应用程序(application，APP)提供的服务。随着通信技术和安全认证技术的不断发展，在第一服务器110上注册的账号不仅可以用来登录第一服务器110对应的应用，还可以用来登录第三方服务器120对应的第三方应用或网站。另外，与第一服务器110上注册的账号有关的信息不仅可以由第一服务器110投递至终端设备130，还可以由第一服务器110投递至第三方服务器120，经第三方服务器120投递至终端设备130。下面参考图1举例说明。
例如，用户M在第一服务器110上注册了账号A，并且授权第三方服务器120通过与第三方服务器120对应的第三方应用客户端向用户M推送该账号A的相关信息。这种情况下，第三方服务器120可以向第一服务器110注册账号事件投递服务，当与账号A有关的信息需要推送给用户M时，第一服务器110可以将信息推送给第三方服务器120，然后由第三方服务器120与终端设备130上的第三方应用客户端交互，将信息发送到第三方应用客户端上，方便用户M查看。示例性的，用户M在某社交应用对应的社交应用服务器(第一服务器110)上注册账号A，用户M可以授权第三方应用客户端，如邮箱应用客户端，对应的邮箱服务器(第三方服务器120)将与该账号A有关的账号风险信息推送给邮箱服务器(第三方服务器120)对应的应用客户端如邮箱应用客户端。当用户M的账号A发生风险时，社交应用服务器(第一服务器110)将账号风险事件投递给邮箱服务器(第三方服务器120)，然后由邮箱服务器(第三方服务器120)与邮箱应用客户端交互，方便用户M及时了解账户A存在的风险。
又如，第一服务器110用于管理某个应用(或网站)的账号信息，第三方服务器120可以在第一服务器110上注册投递服务，使得第一服务器110将与账号有关的信息(例如对账号有关信息的统计规律、大数据分析结果等)发送给第三方服务器120，方便第三方服务器120的用户查看、使用收到的信息。
再如，用户M在第一服务器110上注册了账号A，用户M可以使用该账号A登录第三方服务器120对应的第三方应用(或网站)，例如用户M可以在某社交应用对应的社交应用服务器(第一服务器110)上注册账号A，之后使用该社交应用的账号A登录一个支付应用服务器(第三方服务器120)对应的支付应用(第三方应用)。这种情形下，第三方服务器120在第一服务器110上注册账号事件投递服务，当用户M的账号A发生账号风险时，第一服务器110可以将风险事件投递给第三方服务器120，然后由第三方服务器120与终端设备130上的第三方应用(或网站)交互，以及时作出响应，例如退出登录或注销账号等。
但不管第三方服务器120是用于推送信息还是协助保障账号安全，第三方服务器120都需要先完成账号事件投递服务的注册过程，例如图1中(a)所示的“①注册服务”过程，才能接收到账号风险事件、账号有关信息等，例如图1中(a)所示的“②投递/推送”过程。
图1(a)中的第一服务器110既用于提供账号身份管理和认证服务，还用于提供账号事件投递服务，第三方服务器120可以直接向第一服务器110注册账号事件投递服务，在第一服务器110识别到账号事件时即可向第三方服务器120投递。在另一些实施例中，账号身份管理和认证服务与账号事件投递服务还可以分别部署于不同的服务器上。如图1中的(b)所示，第二服务器140用于提供账号身份管理和认证服务，第一服务器110用于提供账号事件投递服务。用户在第二服务器140上注册账号，注册过程与图1中(a)所述的情况类似，不再赘述。而第三方服务器120可以直接与第一服务器110交互，以注册账号事件投递服务。第一服务器110需要从第二服务器140处获得账号事件，才能将账号事件投递给第三方服务器120。
目前很多第三方网站都支持openID账号登录。用户可以在openID服务器上注册openID账号，并使用注册好的openID账号登录第三方服务器对应的第三方应用或网站。以图1中的(a)为例，第一服务器110可以作为openID服务器，该第一服务器110既用于提供openID账号身份管理和认证服务，还用于提供openID账号事件投递服务；这种情况下，第三方服务器120可以在第一服务器110注册openID账号事件投递服务，当用户的openID账号发生风险事件时，第一服务器110可以将账号风险事件投递给第三方服务器120，以使第三方服务器120及时作出响应。以图1中的(b)为例，第二服务器140也可以作为openID服务器，那么第二服务器140用于提供openID账号身份管理和认证服务，而第一服务器110用作openID账号事件投递服务；这种情况下，第三方服务器120与第一服务器110交互，以注册openID账号事件投递服务，第一服务器110需要从第二服务器140处获得openID账号事件，才能将openID账号事件投递给第三方服务器120。
为了规范openID账号事件投递服务，OPENID组织专门定义了一种帐号风险和事件共享和协调器(risk and incident sharing and coordination，RISC)，也称RISC规范，主要描述了将帐号持有方侧产生的或者识别到的异常帐号风险和事件通知到该帐号经过用户授权的第三方服务器上，以方便与第三方服务快速做出响应。
本申请实施例中，某个服务器用于提供openID账号事件投递服务，也可以称为该服务器用于提供RISC服务。图1的(a)和(b)中第一服务器110均用于提供账号事件投递服务，为方便理解，本申请以下实施例以第一服务器110为提供RISC服务的服务器为例进行说明。
图2是本申请实施例提供的一种RISC服务架构的示意性框图。如图2中的(a)所示，该服务架构主要包括第三方服务器210和第一服务器220。
第三方服务器210为向第一服务器220注册RISC服务的设备。该第三方服务器210可以为第三方应用的服务器，或者为第三方网站的服务器，本申请实施例不做限定。一般地，用户可以使用openID账号登录该第三方服务器210所对应的应用或网站。
第一服务器220为提供账号身份管理和认证服务以及RISC服务的设备。不同的服务可以由同一服务提供商提供，即某个服务提供商既可以提供账号身份管理和认证服务服务，还可以提供RISC服务。RISC服务和账号身份管理和认证服务也可以分别由不同的服务提供商提供，本申请实施例不做限定。如图2中的(a)所示，账号身份管理和认证服务和RISC服务部署于同一设备即第一服务器220上，第一服务器220可以识别账号风险事件，并向第三方服务器210投递账号风险事件。
具体地，第一服务器210上部署有账号系统，例如云端账号系统(cloud accountsystem)，还部署有RISC服务，RISC服务与账号系统之间设置有分布式消息队列(distributed message queue，DMQ)中间件。其中账号系统也可称为身份认证系统(identity authentication system)，用于提供账号身份管理和认证服务，还可以为RISC服务提供账号风险事件。示例性的，账号系统具体可以包括账号风控系统、账号管理系统、授权和鉴权系统等。其中账号风控系统主要负责账号风险评估，该系统可以为RISC服务提供被盗账号、垃圾账号等事件信息。账号管理系统主要负责账号的注册、密码修改、登录、注销等基本功能管理，该系统可以为RISC服务提供登录失败、账号冻结、账号解冻、账号删除、账号销户、重置密码等事件信息。授权和鉴权系统主要负责账号权限授予、凭据颁发和访问时鉴权等功能，该系统可以为RISC服务提供凭据吊销等事件信息。授权和鉴权系统可以基于OAuth进行认证和授权。RISC服务用于实现账号事件投递服务的注册过程以及账号事件的投递过程。
参考图2中的(a)所示，第三方服务器210需要向第一服务器220上部署的RISC服务发送注册请求，以完成账号事件投递服务的注册过程(即完成图中所示的注册服务的过程)。当第一服务器220上部署的账号系统产生或识别到账号发生风险时将账号风险事件发布到DMQ上。RISC服务从DMQ上获取账号风险事件，然后将账号风险事件投递给第三方服务器210。这里分布式消息队列中间件DMQ可以是一个队列处理器，用于支持和保障组件之间可靠的异步通信。在一些实施例中，RISC服务可以根据RISC协议实现。
图2中的(a)中账号系统与RISC服务部署于同一设备上，例如部署于同一服务器上的不同模块。在另一些实施例中，账号系统与RISC服务可以部署于不同设备上。如图2中的(b)所示，RISC服务架构包括第三方服务器210、用于提供RISC服务的第一服务器220、以及用于提供账号身份管理和认证服务的第二服务器230。
具体地，第三方服务器210为向第一服务器220注册RISC服务的设备。第一服务器220为部署了RISC服务的设备(RISC provider)。第二服务器230为部署了账号系统的设备。RISC服务可以进行跨账号管理，RISC服务与账号系统可以构成一个消息发布/订阅系统，其中RISC服务与账号系统之间设置有分布式消息队列(distributed message queue，DMQ)中间件240。第三方服务器210需要先向第一服务器220上部署的RISC服务发送注册请求，以完成账号事件投递服务的注册过程。第二服务器230上部署的账号系统可以为第一服务器220部署的RISC服务提供账号风险事件。当第二服务器230在产生或识别到账号发生风险时将账号风险事件发布到DMQ 240上，第一服务器210从DMQ 240上订阅并消费账号风险事件，即第一服务器210获取到账号风险事件后，将账号风险事件投递给第三方服务器210。
图2中(b)所示的DMQ 240可以部署于第一服务器220，也可以部署于第二服务器230，还可以单独部署于其他设备上，本申请实施例不做限定。另外，图2中(b)关于RISC服务和账号系统的描述可参考图2中的(a)的相关描述，为简洁，在此不再赘述。
如上所述，图2(b)中RISC服务和账号身份管理和认证服务分别部署于第一服务器220和第二服务器230上，其中第一服务器220和第二服务器230可以属于同一服务器集群，也可以属于不同服务器集群。
综上，参考图2中的(a)和(b)，第三方服务器210要使用RISC服务，则需要事先注册事件关注注册表，向第一服务器220请求注册所关注的事件。这样在产生第三方服务器210所关注的事件时，提供RISC服务的第一服务器220可访问外网，并进行事件投递，将账号事件消息投递给第三方服务器210。该过程即为图2中所标注的“①注册服务”和“②事件投递”过程。下面结合图3详细描述该过程。
图3示出了现有一种RISC流程的示意性交互图。如图3所示，该过程主要包括以下几个步骤：
在步骤S301，第三方服务器向第一服务器(即RISC服务提供者)发送注册请求，该注册请求用于请求注册事件关注注册表。具体地，第三方服务器在注册请求中会指定关注的事件类型以及事件投递方式。这里第三方服务器关注的事件类型即第三方服务器感兴趣的事件类型例如图2中的账号系统所发布的事件等，具体可参考RISC规范(即RISC标准协议)中定义的事件，在此不再详述。
参考现有RISC规范(具体可参考《4.1.2.2“更新注册表配置(updating a stream’s configuration)”》章节中的协议内容)，第三方服务器注册RISC注册表(stream)的一个示例如下，其中“delivery_method”字段指定了事件投递方式，“url”字段指定了投递地址，“events_requested”字段指定了关注的事件类型。
Figure BDA0002631581560000111
在步骤S302，第一服务器对注册请求进行接口权限认证，鉴权通过后生成注册表。
接口权限认证即接口鉴权(interface authentication)，用于验证设备身份，以进行访问权限控制。例如上述给出的注册表示例中，可以采用Bearer令牌(bearer token)进行认证。第一服务器生成注册表后，表示第三方服务器注册成功。
在步骤S303，当账号系统一侧产生第三方服务器关注的事件时，账号系统将事件信息发送给第一服务器，例如可以采用如图2所示的发布/订阅系统将事件信息发布到DMQ上，第一服务器通过订阅获取事件信息。
在步骤S304，第一服务器获取到事件信息后，将事件信息投递至注册表中指定的投递地址。
这里投递地址即在步骤S301中第三方服务器在注册请求中所提交的投递地址，例如“url”字段中的URL“https://receiver.example.com/events”。具体地，第一服务器可以根据RISC规范中的封装数据格式，将事件信息进行封装，并根据注册表中指定的投递地址将封装后的数据投递给第三方服务器。相应地，第三方服务器向第一服务器反馈事件信息接收成功或接收失败。
在S301之前，第一服务器可以参照RISC规范提供指定risc配置信息和公钥证书信息的网站，以方便第三方服务器通过上述网站获取注册RISC服务以及解析事件所需要的相关信息，在此不再详述。
现有的RISC流程中，RISC服务提供者对第三方服务器发送的注册请求完成接口级鉴权后，就直接生成了注册表，并在后续过程中，根据注册表中的投递地址将事件信息投递出去。注册表中的投递地址是第三方服务器在注册请求中提交的投递地址，现有注册服务流程中，第一服务器并没有对该投递地址进行校验，这将导致在步骤S304中第一服务器将事件信息投递给未经校验的投递地址中，存在一定的安全风险。例如如果该投递地址为恶意攻击者提供的投递地址，第一服务器很有可能将事件信息投递给非注册的第三方服务器上，将会导致账号事件被窃取。
本申请实施例将提供一种注册服务的方法，使得提供事件投递服务的提供者对第三方服务器的域名拥有权进行校验，确认第三方服务器对投递地址中的域名具有域名拥有权，从而确保事件投递过程的安全可靠。
图4示出了本申请实施例提供的一种注册服务的方法。图4所示的方法400可以由提供事件投递服务的服务器执行，例如图1中的第一服务器110或图2中的第一服务器220。该方法400包括步骤S410至步骤S430。
在步骤S410，第三方服务器向第一服务器发送注册请求，用于请求注册事件投递服务。该注册请求包括第一信息、第二信息和第三信息。
第一信息用于指示所述第三方服务器的公钥地址，该公钥地址包括第一域名。
该第一域名为第三方服务器的公钥地址中的域名，在一些实施例中也可以称为验证域名。本申请实施例中，第三方服务器需要在步骤S410之前将第三方服务器的公钥发布在上述公钥地址下，换言之，第三方服务器需要将第三方服务器的公钥发布在其域名目录下。与公钥对应的私钥由第三方服务器私密保存。
可选地，第三方服务器在公钥地址下可以发布至少一个公钥。
第二信息用于指示事件信息的投递地址，也即第三方服务器接收事件信息的地址，该投递地址包括第二域名。
该第二域名为投递地址中的域名，在一些实施例中也可以称为投递域名。本申请实施例中，即要验证第三方服务器对该第二域名(即投递域名)是否具备域名拥有权。
第三信息用于指示域名系统DNS服务器上的目标DNS记录，该目标DNS记录包括第三方服务器使用第三方服务器的私钥创建的数字签名，第三方服务器发布在域名目录下的公钥即用来对数字签名进行验证。其中该目标DNS记录需要由第三方服务器提前写入DNS服务器。
需要说明的是，只有具备对第二域名的域名拥有权，第三方服务器才可以在DNS服务器上增加第二域名对应的DNS记录(例如前述介绍的A记录，MX记录，TXT记录等)，说明第三方服务器具备对第二域名的DNS维护权限。
可选地，第一信息可以承载于第一字段。
可选地，第二信息可以承载于第二字段。
可选地，第三信息可以承载于第三字段。
可选地，第一字段、第二字段、第三字段可以属于同一字段节点，也可以属于至少两个字段节点。例如第一字段与第三字段属于同一节点，第二字段属于另一节点。
示例性的，在RISC服务场景，在现有的注册请求格式基础上，第三方服务器在发送的注册请求中可以再增加第一字段和第三字段，其中第一字段用于承载第一信息，第一信息用于指示第三方服务器的公钥地址，第三字段用于承载第三信息，第三信息用于指示目标DNS记录。为方便理解，第三方服务器注册RISC注册表的一个示例可以如下：
Figure BDA0002631581560000131
在上述注册表示例中，第一字段的一个示例为“jwks_uri”字段，第三字段的一个示例为“lookup_key”字段，第二字段可以同现有标准即“url”字段，除第一字段、第二字段和第三字段外的其他字段可以同现有标准。第一字段和第三字段相比现有标准为新增字段，可以将第一字段与第三字段设于同一节点下，例如上述注册表示例中的“verify”节点。本申请实施例中增加的第一字段用于获取第三方服务器的公钥，增加的第三字段用于获取第三方服务器在DNS服务器上写入的目标DNS记录。由于目标DNS记录中包括第三方服务器使用私钥创建的数字签名，因此第一服务器根据第一字段获得的第三方服务器的公钥用于验证目标DNS记录中的数字签名，以验证第三方服务器对投递地址中的域名是否具备域名拥有权，具体过程描述如下，在此暂不详述。
应理解，上述示例中字段以及节点的名称仅仅是示例性的，在实际应用中可根据需要相应设定，本申请实施例不做限定。还应理解，对于其他的第三方服务器注册事件投递服务场景，第一信息、第二信息、第三信息在注册请求中的具体承载格式可以根据实际协议或标准相应确定，在此不再一一列举。
在步骤S420，第一服务器根据第一信息、第二信息、第三信息验证第三方服务器对投递地址中的域名是否具有域名拥有权。
本申请实施例中，第一服务器根据注册请求中的信息对第三方服务器的域名拥有权进行验证，可以减少事件投递信息被投递到未经校验的投递地址中而被恶意设备窃取的风险。
在步骤S430，根据验证结果确定是否允许第三方服务器注册服务。
如果验证通过，可以认为第三方服务器具备投递地址中域名的合法拥有权，则可以允许第三方服务器进行注册。
如果验证不通过，可以认为第三方服务器不具备投递地址中域名的合法拥有权，则拒绝第三方服务器进行注册。
下面结合图5和图6更为详细地描述本申请实施例提供的注册服务的方法。
图5示出了本申请实施例提供的一种注册服务的方法。参考图5，方法500为方法400的一种实现方式，该方法500包括步骤S510至步骤S540。
在步骤S510，接收第三方服务器的注册请求。
注册请求用于请求注册事件投递服务。注册请求包括第一信息、第二信息和第三信息，第一信息用于指示第三方服务器的公钥地址，公钥地址包括第一域名；第二信息用于指示事件信息的投递地址，投递地址包括第二域名；第三信息用于指示域名系统DNS服务器上的目标DNS记录，目标DNS记录包括第三方服务器使用第三方服务器的私钥创建的数字签名。
步骤S510与方法400中的步骤S410类似，对于注册请求以及注册请求中的第一信息、第二信息、第三信息的相关描述可参考步骤S410的相关描述，为简洁，在此不再赘述。
在步骤S520，在第一域名与第二域名相同的情况下，根据第一信息尝试获取第三方服务器的公钥，以及根据第三信息尝试获取目标DNS记录。
在该步骤中，第一服务器根据第一信息尝试获取第三方服务器的公钥。
在步骤S510中提到，公钥地址中包括第一域名，投递地址包括第二域名。第一服务器根据第一信息中所指示的公钥地址，可以去该公钥地址下获取公钥信息。应理解，对于第一服务器来说，第一服务器不知道获取的公钥是否真的是第三方服务器的公钥，因此本申请实施例中所述“第三方服务器的公钥”可以理解为在第一服务器角度认为公钥是发送注册请求的设备的公钥，对于该公钥与第三方服务器的真实对应关系没有限定。本申请实施例中，要校验第三方服务器对投递地址中的第二域名是否具备域名拥有权，可以通过第一域名建立第三方服务器与第二域名的联系。具体而言，第一域名为第三方服务器的公钥地址中的域名，将第三方服务器的公钥公布在第一域名目录下，当第一域名与第二域名相同时，第三方服务器的公钥来源与第二域名一致，可以通过公钥证书来证明第三方服务器是否具备合法性验证能力。也就是说，公钥证书可以证明第一域名与发布公钥的服务器具有对应关系，若第二域名与第一域名相同，则可以证明投递地址中的第二域名与发布公钥的服务器具有对应关系，只要验证第三方服务器对公钥对应的第一域名是否具备域名拥有权即可。
当第一域名与第二域名不相同时，可能存在仿冒风险。例如第一信息是真实的第三方服务器发送的，但第二信息可能是被恶意攻击者提供的，这样公钥地址中的域名与投递地址中的域名往往是不同的。
因此，可选地，在第一域名与第二域名不同的情况下，确定不允许第三方服务器进行注册。第一服务器直接拒绝第三方服务器进行注册，可以避免上述提及的仿冒风险。
可选地，第三方服务器在公钥地址下可以发布一个或多个公钥。当根据第一信息查询到多个公钥时，提供事件投递服务方例如前述第一服务器可以根据第三方服务器的指示使用与第三方服务器创建数字签名时使用的私钥对应的公钥。
公钥的指示方式有多种。例如，第三方服务器可以在目标DNS记录中指示，也可以在注册请求中指示，还可以发送单独的消息进行指示。在一些实施例中，第三方服务器和第一服务器也可以按照预设规则使用、获取对应的公私钥对。
可选地，第三方服务器可以通过公私钥对的标识、公钥的标识或者私钥的标识来指示第一服务器获取哪个公钥并使用该公钥进行后续验签。
可选地，在该步骤中，若根据第一信息未获取到公钥信息，则认为第三方服务器未按照约定提供公钥证书，不具备合法性验证能力，可以直接拒绝第三方服务器进行注册。即在未获取到第三方服务器的公钥的情况下，确定不允许第三方服务器进行注册。这样可以避免以下的仿冒风险：例如恶意攻击者在第一信息和第二信息中均提供了相同的域名，但恶意攻击者未在相应域名目录下发布公钥。
在该步骤中，第一服务器根据第三信息获取目标DNS记录。
可选地，第三信息可以包括所述目标DNS记录对应的关键词。这样可以根据关键词在DNS服务器上查询第二域名(也即第一域名)下是否有目标DNS记录。
应理解，通过关键词只能查询到是否有目标DNS记录，对于记录当中是否有内容以及内容具体是什么并不知道，需要通过提取目标DNS记录中的数据确定目标DNS记录中是否有内容，通过使用获取的公钥进行验签确定目标DNS记录中的数据是什么。
在该步骤中，第一服务器可以使用域名解析工具例如nslookup命令，在第二域名对应的DNS服务器上查询是否有关键词对应的DNS记录。
在一些实施例中，“获取目标DNS记录”包括：根据关键词在DNS服务器上查询目标DNS记录；获取目标DNS记录中的数字签名。
可选地，在该步骤中，若根据第三信息未获取到目标DNS记录，例如第一服务器在DNS服务器查询到目标DNS记录，或者没有获取到目标DNS记录中的数字签名，则认为第三方服务器不具备对第二域名(也即第一域名)的DNS维护权限，即不具备合法拥有权。即在未获取到目标DNS记录的情况下，或者在未获取到数字签名的情况下，确定不允许第三方服务器进行注册。这样可以避免以下的仿冒风险：例如第三方服务器为真实的注册服务发起方，但恶意攻击者提供了仿冒的域名，这样服务提供方将在DNS服务器上查询恶意攻击者提供的域名下是否有目标DNS记录。由于第三方服务器将目标DNS记录写入了自己的域名下，如果恶意攻击者不在其提供的域名下增加目标DNS记录，则服务提供方是查询不到目标DNS记录的。因此可以认为第三方服务器不具备该域名的拥有权。
应理解，本申请实施例中，步骤S520中获取第三方服务器的公钥的过程和获取目标DNS记录的过程可以先后执行，也可以同时执行，在此不做具体限定。当获取公钥的过程在获取目标DNS记录的过程之前或同时执行时，若第三方服务器发布多个公钥，第一服务器可以将多个公钥均获取到，再根据目标DNS记录中的公钥指示从多个公钥中确定用来验证数字签名的公钥。当获取公钥的过程在获取目标DNS记录的过程之后执行，若第三方服务器发布多个公钥，第一服务器可以根据目标DNS记录中的公钥指示直接从公钥地址下获取用于验证数字签名的公钥。
还应理解，在第一服务器执行步骤S520过程中，如果第一服务器没有得到相应的结果，则可以直接停止操作流程，拒绝第三方服务器此次的注册请求。即，在未获取到第三方服务器的公钥和/或目标DNS记录的情况下，确定不允许第三方服务器进行注册。
在步骤S530，在获取到第三方服务器的公钥和目标DNS记录的情况下，根据第三方服务器的公钥，对目标DNS记录中的数字签名进行验签，得到验签结果。
目标DNS记录中的数字签名可以有多种形式。
作为一个示例，目标DNS记录可以包括使用第三方服务器的私钥创建的数字签名，加密前的原文在注册请求中指示给服务提供方(即第一服务器)。
作为另一个示例，目标DNS记录中的数字签名可以是JWT形式。即目标DNS记录可以包括JWT，该JWT包括使用第三方服务器的私钥创建的数字签名。由于JWT是一个自包含的访问令牌，因此获取到该目标DNS记录就可以使用第三方服务器的公钥进行验签。
为方便理解，下面对JWT做一些简要介绍。
JWT是一种用于通信双方之间传递安全信息的简洁的、URL安全的表述性声明规范，经常用在跨域身份验证。JWT本质是一种访问资源的凭证(Token)，其目的不是为了隐藏或者保密数据，而是为了确保数据确实来自被授权的人创建的，以防止中途篡改。
JWT是由三段字符串和两个圆点(.)组成，其格式为：Header.Payload.Signature(例如：xxxxxx.yyyyyy.zzzzzz)，字符串和字符串之间没有换行，每个字符串代表了不同的功能。
1.头部(header))
头部是一个JSON对象，主要承载两部分信息，分别是声明类型(token类型)和声明加密的算法。其中声明类型为jwt；声明加密的算法通常直接使用HMAC SHA256。在一些实施例中，签名算法也可以使用例如RSA或ECDSA等非对称加密算法。
示例性的，头部字符串可以为json{"alg":"HS256","typ":"JWT"}，这里的alg属性表示签名所使用的算法，JWT签名默认的算法为HMAC SHA256，alg属性值HS256就是HMACSHA256算法。typ属性表示令牌类型，这里就是JWT。将头部进行base64加密(该加密是可以对称解密的)，构成了JWT的第一部分。
2.有效载荷(playload)
载荷是存放有效信息的地方，有效载荷也是个JSON对象，是JWT的主体。有效载荷主要包含三个部分，分别是标准注册(registered)声明、公共(public)声明和私有(private)声明。
其中，标准注册声明一般包括以下内容：1)iss：jwt的签发者/发行人；2)sub：主题或jwt所面向的用户；3)aud：接收方；4)exp：jwt过期时间；5)nbf：jwt生效时间；6)iat：jwt的签发时间；7)jti：jwt唯一身份标识，主要用来作为一次性token，可以避免重放攻击。公共声明中可以添加任何信息，一般会添加用户信息和业务信息，该公共声明可以在客户端解密。私有声明是服务器和客户端共同定义的声明，该部分信息可以归类为明文信息。这里标准注册声明不是强制使用的，另外由于公共声明和私有声明采用对称加密，因此一般不建议存放敏感信息。将有效载荷进行base64加密(该加密是可以对称解密的)，构成了JWT的第二部分。
3.哈希签名(签证(signature)信息)
哈希签名的算法主要是确保数据不会被篡改。它主要是对前面所讲的两个部分进行签名，通过JWT头部定义的算法生成哈希。哈希签名的一般过程如下:1)指定一个密码(secret，即私钥)，该密码仅保存于服务器中，不能向用户公开；2)对JWT头部和有效载荷进行base64编码，JWT头部和有效载荷编码后的结果之间用(.)来连接，分别作为JWT字符串的第一部分(例如xxxxxx)和第二部分(例如yyyyyy)；3)使用JWT头部指定的算法进行签名，即使用头部中声明的加密算法对步骤2)中得到的字符串(例如xxxxxx.yyyyyy)进行加盐密钥组合加密，构成了JWT的第三部分(例如zzzzzz)。
在计算出签名哈希后，编码后的JWT头部，编码后的有效载荷和哈希签名的三个部分组合成一个字符串，每个部分用(.)分隔，就构成整个JWT对象(例如xxxxxx.yyyyyy.zzzzzz)。签名是用于验证消息在传递过程中有没有被更改，并且，对于使用私钥签名的token，它还可以验证JWT的发送方是否为它所称的发送方。
可选地，JWT可以包括第三方服务器对应的第三方开发者的标识或者第三方服务器对应的应用标识(可记做client_id)，其中应用标识用于标识第三方服务器对应的第三方应用。该第三方服务器对应的第三方应用标识或者第三方开发者标识可以用于唯一标识第三方应用(或网站)，用于验证第三方服务器是否持有对应的第三方应用的信息。例如JWT中的aud字段可包括前述信息。
可选地，JWT中包括第三域名，该第三域名用于指示JWT的签发者。在一些实施例中第三域名还可以称为签发者域名，即第三方服务器的域名。例如JWT中的iss表示JWT的签发者，因而iss字段包括签发者域名。
可选地，JWT中sub字段包括的信息可与aud字段中的信息相同。JWT中的其他字段内容可根据实际需要或者按照JWT标准相应定义。
在第一服务器对JWT中的数字签名进行验签过程中，第一服务器可以使用在步骤S520中获取的公钥解密JWT中的哈希签名，得到编码后的头部和编码后的有效载荷。通过比较解密得到的数据与JWT的头部和有效载荷部分中的数据，可以验证JWT的发送方是否为第三方服务器，且可以验证签名数据是否被篡改过。
在一些实施例中，第一服务器对目标DNS记录中的数字签名进行验签的过程，具体可以包括：提取目标DNS记录中的校验串，在提取到校验串的情况下，根据第三方服务器的公钥对校验串进行验签。
因此，可选地，在未提取到校验串的情况下，确定不允许第三方服务器进行注册。这样可以避免以下仿冒风险：恶意攻击者通过猜测在DNS服务器上写入目标DNS记录对应的关键词，但没有写入签名数据。
在步骤S540，根据验签结果确定是否允许第三方服务器进行注册。
该步骤为验证签名的过程，即验证目标DNS记录中的数字签名是否是第三方服务器所创建，签名数据是否被篡改。
若目标DNS记录中的数字签名为第三方服务器创建且没有被篡改，则验签结果通过，确定允许第三方服务器进行注册。若目标DNS记录中的数字签名不是第三方服务器创建，或者签名数据被篡改，则验签结果为不通过，确定不允许第三方服务器进行注册。
进行到该步骤，可能存在以下几种情形：
情形一：第三方服务器为真实的，注册请求中的信息也没有被恶意篡改，则经过步骤S520后获取的公钥以及目标DNS记录均为真实的，在该步骤中使用第三方服务器的公钥对目标DNS记录中的数字签名进行验签，验签通过即可以证明第三方服务器对第二域名具备域名拥有权。
情形二：第三方服务器为恶意第三方，该恶意第三方盗取了投递域名对应的DNS内容编辑权限和对应的公钥，在一些情况下该恶意第三方通过猜测目标DNS记录对应的关键词在DNS服务器上增加了DNS记录，但由于恶意第三方不知道与公钥对应的私钥，在该步骤中则不能通过验签。则认为第三方服务器对第二域名不具备域名拥有权，可以拒绝第三方服务器注册，这样可以有效提升事件投递过程中的安全性。
本申请实施例提供的注册服务的方法中，在第三方服务器注册事件投递服务过程中，对第三方服务器对投递地址指定的域名的合法拥有权进行了校验，通过校验第三方服务器是否具备DNS记录增加权限以及校验第三方服务器的签名，可以有效提升事件投递过程中的安全性。当第一服务器确定第三方服务器对投递地址中的域名没有域名拥有权时，第一服务器可以拒绝第三方服务器注册服务。这样可以避免仿冒问题，减少投递事件被盗取的风险，保证事件投递过程的安全可靠，提升第一服务器将事件信息共享给第三方的安全性。
图5提供的注册服务的方法中，由于第一服务器对第三方服务器对投递地址中的域名合法拥有权进行了校验，相比现有技术而言，已经大大提升了事件投递过程的安全性，并且可以避免绝大部分的仿冒问题，恶意攻击者能够通过步骤S540已经非常困难。
为了进一步提高事件投递过程的安全性，本申请实施例还提供了一种注册服务的方法，下面参考图6描述。图6所示的方法600为方法400的一种实现方式，该方法600包括步骤S610至步骤S650。
在步骤S610，接收第三方服务器的注册请求。
注册请求用于请求注册事件投递服务。注册请求包括第一信息、第二信息和第三信息，第一信息用于指示第三方服务器的公钥地址，公钥地址包括第一域名；第二信息用于指示事件信息的投递地址，投递地址包括第二域名；第三信息用于指示域名系统DNS服务器上的目标DNS记录，目标DNS记录包括第三方服务器使用第三方服务器的私钥创建的数字签名和第三方服务器对应的应用标识。
步骤S610与方法500中的步骤S510类似，具体可参考步骤S510的相关描述，下面仅描述不同之处。
本申请实施例中，第三方服务器可以在注册事件投递服务之前注册账号，该账号与第三方服务器对应的第三方应用(或网站)具有关联关系，例如注册账号过程中，第三方服务器提供第三方应用对应的域名，注册成功后可以获得第三方应用的标识(在一些实施例也可记做clent ID)，该应用的标识用于标识第三方应用。
本申请实施例中目标DNS记录中包括第三方服务器对应的应用标识，第一服务器根据该应用标识可以获取到第三方服务器注册账号时在提供账号注册服务的一方生成的重定向地址，该重定向地址包括第三方服务器对应的第三方应用的域名。以下会结合步骤S610详细描述，在此暂不详述。
在步骤S620，在第一域名与第二域名相同的情况下，根据第一信息尝试获取第三方服务器的公钥，以及根据第三信息尝试获取目标DNS记录。
步骤S620与方法500中的步骤S520类似，具体可参考步骤S520的相关描述，在此不再赘述。
在步骤S630，在获取到第三方服务器的公钥和目标DNS记录的情况下，根据第三方服务器的公钥，对目标DNS记录中的数字签名进行验签，得到验签结果。
步骤S630与方法500中的步骤S530类似，具体可参考步骤S530的相关描述，在此不再赘述。
在步骤S640，在验签结果通过的情况下，根据第三方服务器对应的应用标识，获取第三方服务器对应的应用的重定向地址，该重定向地址包括第四域名。
在该步骤中，第一服务器从目标DNS记录中可以获取第三方服务器对应的应用标识，该应用标识用于标识第三方服务器对应的应用。第一服务器根据该应用标识可以获取第三方服务器对应的应用(即第三方应用)的重定向地址，也即第三方应用对应的重定向地址。该重定向地址中包括第四域名，第四域名即第三方应用对应的域名，在本申请实施例中也可以称为应用可信域名。
可选地，在验签结果不通过的情况下，确定不允许第三方服务器进行注册。
在步骤S650，在第二域名与第四域名相同的情况下，确定允许第三方服务器进行注册。
换言之，相比方法500，第一服务器除了对目标DNS记录中的数字签名进行验签外，对第三方服务器的域名拥有权的验证还可以包括：
验证第二信息中的第二域名与第三方应用的应用可信域名是否一致。
若一致，则继续执行其他步骤，例如确定允许第三方服务器注册；若不一致，则可能存在仿冒风险，第一服务器可以直接拒绝第三方服务器的注册请求，即在第二域名与第四域名不同的情况下，确定不允许第三方服务器进行注册。
该第三方应用的应用可信域名为第三方应用对应的重定向地址(redirect_uri)中的域名，是在第三方服务器注册账号过程中或者第三方服务器被授权过程中提交给账号系统(例如图2中的账号系统)的。在注册事件投递服务过程中，第一服务器可以从账号系统中获取重定向地址或重定向地址中的应用可信域名，然后进行上述关于第二域名与应用可信域名(即第四域名)的验证。应理解，该重定向地址(redirect_uri)相当于一个应用的URL，且为设备后台配置，不可更改。本申请实施例验证第二域名与重定向地址(redirect_uri)中的域名是否一致，可以判断第二域名是否为仿冒域名。这样，可以在确定投递域名确实为在第一服务器侧注册的第三方应用的域名基础上，确定第三方服务器对投递域名具有拥有权，可以避免将事件信息投递给未在第一服务器注册账号的第三方，提高事件投递过程的安全性。
可选地，对第三方服务器的域名拥有权的验证还包括：
验证JWT中的签发者域名(即第三域名)、第一信息中的验证域名(即第一域名)、第二信息中的投递域名(即第二域名)与第三方应用(或网站)对应的重定向地址中的应用可信域名(即第四域名)是否一致。
若一致，则继续执行其他步骤，若不一致，则可能存在仿冒风险，第一服务器可以直接拒绝第三方服务器的注册请求。
图6中提供的注册服务的方法中，通过在注册请求中提交公钥地址的域名建立第三方服务器与投递地址中的域名的联系，从而通过验证第三方服务器对公钥地址中的域名是否具有合法拥有权，来判断第三方服务器对投递地址中的域名是否具有合法拥有权。在另一些实施例中，第三方服务器在注册请求中也可以不提交用于指示公钥地址的第一信息或者不限定第一域名和第二域名相同的情况下才执行后续步骤，第一服务器可以直接执行上述“验证第二信息中的第二域名与第三方应用的应用可信域名(即第四域名)是否一致”，以此来建立第三方服务器与投递地址中的域名的联系。
应理解，本申请实施例中第一服务器通过方法600后得到的验证结果包括以下至少一方面：
一是验证签名，即验证目标DNS记录中的数字签名是否是第三方服务器所创建，签名数据是否被篡改；
二是验证第一信息中的第一域名(或者第二信息中的第二域名)与第三方服务器对应的第三方应用的可信域名(即第四域名)是否一致；
三是验证目标DNS记录中的签发者域名(即第三域名)、注册请求中的第一域名和第二域名以及第三方应用的可信域名(即第四域名)是否一致。
当验证结果包括至少两方面时，只要有一方面的验证结果为否，则认为验证不通过。
在验证通过后，在产生第三方服务器关注的账号事件时，第一服务器可以按照现有流程将账号事件信息投递给第三方服务器注册时提供的投递地址中，即将账号事件信息投递给第三方服务器。
本申请实施例提供的注册服务的方法中，在第三方服务器注册事件投递服务过程中，对第三方服务器对投递地址指定的域名的合法拥有权进行了校验，通过校验第三方服务器是否具备DNS记录增加权限以及校验第三方服务器的签名，可以有效提升事件投递过程中的安全性。当第一服务器确定第三方服务器对投递地址中的域名没有域名拥有权时，第一服务器可以拒绝第三方服务器注册服务。这样可以避免仿冒问题，减少投递事件被盗取的风险，保证事件投递过程的安全可靠，提升第一服务器将事件信息共享给第三方的安全性，并且可以避免将事件信息投递给未在第一服务器注册账号的第三方。
下面结合附图7更加详细地描述本申请实施例的一些具体的非限制性的例子。本申请实施例以第三方服务器注册RISC服务为例进行说明，但如上所述，本申请实施例提供的方法同样可以应用于第三方服务器注册其他事件投递服务的场景。图7所示的方法700主要应用于如图1或2中所述的包括第一服务器和第三方服务器的架构。方法700包括步骤S701至步骤S711a(或步骤S711b)。
在步骤S701，第三方服务器向第一服务器发送注册请求。
该第一服务器可以为提供消息推送或事件投递等服务的设备，其中第一服务器推送的消息类型或事件类型可以根据第一服务器所提供的服务相应确定。该注册请求则用于请求注册第一服务器所能提供的服务。示例性的，该第一服务器可以为提供RISC服务的设备，即第一服务器可以提供账号风险事件信息。相应地，该注册请求用于请求注册RISC服务。
该注册请求可以包括第一字段、第二字段和第三字段，其中第一字段用于指示第三方服务器的公钥地址，第二字段用于指示事件信息的投递地址，第三字段用于指示目标DNS记录。
示例性的，在发送注册请求过程中，第三方服务器可以根据RISC协议向第一服务器提交注册表。该注册表为事件关注注册表，包括第三方服务器所关注的事件类型信息，例如账号禁用、账号冻结、凭据吊销等。
为方便理解，注册表的一个示例如下：
Figure BDA0002631581560000211
在上述注册表示例中，“iss”字段用于指示第三方服务器的所有者，或者可以理解为是第三方网站或第三方应用的提供者，该字段具体可以包括第三方应用或第三方网站对应的域名。“aud”字段用于指示事件投递信息的接收者。示例性的，若第三方服务器为应用服务器(the application server)，用于为第三方应用提供服务，则该字段可以包括第三方应用的客户端地址和/或网页地址。若第三方服务器为网站服务器(web server)，用于为第三方网站提供服务，则该字段可以包括第三方网站的网页地址。verify节点下的“jwks_uri”字段即上述第一字段，用于指示第三方服务器的公钥地址。一般第三方服务器需要事先在其域名目录下发布第三方服务器的至少一个公钥，第一服务器可以根据注册请求获取与第三方服务器签名时使用的私钥对应的公钥，该公钥用于后续验签使用。verify节点下的“lookup_key”字段即上述第三字段，用于指示目标DNS记录，该字段具体可以包括目标DNS记录对应的关键词。示例性的，目标DNS记录对应的关键词可以为“verify_key”，第一服务器可以在DNS服务器上查询与名称“verify_key”对应的DNS记录。delivery节点下的“delivery_method”字段用于指示获取消息的方式。第三方服务器从第一服务器获取消息的方式可以有两种，一种方式是由第一服务器主动推送或投递给第三方服务器，这种方式称为推(push)，另一种方式是由第三方服务器主动去第一服务器侧拉取，这种方式称为拉(pull)。示例性的，本申请实施例中第三方服务器以推送方式获取事件信息。delivery节点下的“url”字段即为上述第二字段，用于指示投递地址，即指示第一服务器将消息投递给哪个地址。“events_requested”字段用于指示第三方服务器的关注的事件。第三方服务器可以关注一个或多个事件，相应地，该字段包括第三方服务器想要关注的所有事件信息。
示例性，以第三方服务器为应用服务器为例，上述注册表中所包含的信息为：第三方应用服务提供方(例如cloud.example.com)向RISC服务提供方提交关注凭据吊销(https://schemas.openid.net/secevent/oauth/event-type/tokens-revoked)事件，希望RISC服务提供方发现凭据吊销事件时，将该凭据吊销事件投递至https://cloud.example.com/rc/events方法上，方便第三方应用服务提供方(例如cloud.example.com)快速响应账号安全消息，并采取相应的保护措施(例如登出账号)。
应理解，第三方服务器发送的注册请求还包括其他信息，具体可以参考注册服务对应的协议实现，在此不再赘述。
在步骤S702，第一服务器接收到第三方服务器发送的注册请求后，第一服务器可以先解析字段信息，然后提取第一字段中的第一域名、第二字段中的第二域名和第三字段中的关键词。
这里，第一域名也可以称为验证域名，第二域名也可以称为投递域名。
如果在该步骤中，第一服务器没有提取到第一域名、第二域名和关键词中的至少一个，则第一服务器可以直接执行步骤S711b，返回错误码。
这里，第一服务器没有提取到第一域名、第二域名和关键词中的至少一个，可能是在注册请求中没有相应的字段，则第一服务器可以不再进行以下的域名拥有权验证步骤，而直接返回错误码，从而拒绝第三方服务器此次的注册请求。
如果在该步骤中第一服务器提取到相应信息，则进入下一步骤。
在该步骤中，如果恶意设备发送了注册请求，但没有在注册请求中按照约定携带上述信息，则第一服务器在该步骤即可以拒绝恶意设备的注册，防止事件信息被盗取。
示例性的，以第三方服务器发送步骤S701中示出的注册表为例，第一服务器可以根据协议解析注册表中的字段信息，并得到verify节点信息(主要包括“jwks_uri”和“lookup_key”信息)和delivery节点信息(主要包括“url”信息)。这里第一服务器解析并提取得到“jwks_uri”信息为“https://cloud.example.com/jwks.json”，“lookup_key”信息为“verify_key”，“url”信息为“https://cloud.example.com/rc/events”。
接下来，第一服务器从第一字段(即“jwks_uri”字段)中提取第一域名为“cloud.example.com”，从第二字段(即“url”字段)中提取第二域名为“cloud.example.com”，从第三字段(即“lookup_key”)提取关键词为“verify_key”。
在步骤S703，第一服务器进行域名一致性判断，判断第一域名与第二域名是否相同。
如果第一域名与第二域名不相同，说明公钥证书持有者与需要投递的方法采用的域名不一致，这种情况有可能会导致仿冒风险，因此，检测到这种情况可以直接执行步骤S711b返回错误码，拒绝第三方服务器此次的注册请求。
如果第一域名与第二域名相同，即第三方服务器公钥地址中的域名与投递地址中的域名相同，说明公钥证书持有者与需要投递的方法中采用的域名一致，可以进入下一步骤。
在该步骤中，如果注册请求是真实的第三方服务器发送的，但是注册请求中用于指示投递地址的第二字段被恶意设备修改了，或者恶意设备窃取了注册请求但只修改了第二字段，这样用于指示真实第三方服务器公钥地址的域名与投递地址中的域名不相同，则第一服务器在该步骤即可以拒绝恶意设备的注册，防止事件信息被盗取。
示例性的，以第三方服务器提取的第一域名和第二域名为步骤S702中示出的域名为例，由于第一域名为“cloud.example.com”，第二域名为“cloud.example.com”，两者相同，说明证书发布的域名和投递方法中的域名是同一持有者持有。
在步骤S704，根据第一字段所指示的公钥地址，第一服务器尝试获取第三方服务器的公钥。
该步骤中，第一服务器获取第三方服务器的公钥是用于后续进行验签，以下将结合步骤S709进行描述，在此暂不详述。
示例性，以第一字段为步骤S701给出的示例为例，第一服务器根据第一字段(即“jwks_uri”字段)中指定的统一资源定位符URL，通过http或者https尝试获取第三方服务器提供的公钥信息。
因此，在该步骤之前第三方服务器需要事先执行步骤S712，发布公钥信息，具体地第三方服务器在其域名目录下即注册请求中提供的第一字段的网址下发布公钥。为方便理解，公钥发布格式的一个示例如下：
Figure BDA0002631581560000231
Figure BDA0002631581560000241
在上述公钥发布格式示例中，“alg”标头参数用于表示保护ID令牌的加密算法。示例性的，第三方服务器签名算法采用RS256(即RSA-SHA256)加密算法，当然也可以采用其他消息签名算法例如HS256(HMAC-SHA256)、ES256(ECDSA-SHA256)等。“kty”参数标识与密钥结合使用的加密算法系列，例如本申请实施例示出的“RSA”，也即密钥类型参数。“e”参数包含RSA公有密钥的指数值，其表示为采用Base64urlUInt编码的值。“n”参数包含RSA公有密钥的模数值，其表示为采用Base64urlUInt编码的值。“kid”是一个提示，指示哪些密钥用于保护令牌的签名(即JSON web signature(JWS))，也即用于指示公钥标识。“use”参数表述了公有密钥的预期用途，例如本申请示例中，use值“sig”表示签名。应理解，公钥发布格式还可以是其他形式或者包括其他字段信息，具体可根据对应的协议规定确定，在此不再详述。
第三方服务器可以发布至少一个公钥，例如上述给出的公钥发布格式即发布了两个公钥。当第三方服务器发布了多个公钥时，第三方服务器可以通过一些方式例如向第一服务器单独发送指示信息或者在注册请求中包括指示信息等来指示与第三方服务器使用的私钥对应的公钥。下面将结合步骤S709进行具体描述，在此暂不详述。
在步骤S705，第一服务器根据公钥返回结果判断是否获取到公钥。
如果公钥返回结果中没有第三方服务器的公钥信息，在该步骤中，第一服务器不能获取到第三方服务器的公钥，可以认为第三方服务器未按照协议约定提供公钥证书，不具备合法性验证能力。则第一服务器可以直接执行步骤S711b，返回错误码，拒绝第三方服务器此次的注册请求。
如果公钥返回结果中包括第三方服务器的公钥信息，在该步骤中第一服务器能够获取到第一服务器的公钥，说明第三方服务器按照协议约定提供了公钥证书，则进入下一步骤。
如果上述步骤中注册请求是恶意设备发送的，并且恶意设备将注册请求中第一字段和第二字段中的验证域名和投递域名修改一致，但恶意设备没有在第一字段对应的网址下发布公钥，即没有执行步骤S712。在该步骤中，第一服务器获取不到公钥，则第一服务器即可以拒绝恶意设备的注册，防止事件信息被盗取。
示例性的，以第三方服务器发送步骤S701中示出的注册表为例，第一服务器根据第一字段(即“jwks_uri”字段)指定的URL：https://cloud.example.com/jwks.json，通过http或https获取第三方服务器提供的公钥信息。第三方服务器在步骤S712中发布至少一个公钥，第一服务器可以获取到该至少一个公钥，例如第一服务器获取到步骤S704示出的公钥。应理解，本申请实施例中是站在第一服务器的角度描述，第一服务器至此并不知道注册服务的设备是真实的第三方服务器还是恶意设备，因此第一服务器将获取的公钥默认就是第三方服务器的公钥，用于后续验签。
在步骤S706，第一服务器查询第三方服务器的DNS记录。
该步骤中，第一服务器根据第三字段中的关键词尝试获取目标DNS记录。
由于只有对域名具有域名拥有权时，才能在域名系统DNS中增加DNS记录，因此本申请实施例通过判断第三方服务器是否能够在DNS中增加目标DNS记录，确定第三方服务器是否具备域名拥有权。
因此，第三方服务器需要事先执行步骤S713，在DNS服务器中写入目标DNS记录。本申请实施例中，目标DNS记录中的数值为JWT。
本申请实施例中，目标DNS记录中的JWT组成部分中，有效载荷(playload)的一个示例为：标准注册声明中的iss为jwt的签发者，以步骤S701给出的注册表示例为例，iss可以为“delivery”节点下的投递地址中的域名(例如：cloud.example.com)，即iss设置为第三方服务器的域名，也可以称签发者域名；sub为jwt所面向的用户，示例性的可以为上述有效载荷中的aud(即接收方)，aud为对注册请求进行接口级鉴权(OAuth)中的第三方服务器对应的应用标识(client_ID)或者为第三方开发者的唯一标识例如第三方开发者账号(user ID，UID)，用于验证第三方服务器是否持有对应的第三方应用的信息。换言之，JWT的有效载荷中sub和aud包括的内容可以相同。标准注册声明中的其他exp、nbf、iat、jti均可以遵循JWT标准进行相应定义。有效载荷中的公共声明和私有声明可以添加，可以不添加，本申请实施例不做限定。
示例性的，以第三方服务器发送步骤S701中示出的注册表为例，为方便理解，JWT字符串的一个示例如下：
(lEdor06VsUexUdViEOQCDxwuxdbcOwOJYiQauWd.AtYO73s3mE-Up83tXUDLdzWQ_7rEda95q4J8dXRL1sIdq7eWh6Go33twaxbVw48JdZuup8OhfwyYKF51o.j3kJHmHOH3vSwpi4apW-uS3_fFqpEPLwGJPtmvvjXMntpZv0BqOKIOImlZsubytfFNpDC8cq7_ht2AEECn1kKtcL0yEi_QmlC)
其中，由(.)分隔开的三部分字符串分别为JWT的三个部分，即编码后的头部、编码后的有效载荷以及哈希签名。
在步骤S707，第一服务器根据记录查询返回结果，判断是否获取到目标DNS记录。
如果记录查询返回结果中没有目标DNS记录，在该步骤中，第一服务器不能获取到目标DNS记录，可以认为第三方服务器(即注册请求的发起方)不具备对投递地址中的域名的拥有权，则第一服务器可以直接执行步骤S711b，返回错误码，拒绝第三方服务器此次的注册请求。
如果记录查询返回结果中有目标DNS记录，在该步骤中，第一服务器能获取到目标DNS记录，可以认为第三方服务器(即注册请求的发起方)具备该域名的DNS维护权限，具有合法拥有权，第一服务器可以将目标DNS记录缓存，进入下一步骤。
由于没有域名拥有权的一方，是不能在DNS中增加记录的，非法个人即使能够仿冒域名进行投递注册请求，但是不能够按照与第一服务器的约定在DNS上增加记录，第一服务器拒绝其注册，从而提高了事件投递过程的安全性和可靠性。该步骤可以防止以下几种可能的情况：
一是恶意设备仿冒了真实的第三方服务器域名投递注册请求，但没有修改投递地址中的域名，此时恶意设备不具有投递域名对应的DNS记录维护权限，所以恶意设备不能在DNS服务器上增加目标DNS记录，第一服务器可以拒绝恶意设备的注册，防止事件信息被盗取。
二是恶意设备仿冒了真实的第三方服务器域名投递注册请求，但修改了投递地址和公钥地址中的域名(通过步骤S703)，并在相应的公钥地址下发布了公钥(通过步骤S705)，该公钥可以是恶意设备盗取的第三方服务器的公钥，也可以是恶意设备自己的公钥。但恶意设备对投递地址中的域名不具有拥有权，和/或，恶意设备不知道目标DNS记录对应的关键词，则第一服务器在注册请求中的投递域名对应的DNS服务器上查询不到目标DNS记录，第一服务器可以拒绝恶意设备的注册，防止事件信息被盗取。
可选地，第一服务器可以通过nslookup命令查询目标DNS记录。示例性的，以第三方服务器发送步骤S701中示出的注册表为例，通过第一服务器通过nslookup命令在DNS服务器上查询到的目标DNS记录的一个示例如下：
nslookup命令示例：
nslookup qt＝TXT cloud.example.com
获得的结果例子如下：
Welcome cloud.example.com
[verify_key＝lEdor06VsUexUdViEOQCDxwuxdbcOwOJYiQauWd.AtYO73s3mE-Up83tXUDLdzWQ_7rEda95q4J8dXRL1sIdq7eWh6Go33twaxbVw48JdZuup8OhfwyYKF51o.j3kJHmHOH3vSwpi4apW-uS3_fFqpEPLwGJPtmvvjXMntpZv0BqOKIOImlZsubytfFNpDC8cq7_ht2AEECn1kKtcL0yEi_QmlC]
其中，verify_key后边即上述JWT字符串的示例。这里第三方服务器在注册请求中指示的关键词(例如verify_key)及其数值JWT字符串即目标DNS记录。第一服务器查询到目标DNS记录后，将该目标DNS记录缓存下来。
需要说明的是，本申请实施例中，步骤S704-S705中获取第三方服务器公钥的步骤，和步骤S706-S707中获取目标DNS记录的步骤可以以图7所示的先后顺序执行，也可以调换顺序执行，还可以同时执行，本申请实施例不做限定，在此仅做示例性说明。
在步骤S708，第一服务器提取目标DNS记录中的校验串。
本申请实施例中，第一服务器是根据第三字段中的关键词确定是否获取到目标DNS记录，但第一服务器对于目标DNS中是否有具体内容以及是什么内容并不知道，所以需要做进一步判断才能确定目标DNS记录是否是由第三方服务器增加的。目标DNS记录中的校验串即JWT字符串，该步骤中提取的校验串用于后续进行JWT验签，证明目标DNS记录是由第三方服务器写入DNS服务器中并且并没有被篡改过。
在该步骤中，如果第一服务器没有提取到校验串，则第一服务器可以直接执行步骤S711b，返回错误码，拒绝第三方服务器此次的注册请求。
如果第一服务器提取到校验串，则进行下一步骤。
在该步骤中，如果恶意设备想通过猜测查询关键词达到仿冒目的，例如恶意设备猜测到查询关键词，在投递域名对应的DNS服务器上增加了一条DNS记录，但是没有写入校验串，第一服务器提取不到校验串，则可以拒绝恶意设备的注册，防止事件信息被盗取。
在提取校验串过程中，第一服务器可以根据步骤S702中得到的查询关键词从缓存中确定目标DNS记录，并提取到该查询关键词对应的校验串。
示例性的，以步骤S707中给出的目标DNS记录，该步骤中，第一服务器提取到verify_key对应的校验串(lEdor06VsUexUdViEOQCDxwuxdbcOwOJYiQauWd.AtYO73s3mE-Up83tXUDLdzWQ_7rEda95q4J8dXRL1sIdq7eWh6Go33twaxbVw48JdZuup8OhfwyYKF51o.j3kJHmHOH3vSwpi4apW-uS3_fFqpEPLwGJPtmvvjXMntpZv0BqOKIOImlZsubytfFNpDC8cq7_ht2AEECn1kKtcL0yEi_QmlC)。
在步骤S709，第一服务器对校验串进行验证。
在该步骤中，第一服务器主要验证以下至少一方面：
一是验证校验串中的“iss”的签发者域名(即上述第三域名)与公钥地址中的验证域名(即上述第一域名)是否相同；
二是验证校验串中的“iss”的签发者域名(即上述第三域名)、公钥地址中的验证域名(即上述第一域名)、投递地址中的投递域名(即上述第二域名)与第三方应用(或网站)对应的重定向地址(redirect_uri)中的域名(即上述第四域名)是否相同；
三是验证校验串中的签名的是否合法、签名数据是否被篡改。
恶意攻击者能够实现到步骤S709非常困难，因此当第一服务器只验证第一、三方面时，方法700已经可以避免绝大部分的仿冒问题。当第一服务器验证上述三方面时，进一步增加了事件投递过程的安全性。
具体来说，本申请实施例中涉及的重定向地址(redirect_uri)是第三方服务器对应的第三方应用(或网站)在注册账号过程中创建，相当于一个应用的URL。例如第三方服务器在账号系统中注册账号，该账号与第三方应用具有关联关系。重定向地址中的域名为应用可信域名，且重定向地址为设备后台配置，不可更改。第一服务器可以根据第三方服务器提供的应用标识(client ID)，从账号系统中获取重定向地址或重定向地址中的应用可信域名。本申请实施例中验证签发者域名、验证域名、投递域名与重定向地址中的域名一致时，可以证明域名没有被仿冒。
本申请实施例中，验证校验串的签名是否合法、签名数据是否被篡改的过程也可以称为验证签名(即验签)过程。在验签过程中，第一服务器使用步骤S705中获得的公钥，对校验串进行JWT验签。该公钥与第三方服务器进行在JWT签名中使用的私钥相对应。
上文提到，第三方服务器可以在其域名目录下发布多个公钥，第三方服务器可以在注册请求中指示第一服务器获取哪个公钥来进行验签。或者第三方服务器在目标DNS记录中指示第三方服务器使用了哪个私钥进行签名，将私钥标识指示给第一服务器，这样第一服务器可以根据私钥标识获取与私钥对应的公钥。
第一服务器验签的过程大致如下：第一服务器使用公钥对JWT字符串中的哈希签名进行解密，可以得到JWT编码后的头部和编码后的有效载荷。将解密哈希签名得到的编码后的头部、编码后的有效载荷分别与JWT字符串中的第一部分和第二部分比较，若均相同则验签通过。
在步骤S710，判断验证是否通过。
根据步骤S709的验证结果，确定验证是否通过。如果验证不通过，可以认为第三方服务器不具有投递地址所涉及的域名的拥有权，则第一服务器可以直接执行步骤S711b，返回错误码，拒绝第三方服务器此次的注册请求。
如果验证通过，则进行下一步骤。
在步骤S711a，保存注册表，返回成功码。
应理解，本申请实施例示出的注册服务过程步骤仅示例地示出第三方服务器和第一服务器所能执行的操作，对于具体执行操作的先后顺序可以根据实际需要相应调整，例如某些步骤可以合并为一个步骤处理，某些步骤可以同时执行或调换顺序执行等，在此不再一一详述。
第三方服务器注册成功后，接下来可以按照现有技术流程接收第一服务器投递的事件信息。具体地，第三方服务器可以执行如图3中步骤S303至步骤S304的操作，为简洁，在此不再赘述。
上文结合图1至图7详细的描述了本申请实施例的方法实施例，下面结合图8至图11，详细描述本申请实施例的装置实施例。应理解，方法实施例的描述与装置实施例的描述相互对应，因此，未详细描述的部分可以参见前面方法实施例。
图8是本申请实施例提供的一种设备的示意性结构图。图8的设备800可以是上文提及的第一服务器，例如可以是图1所示的第一服务器110或者图2所示的第一服务器220的一个具体的例子。设备800可用于实现上文中的由第一服务器执行的步骤，例如图4或图5的方法，还可以用于具体实现图7所示的实施例。为避免冗余，不再重复描述。
图8所示的设备800包括接收模块810、获取模块820、验签模块830和确定模块840。
接收模块810，用于接收第三方服务器发送的注册请求。
所述注册请求用于请求注册事件投递服务。
所述注册请求包括第一信息、第二信息和第三信息。
其中，所述第一信息用于指示所述第三方服务器的公钥地址，所述公钥地址包括第一域名；所述第二信息用于指示事件信息的投递地址，所述投递地址包括第二域名；所述第三信息用于指示域名系统DNS服务器上的目标DNS记录，所述目标DNS记录包括所述第三方服务器使用所述第三方服务器的私钥创建的数字签名。
获取模块820，用于在所述第一域名与所述第二域名相同的情况下，根据所述第一信息尝试获取所述第三方服务器的公钥；以及根据所述第三信息尝试获取所述目标DNS记录。
验签模块830，用于在获取到所述第三方服务器的公钥和所述目标DNS记录的情况下，根据所述第三方服务器的公钥，对所述目标DNS记录中的数字签名进行验签，得到验签结果。
确定模块840，用于根据所述验签结果确定是否允许所述第三方服务器进行注册。
可选地，所述第三信息包括关键词，获取模块820具体用于，根据所述关键词，在所述DNS服务器上查询所述目标DNS记录。
可选地，所述目标DNS记录包括基于JSON对象的网络令牌JWT，所述JWT包括所述数字签名。
可选地，所述JWT包括以下信息中的至少一种：第三域名，所述第三域名用于指示所述JWT的签发者；所述第三方服务器对应的第三方开发者的标识；所述第三方服务器对应的应用标识，其中所述应用标识用于标识所述第三方服务器对应的应用。
可选地，验签模块830具体用于，提取所述目标DNS记录中的校验串；在提取到所述校验串的情况下，根据所述第三方服务器的公钥对所述校验串进行验签。
可选地，所述第一信息承载于第一字段，所述第三信息承载于第三字段，所述第一字段与所述第三字段属于同一节点。
可选地，确定模块840，用于在所述第一域名与所述第二域名不同的情况下，确定不允许所述第三方服务器进行注册。
可选地，确定模块840，用于在未获取到所述第三方服务器的公钥和/或所述目标DNS记录的情况下，确定不允许所述第三方服务器进行注册。
可选地，确定模块840，用于在未提取到所述校验串的情况下，确定不允许所述第三方服务器进行注册。
可选地，所述事件投递服务包括开放的身份标识openID账号风险事件投递。
图9是本申请实施例提供的一种装置的示意性结构图。图9中的装置900可以是图1中的第一服务器110或图2中的第一服务器220一个具体的例子。图9所示的装置可以用于执行图4或图5中的方法，并具体实现图7所示的实施例，为避免冗余，不再重复描述。
该装置900可以是上文中的第一服务器，也可以是第一服务器中的装置，或者是能够和第一服务器匹配使用的装置。其中，该装置900可以为芯片系统。本申请实施例中，芯片系统可以由芯片构成，也可以包含芯片和其他分立器件。装置900包括至少一个处理器920，用于实现本申请实施例提供的方法，具体参见方法示例中的详细描述，此处不做赘述。
装置900还可以包括至少一个存储器910，用于存储程序指令和/或数据。存储器910和处理器920耦合。本申请实施例中的耦合是装置、单元或模块之间的间接耦合或通信连接，可以是电性，机械或其它的形式，用于装置、单元或模块之间的信息交互。处理器910可能和存储器920协同操作。处理器910可能执行存储器920中存储的程序指令。所述至少一个存储器中的至少一个可以包括于处理器中。
装置900还可以包括通信接口930，用于通过传输介质和其它设备进行通信，从而用于装置900中的装置可以和其它设备进行通信。示例性的，通信接口可以是收发器、电路、总线、模块、管脚或其它类型的通信接口。示例性地，装置900是第一服务器，该其它设备是为第三方服务器。处理器920利用通信接口930收发数据，并用于实现图4-6对应的实施例中所述第一服务器所执行的方法。
本申请实施例中不限定上述通信接口930、处理器920以及存储器910之间的具体连接介质。本申请实施例在图9中以存储器910、处理器920以及通信接口930之间通过总线940连接。
图10是本申请实施例提供的一种设备的示意性结构图。图10的设备1000可以是上文提及的第一服务器，例如可以是图1所示的第一服务器110或者图2所示的第一服务器220的一个具体的例子。设备1000可用于实现上文中的由第一服务器执行的步骤，例如图4或图6的方法，还可以用于具体实现图7所示的实施例。为避免冗余，不再重复描述。
图10所示的设备1000包括接收模块1010、获取模块1020、验签模块1030和确定模块1040。
接收模块1010，用于接收第三方服务器发送的注册请求。
所述注册请求用于请求注册事件投递服务。
所述注册请求包括第一信息、第二信息和第三信息。
其中，所述第一信息用于指示所述第三方服务器的公钥地址，所述公钥地址包括第一域名；所述第二信息用于指示事件信息的投递地址，所述投递地址包括第二域名；所述第三信息用于指示域名系统DNS服务器上的目标DNS记录，所述目标DNS记录包括所述第三方服务器使用所述第三方服务器的私钥创建的数字签名和所述第三方服务器对应的应用标识，所述应用标识用于标识所述第三方服务器对应的应用。
获取模块1020，用于在所述第一域名与所述第二域名相同的情况下，根据所述第一信息尝试获取所述第三方服务器的公钥；以及根据所述第三信息尝试获取所述目标DNS记录。
验签模块1030，用于在获取到所述第三方服务器的公钥和所述目标DNS记录的情况下，根据所述第三方服务器的公钥，对所述目标DNS记录中的数字签名进行验签，得到验签结果。
获取模块1020，用于在所述验签结果通过的情况下，根据所述第三方服务器对应的应用标识，获取所述第三方服务器对应的应用的重定向地址，所述重定向地址包括第四域名。
确定模块1040，用于在所述第二域名与所述第四域名相同的情况下，确定允许所述第三方服务器进行注册。
可选地，所述第三信息包括关键词，获取模块1020具体用于，根据所述关键词，在所述DNS服务器上查询所述目标DNS记录。
可选地，所述目标DNS记录包括基于JSON对象的网络令牌JWT，所述JWT包括所述数字签名。
可选地，所述JWT包括以下信息中的至少一种：第三域名，所述第三域名用于指示所述JWT的签发者；所述第三方服务器对应的第三方开发者的标识；所述第三方服务器对应的应用标识。
可选地，验签模块1030具体用于，提取所述目标DNS记录中的校验串；在提取到所述校验串的情况下，根据所述第三方服务器的公钥对所述校验串进行验签。
可选地，所述第一信息承载于第一字段，所述第三信息承载于第三字段，所述第一字段与所述第三字段属于同一节点。
可选地，确定模块840，用于在所述第一域名与所述第二域名不同的情况下，确定不允许所述第三方服务器进行注册。
可选地，确定模块840，用于在未获取到所述第三方服务器的公钥和/或所述目标DNS记录的情况下，确定不允许所述第三方服务器进行注册。
可选地，确定模块840，用于在所述验签结果不通过的情况下，确定不允许所述第三方服务器进行注册。
可选地，确定模块840，用于在所述第二域名与所述第四域名不同的情况下，确定不允许所述第三方服务器进行注册。
可选地，确定模块840，用于在未提取到所述校验串的情况下，确定不允许所述第三方服务器进行注册。
可选地，所述事件投递服务包括openID账号风险事件投递。
图11是本申请实施例提供的一种装置的示意性结构图。图11中的装置1100可以是图1中的第一服务器110或图2中的第一服务器220一个具体的例子。图11所示的装置可以用于执行图4或图6中的方法，并具体实现图7所示的实施例，为避免冗余，不再重复描述。
该装置1100可以是上文中的第一服务器，也可以是第一服务器中的装置，或者是能够和第一服务器匹配使用的装置。其中，该装置1100可以为芯片系统。本申请实施例中，芯片系统可以由芯片构成，也可以包含芯片和其他分立器件。装置1100包括至少一个处理器1120，用于实现本申请实施例提供的方法，具体参见方法示例中的详细描述，此处不做赘述。
装置1100还可以包括至少一个存储器1110，用于存储程序指令和/或数据。存储器1110和处理器1120耦合。本申请实施例中的耦合是装置、单元或模块之间的间接耦合或通信连接，可以是电性，机械或其它的形式，用于装置、单元或模块之间的信息交互。处理器1110可能和存储器1120协同操作。处理器1110可能执行存储器1120中存储的程序指令。所述至少一个存储器中的至少一个可以包括于处理器中。
装置1100还可以包括通信接口1130，用于通过传输介质和其它设备进行通信，从而用于装置1100中的装置可以和其它设备进行通信。示例性的，通信接口可以是收发器、电路、总线、模块、管脚或其它类型的通信接口。示例性地，装置1100是第一服务器，该其它设备是为第三方服务器。处理器1120利用通信接口1130收发数据，并用于实现图4-6对应的实施例中所述第一服务器所执行的方法。
本申请实施例中不限定上述通信接口1130、处理器1120以及存储器1110之间的具体连接介质。本申请实施例在图11中以存储器1110、处理器1120以及通信接口1130之间通过总线1140连接。
本领域普通技术人员可以意识到，结合本文中所公开的实施例描述的各示例的单元及算法步骤，能够以电子硬件、或者计算机软件和电子硬件的结合来实现。这些功能究竟以硬件还是软件方式来执行，取决于技术方案的特定应用和设计约束条件。专业技术人员可以对每个特定的应用来使用不同方法来实现所描述的功能，但是这种实现不应认为超出本申请的范围。
所属领域的技术人员可以清楚地了解到，为描述的方便和简洁，上述描述的系统、装置和单元的具体工作过程，可以参考前述方法实施例中的对应过程，在此不再赘述。
在本申请所提供的几个实施例中，应该理解到，所揭露的系统、装置和方法，可以通过其它的方式实现。例如，以上所描述的装置实施例仅仅是示意性的，例如，所述单元的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，例如多个单元或组件可以结合或者可以集成到另一个系统，或一些特征可以忽略，或不执行。另一点，所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些接口，装置或单元的间接耦合或通信连接，可以是电性，机械或其它的形式。
所述作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部单元来实现本实施例方案的目的。
另外，在本申请各个实施例中的各功能单元可以集成在一个处理单元中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个单元中。
所述功能如果以软件功能单元的形式实现并作为独立的产品销售或使用时，可以存储在一个计算机可读取存储介质中。基于这样的理解，本申请的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质中，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)执行本申请各个实施例所述方法的全部或部分步骤。而前述的存储介质包括：U盘、移动硬盘、只读存储器(read-only memory，ROM)、随机存取存储器(random access memory，RAM)、磁碟或者光盘等各种可以存储程序代码的介质。
以上所述，仅为本申请的具体实施方式，但本申请的保护范围并不局限于此，任何熟悉本技术领域的技术人员在本申请揭露的技术范围内，可轻易想到变化或替换，都应涵盖在本申请的保护范围之内。因此，本申请的保护范围应以所述权利要求的保护范围为准。

Claims (21)

1.一种注册服务的方法，其特征在于，包括：
接收第三方服务器发送的注册请求，所述注册请求用于请求注册事件投递服务，所述注册请求包括第一信息、第二信息和第三信息，其中，
所述第一信息用于指示所述第三方服务器的公钥地址，所述公钥地址包括第一域名，
所述第二信息用于指示事件信息的投递地址，所述投递地址包括第二域名，
所述第三信息用于指示域名系统DNS服务器上的目标DNS记录，所述目标DNS记录包括所述第三方服务器使用所述第三方服务器的私钥创建的数字签名；
在所述第一域名与所述第二域名相同的情况下，
根据所述第一信息尝试获取所述第三方服务器的公钥；以及
根据所述第三信息尝试获取所述目标DNS记录；
在获取到所述第三方服务器的公钥和所述目标DNS记录的情况下，
根据所述第三方服务器的公钥，对所述目标DNS记录中的数字签名进行验签，得到验签结果；
根据所述验签结果确定是否允许所述第三方服务器进行注册。
2.根据权利要求1所述的方法，其特征在于，所述第三信息包括关键词，
所述根据所述第三信息尝试获取所述目标DNS记录，包括：
根据所述关键词，在所述DNS服务器上查询所述目标DNS记录。
3.根据权利要求1或2所述的方法，其特征在于，所述目标DNS记录包括基于JSON对象的网络令牌JWT，所述JWT包括所述数字签名。
4.根据权利要求3所述的方法，其特征在于，所述JWT包括以下信息中的至少一种：
第三域名，所述第三域名用于指示所述JWT的签发者；
所述第三方服务器对应的第三方开发者的标识；
所述第三方服务器对应的应用标识，其中所述应用标识用于标识所述第三方服务器对应的应用。
5.根据权利要求1至4中任一项所述的方法，其特征在于，所述根据所述第三方服务器的公钥，对所述目标DNS记录中的数字签名进行验签，包括：
提取所述目标DNS记录中的校验串；
在提取到所述校验串的情况下，根据所述第三方服务器的公钥对所述校验串进行验签。
6.根据权利要求1至5中任一项所述的方法，其特征在于，所述第一信息承载于第一字段，所述第三信息承载于第三字段，所述第一字段与所述第三字段属于同一节点。
7.根据权利要求1至6中任一项所述的方法，其特征在于，还包括：
在所述第一域名与所述第二域名不同的情况下，确定不允许所述第三方服务器进行注册；或者，
在未获取到所述第三方服务器的公钥和/或所述目标DNS记录的情况下，确定不允许所述第三方服务器进行注册。
8.根据权利要求5至7中任一项所述的方法，其特征在于，还包括：
在未提取到所述校验串的情况下，确定不允许所述第三方服务器进行注册。
9.根据权利要求1至8中任一项所述的方法，其特征在于，所述事件投递服务包括开放的身份标识openID账号风险事件投递。
10.一种注册服务的方法，其特征在于，包括：
接收第三方服务器发送的注册请求，所述注册请求用于请求注册事件投递服务，所述注册请求包括第一信息、第二信息和第三信息，其中，
所述第一信息用于指示所述第三方服务器的公钥地址，所述公钥地址包括第一域名，
所述第二信息用于指示事件信息的投递地址，所述投递地址包括第二域名，
所述第三信息用于指示域名系统DNS服务器上的目标DNS记录，所述目标DNS记录包括所述第三方服务器使用所述第三方服务器的私钥创建的数字签名和所述第三方服务器对应的应用标识，所述应用标识用于标识所述第三方服务器对应的应用；
在所述第一域名与所述第二域名相同的情况下，
根据所述第一信息尝试获取所述第三方服务器的公钥；以及
根据所述第三信息尝试获取所述目标DNS记录；
在获取到所述第三方服务器的公钥和所述目标DNS记录的情况下，
根据所述第三方服务器的公钥，对所述目标DNS记录中的数字签名进行验签，得到验签结果；
在所述验签结果通过的情况下，
根据所述第三方服务器对应的应用标识，获取所述第三方服务器对应的应用的重定向地址，所述重定向地址包括第四域名；
在所述第二域名与所述第四域名相同的情况下，确定允许所述第三方服务器进行注册。
11.根据权利要求10所述的方法，其特征在于，所述第三信息包括关键词，
所述根据所述第三信息尝试获取所述目标DNS记录，包括：
根据所述关键词，在所述DNS服务器上查询所述目标DNS记录。
12.根据权利要求10或11所述的方法，其特征在于，所述目标DNS记录包括基于JSON对象的网络令牌JWT，所述JWT包括所述数字签名。
13.根据权利要求12所述的方法，其特征在于，所述JWT包括以下信息中的至少一种：
第三域名，所述第三域名用于指示所述JWT的签发者；
所述第三方服务器对应的第三方开发者的标识；
所述第三方服务器对应的应用标识。
14.根据权利要求10至13中任一项所述的方法，其特征在于，所述根据所述第三方服务器的公钥，对所述目标DNS记录中的数字签名进行验签，包括：
提取所述目标DNS记录中的校验串；
在提取到所述校验串的情况下，根据所述第三方服务器的公钥对所述校验串进行验签。
15.根据权利要求10至14中任一项所述的方法，其特征在于，所述第一信息承载于第一字段，所述第三信息承载于第三字段，所述第一字段与所述第三字段属于同一节点。
16.根据权利要求10至15中任一项所述的方法，其特征在于，还包括：
在所述第一域名与所述第二域名不同的情况下，确定不允许所述第三方服务器进行注册；或者，
在未获取到所述第三方服务器的公钥和/或所述目标DNS记录的情况下，确定不允许所述第三方服务器进行注册；或者，
在所述验签结果不通过的情况下，确定不允许所述第三方服务器进行注册；或者，
在所述第二域名与所述第四域名不同的情况下，确定不允许所述第三方服务器进行注册。
17.根据权利要求14至16中任一项所述的方法，其特征在于，还包括：
在未提取到所述校验串的情况下，确定不允许所述第三方服务器进行注册。
18.根据权利要求10至17中任一项所述的方法，其特征在于，所述事件投递服务包括openID账号风险事件投递。
19.一种设备，其特征在于，其特征在于，包括用于执行如权利要求1至9中任一项所述的注册服务的方法的模块；或者用于执行如权利要求10至18中任一项所述的注册服务的方法的模块。
20.一种装置，其特征在于，包括处理器和存储器，所述存储器存储有指令，所述处理器用于从所述存储器中调用并执行所述指令，使得所述装置执行如权利要求1至18中任一项所述的注册服务的方法。
21.一种计算机可读存储介质，其特征在于，存储有计算机程序，当所述计算机程序在计算机上运行时，使得所述计算机执行如权利要求1至18中任一项所述的方法。
CN202010812614.5A 2020-08-13 2020-08-13 注册服务的方法及设备 Active CN114079645B (zh)

Priority Applications (4)

Application Number Priority Date Filing Date Title
CN202010812614.5A CN114079645B (zh) 2020-08-13 2020-08-13 注册服务的方法及设备
US18/041,367 US20230299973A1 (en) 2020-08-13 2021-08-03 Service registration method and device
PCT/CN2021/110184 WO2022033350A1 (zh) 2020-08-13 2021-08-03 注册服务的方法及设备
EP21855403.8A EP4203377A4 (en) 2020-08-13 2021-08-03 SERVICE REGISTRATION METHOD AND DEVICE

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN202010812614.5A CN114079645B (zh) 2020-08-13 2020-08-13 注册服务的方法及设备

Publications (2)

Publication Number Publication Date
CN114079645A true CN114079645A (zh) 2022-02-22
CN114079645B CN114079645B (zh) 2022-12-30

Family

ID=80247722

Family Applications (1)

Application Number Title Priority Date Filing Date
CN202010812614.5A Active CN114079645B (zh) 2020-08-13 2020-08-13 注册服务的方法及设备

Country Status (4)

Country Link
US (1) US20230299973A1 (zh)
EP (1) EP4203377A4 (zh)
CN (1) CN114079645B (zh)
WO (1) WO2022033350A1 (zh)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN114979071A (zh) * 2022-06-16 2022-08-30 Oppo广东移动通信有限公司 动态域名配置方法、装置、电子设备及存储介质

Families Citing this family (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN115242658B (zh) * 2022-07-22 2023-08-29 中国平安财产保险股份有限公司 开放系统访问方法、装置、计算机设备及存储介质

Citations (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20150180857A1 (en) * 2013-12-23 2015-06-25 Joseph Schulman Simple user management service utilizing an access token
CN106603225A (zh) * 2015-10-15 2017-04-26 捷玛计算机信息技术（上海）股份有限公司 为企业信息服务器提供信息验证的验证方法
CN106790296A (zh) * 2017-03-16 2017-05-31 中国联合网络通信集团有限公司 域名记录验证方法及装置
CN107786571A (zh) * 2017-11-07 2018-03-09 昆山云景商务服务有限公司 一种用户统一认证的方法
US20190306138A1 (en) * 2018-03-27 2019-10-03 Oracle International Corporation Cross-Region Trust for a Multi-Tenant Identity Cloud Service
CN110875925A (zh) * 2018-08-30 2020-03-10 佳能株式会社 信息处理装置、授权系统及验证方法
CN111327582A (zh) * 2019-08-22 2020-06-23 刘高峰 一种基于OAuth协议的授权方法、装置及系统

Family Cites Families (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US9130917B2 (en) * 2011-05-02 2015-09-08 Verisign, Inc. DNSSEC signing server
CN104378399B (zh) * 2013-08-15 2019-08-23 腾讯科技（深圳）有限公司 一种数据推送方法、平台服务器、客户端以及系统
US9762556B2 (en) * 2015-01-09 2017-09-12 Verisign, Inc. Registering, managing, and communicating with IOT devices using domain name system processes
US10673894B2 (en) * 2018-09-26 2020-06-02 KnowBe4, Inc. System and methods for spoofed domain identification and user training
CN109714447B (zh) * 2018-12-20 2021-09-10 全链通有限公司 基于区块链域名系统的域名生成方法和系统

Patent Citations (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20150180857A1 (en) * 2013-12-23 2015-06-25 Joseph Schulman Simple user management service utilizing an access token
CN106603225A (zh) * 2015-10-15 2017-04-26 捷玛计算机信息技术（上海）股份有限公司 为企业信息服务器提供信息验证的验证方法
CN106790296A (zh) * 2017-03-16 2017-05-31 中国联合网络通信集团有限公司 域名记录验证方法及装置
CN107786571A (zh) * 2017-11-07 2018-03-09 昆山云景商务服务有限公司 一种用户统一认证的方法
US20190306138A1 (en) * 2018-03-27 2019-10-03 Oracle International Corporation Cross-Region Trust for a Multi-Tenant Identity Cloud Service
CN110875925A (zh) * 2018-08-30 2020-03-10 佳能株式会社 信息处理装置、授权系统及验证方法
CN111327582A (zh) * 2019-08-22 2020-06-23 刘高峰 一种基于OAuth协议的授权方法、装置及系统

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
P. WOUTERS等: "Using DANE to Associate OpenPGP public keys with email addresses draft-ietf-dane-openpgpkey-12", 《IETF 》 *

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN114979071A (zh) * 2022-06-16 2022-08-30 Oppo广东移动通信有限公司 动态域名配置方法、装置、电子设备及存储介质
CN114979071B (zh) * 2022-06-16 2024-03-26 Oppo广东移动通信有限公司 动态域名配置方法、装置、电子设备及存储介质

Also Published As

Publication number Publication date
CN114079645B (zh) 2022-12-30
WO2022033350A1 (zh) 2022-02-17
EP4203377A4 (en) 2024-04-10
EP4203377A1 (en) 2023-06-28
US20230299973A1 (en) 2023-09-21

Similar Documents

Publication Publication Date Title
AU2021206913B2 (en) Systems and methods for distributed data sharing with asynchronous third-party attestation
US10439826B2 (en) Identity-based certificate management
EP1697818B1 (en) Authentication system for networked computer applications
US7725723B2 (en) Data certification method and apparatus
US7512782B2 (en) Method and system for using a web service license
KR100962399B1 (ko) 익명 공개 키 기반구조 제공 방법 및 이를 이용한 서비스제공 방법
CN111901346B (zh) 一种身份认证系统
KR102177848B1 (ko) 액세스 요청을 검증하기 위한 방법 및 시스템
US20030208681A1 (en) Enforcing file authorization access
US20050144439A1 (en) System and method of managing encryption key management system for mobile terminals
US20080263644A1 (en) Federated authorization for distributed computing
EP2957064B1 (en) Method of privacy-preserving proof of reliability between three communicating parties
CN109981287A (zh) 一种代码签名方法及其存储介质
CN114079645B (zh) 注册服务的方法及设备
KR20090054774A (ko) 분산 네트워크 환경에서의 통합 보안 관리 방법
Kim et al. Can we create a cross-domain federated identity for the industrial Internet of Things without Google?
KR20030035025A (ko) 공개키 기반구조의 공인 인증서를 이용한 신원확인 서비스제공 시스템 및 그 방법
WO2015184507A1 (en) Identity verification
Alrodhan Privacy and practicality of identity management systems
Melara CONIKS: Preserving Secure Communication with Untrusted Identity Providers
CN115118431A (zh) 一种跨域身份认证票据转换方法
WO2008084068A1 (en) Method and systems for proving the authenticity of a client to a server

Legal Events

Date Code Title Description
PB01 Publication
PB01 Publication
SE01 Entry into force of request for substantive examination
SE01 Entry into force of request for substantive examination
TA01 Transfer of patent application right

Effective date of registration: 20220524

Address after: 523808 Southern Factory Building (Phase I) Project B2 Production Plant-5, New Town Avenue, Songshan Lake High-tech Industrial Development Zone, Dongguan City, Guangdong Province

Applicant after: HUAWEI DEVICE Co.,Ltd.

Address before: 518129 Bantian HUAWEI headquarters office building, Longgang District, Guangdong, Shenzhen

Applicant before: HUAWEI TECHNOLOGIES Co.,Ltd.

Effective date of registration: 20220524

Address after: 523799 Room 101, building 4, No. 15, Huanhu Road, Songshanhu Park, Dongguan City, Guangdong Province

Applicant after: Petal cloud Technology Co.,Ltd.

Address before: 523808 Southern Factory Building (Phase I) Project B2 Production Plant-5, New Town Avenue, Songshan Lake High-tech Industrial Development Zone, Dongguan City, Guangdong Province

Applicant before: HUAWEI DEVICE Co.,Ltd.

TA01 Transfer of patent application right
GR01 Patent grant
GR01 Patent grant