CN115622747A - Api授权认证处理方法、装置、电子设备和存储介质 - Google Patents

Api授权认证处理方法、装置、电子设备和存储介质 Download PDF

Info

Publication number
CN115622747A
CN115622747A CN202211158054.1A CN202211158054A CN115622747A CN 115622747 A CN115622747 A CN 115622747A CN 202211158054 A CN202211158054 A CN 202211158054A CN 115622747 A CN115622747 A CN 115622747A
Authority
CN
China
Prior art keywords
application
api
digital signature
service
party
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.)
Pending
Application number
CN202211158054.1A
Other languages
English (en)
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.)
China Construction Bank Corp
CCB Finetech Co Ltd
Original Assignee
China Construction Bank Corp
CCB Finetech 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 China Construction Bank Corp, CCB Finetech Co Ltd filed Critical China Construction Bank Corp
Priority to CN202211158054.1A priority Critical patent/CN115622747A/zh
Publication of CN115622747A publication Critical patent/CN115622747A/zh
Pending legal-status Critical Current

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/08—Network architectures or network communication protocols for network security for authentication of entities
    • H04L63/083—Network architectures or network communication protocols for network security for authentication of entities using passwords
    • 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/04—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks
    • H04L63/0428—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks wherein the data content is protected, e.g. by encrypting or encapsulating the payload
    • 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
    • H04L63/0807—Network architectures or network communication protocols for network security for authentication of entities using tickets, e.g. Kerberos
    • 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
    • H04L63/0861—Network architectures or network communication protocols for network security for authentication of entities using biometrical features, e.g. fingerprint, retina-scan
    • 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/10—Network architectures or network communication protocols for network security for controlling access to devices or network resources
    • 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

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)
  • Health & Medical Sciences (AREA)
  • Biomedical Technology (AREA)
  • General Health & Medical Sciences (AREA)
  • Telephonic Communication Services (AREA)

Abstract

本申请公开了一种API授权认证处理方法、装置、电子设备和存储介质，涉及大数据数据访问技术领域，其中，方法包括：接收应用方在调用API授权平台的目标API时发送的服务请求，服务请求中包括与服务请求参数关联的第一数字签名；对第一数字签名进行验证；在第一数字签名通过验证的情况下，将服务请求转发给对应的业务服务器，以获取业务服务器返回服务结果；将服务结果返回给应用方。该方法通过对第一数字签名进行验证，实现对应用方的身份进行验证，实现了对API授权认证管理，降低了应用方与服务提供方之间的对接成本。

Description

API授权认证处理方法、装置、电子设备和存储介质
技术领域
本申请涉及大数据数据访问技术领域，尤其涉及一种API授权认证处理方法、装置、电子设备和存储介质。
背景技术
随着互联网技术发展，提供服务的业务***越来越多，因此为用户提供的服务也日益增多。相关技术中，通常是应用方与业务***之间进行对接，当应用方发起调用请求时，业务***根据请求提供相应的服务。
但是，大多服务提供方使用的应用程序编程接口(Application ProgrammingInterface，API)风格不尽相同，应用方与服务提供方之间的对接成本较高。
发明内容
本申请提供一种API授权认证处理方法、装置、电子设备和存储介质，以至少在一定程度上解决相关技术中的技术问题之一。本申请的技术方案如下：
根据本申请实施例的第一方面，提供一种API授权认证处理方法，可应用于API授权认证平台，该方法包括：
接收应用方在调用所述API授权平台的目标API时发送的服务请求，其中，所述服务请求中包括与所述服务请求参数关联的第一数字签名；
对所述第一数字签名进行验证；
在所述第一数字签名通过验证的情况下，将所述服务请求转发给对应的业务服务器，以获取所述业务服务器返回的所述服务请求对应的服务结果；
将服务结果返回给应用方。
根据本申请实施例的第二方面，提供一种API授权认证处理装置，包括：
接收模块，被配置为接收应用方在调用所述API授权平台的目标API时发送的服务请求，其中，所述服务请求中包括与所述服务请求参数关联的第一数字签名；
验证模块，被配置为对所述第一数字签名进行验证；
转发模块，被配置为在所述第一数字签名通过验证的情况下，将所述服务请求转发给对应的业务服务器，以获取所述业务服务器返回的所述服务请求对应的服务结果；
发送模块，被配置为将服务结果返回给应用方。
根据本申请实施例的第三方面，提供一种电子设备，包括：处理器；用于存储所述处理器可执行指令的存储器；其中，所述处理器被配置为执行所述指令，以实现如本申请上述实施例所述的方法。
根据本申请实施例的第四方面，提供一种计算机可读存储介质，当所述计算机可读存储介质中的指令由电子设备的处理器执行时，使得电子设备能够执行如本申请上述实施例所述的方法。
根据本申请实施例的第五方面，提供一种计算机程序产品，包括：计算机程序，所述计算机程序被处理器执行时实现如本申请上述实施例所述的方法。
本申请的实施例提供的技术方案至少带来以下有益效果：API授权认证平台可以通过对第一数字签名进行验证，实现对应用方的身份进行验证，若验证通过，说明应用方有权限调用目标API，实现了对API授权认证管理，从而应用方可以通过API授权认证平台调用服务提供方的API，降低了应用方与服务提供方之间的对接成本，服务提供方也无需重复实现API访问控制逻辑，减少了服务提供方的处理负担。
应当理解的是，以上的一般描述和后文的细节描述仅是示例性和解释性的，并不能限制本申请。
附图说明
此处的附图被并入说明书中并构成本说明书的一部分，示出了符合本申请的实施例，并与说明书一起用于解释本申请的原理，并不构成对本申请的不当限定。
图1是本申请一实施例提供的API授权认证处理方法的流程示意图。
图2为本申请实施例提供的应用方、API授权认证平台及业务提供方之间的关系示意图。
图3是本申请另一实施例提供的API授权认证处理方法的流程示意图。
图4是本申请另一实施例提供的API授权认证处理方法的流程示意图。
图5是本申请另一实施例提供的API授权认证处理方法的流程示意图。
图6是本申请另一实施例提供的API授权认证处理方法的流程示意图。
图7是本申请实施例提供的一交互流程示意图。
图8是本申请实施例提供的另一交互流程示意图。
图9是本申请实施例提供的另一交互流程示意图。
图10是本申请一实施例提供的API授权认证处理装置的结构示意图。
图11为本申请一实施例提供的电子设备的结构示意图。
具体实施方式
为了使本领域普通人员更好地理解本申请的技术方案，下面将结合附图，对本申请实施例中的技术方案进行清楚、完整地描述。
需要说明的是，本申请的说明书和权利要求书及上述附图中的术语“第一”、“第二”等是用于区别类似的对象，而不必用于描述特定的顺序或先后次序。应该理解这样使用的数据在适当情况下可以互换，以便这里描述的本申请的实施例能够以除了在这里图示或描述的那些以外的顺序实施。以下示例性实施例中所描述的实施方式并不代表与本申请相一致的所有实施方式。相反，它们仅是与如所附权利要求书中所详述的、本申请的一些方面相一致的装置和方法的例子。
本申请技术方案中对数据的获取、存储、使用、处理等均符合国家法律法规的相关规定。
随着互联网技术发展，提供服务的业务***越来越多，因此为用户提供的服务也日益增多。相关技术中，通常是应用方与业务***之间进行对接，当应用方发起调用请求时，业务***根据请求提供相应的服务。
但是，大多服务提供方所使用的API风格不尽相同，应用方与服务提供方之间的对接成本较高。并且，业务服务***需要重复实现API访问控制逻辑，比如验证、鉴权等，比较繁琐。基于此，本申请实施例提供了一种API授权认证处理方法。
下面参考附图描述本申请实施例的API授权认证处理方法、装置、电子设备和存储介质。图1是本申请一实施例提供的API授权认证处理方法的流程示意图。
本申请实施例以该API授权认证处理方法被配置于API授权认证平台中来举例说明，该API授权认证平台可以应用于任一电子设备中，以使该电子设备可以执行API授权认证处理功能。
其中，电子设备可以为任一具有计算能力的设备，例如可以为服务器等。
本申请的API授权认证平台可以包括API接入平台、用户授权鉴权***、API后台管理者门户、API监控平台等部分。
其中，API接入平台，提供外网HTTPS、HTTP2、HTTP等协议转换适配到内网HTTP协议或其他内部协议，安全方面提供认证验签、验签加固、WAF、防刷、限流、风控，移动接入优化如SSL加解密异步化、流量管控、异地多活，其他方面提供轻量数据聚合、多租户等。
用户授权鉴权***，可提供对外接口中的权限控制。比如，对合法注册的应用的内部资源交易接口访问生成访问令牌，校验第三方请求附带的访问令牌的合法性，支持用户授权访问用户个人信息。
如图1所示，该API授权认证处理方法可以包括以下步骤101-步骤105。
步骤101，接收应用方在调用API授权平台的目标API时发送的服务请求。
本申请中，服务提供方可以按照统一的接口标准开发API，并在API授权认证平台进行注册发布，由此，API授权认证平台可以集成多个服务提供方的API，应用方可以通过API授权认证平台调用服务提供方的API，从而可以减少应用方与服务提供方之间的对接成本，并且业务服务器也无需重复实现API访问控制逻辑。其中，应用方可以是应用客户端，也可以是应用服务端。
本申请中，当某服务提供方申请注册API时，API授权认证平台可以获取API注册请求，其中，注册请求中可以包括待注册API的标识，API授权认证平台可以根据待注册API的标识，查询API数据库，以确定待注册API是否已经注册过。如果API数据库中未包含待注册API的标识，那么可以将待注册API的标识添加到API数据库，如果API数据库中包含待注册API的标识，说明该API已经注册过，那么可以向服务提供方返回API已注册的提示信息。由此，API授权认证平台可以集成服务提供方的API。
为了便于理解，下面结合图2进行说明，图2为本申请实施例提供的应用方、API授权认证平台及业务提供方之间的关系示意图。
如图2中所示，服务提供方可以采用统一的接口标准开发API并在平台进行注册，其中，服务提供方可以包括手机服务、公有云服务、第三方服务等。
服务使用方可以是前端应用，也可以是后端服务，其中，前端应用比如可以是前端PC端、移动APP、小程序等可以发起前端调用。服务使用方的前端应用可以通过统一提供的JavaScript软件开发工具包发起服务请求。服务使用方如果是后端服务，使用Java软件开发工具包发起服务请求。
本申请中，当应用客户端或应用服务端需要发起服务请求时，可以调用API授权认证平台的目标API，由此，API授权认证平台可以接收应用方发送的服务请求。
比如，用户在某应用客户端进行刷脸认证操作时，该应用客户端需要使用第三方的刷脸认证服务。又如，用户在某浏览器页面进行查询利率***息的操作时，该页面需要使用第三方的利率业务服务。
本申请中，应用方在向API授权认证平台发送服务请求之前，可以对服务请求参数进行加密，或者对服务请求相关的信息进行加密，生成第一数字签名，应用方向API授权认证平台发送服务请求中可以携带第一数字签名。
步骤102，对第一数字签名进行验证。
本申请中，API授权认证平台可以根据预设的加解密规则，对第一数字签名进行验证。比如，第一数字签名是用应用方的私钥进行加密的，那么API授权认证平台可以利用与应用方的私钥成对的公钥，对第一数字签名进行验证。
本申请中，API授权认证平台对应用方的第一数字签名进行验证，可以确定应用方的身份及在验证身份的基础上再验证传递的明文数据是否被篡改过。
步骤103，在第一数字签名验证通过的情况下，将服务请求转发给对应的业务服务器，以获取业务服务器返回的服务请求对应的服务结果。
本申请中，如果第一数字签名验证通过，可以认为应用方具有调用目标API的权限，说明服务请求为合法请求，那么API授权认证平台可以将应用方的服务请求转发给对应的业务服务器，业务服务器可以对服务请求进行处理，并返回服务请求对应的服务结果。
以图2为例，服务使用方也即应用方发起的请求经过平台的鉴权和寻址，路由到服务提供方的API，从而由服务提供方可以获取服务请求，并对服务请求进行处理。
在实际应用中，可能有多个服务提供方提供相同的业务服务，应用方可以指定调用哪个服务提供方的业务服务。本申请中，API授权认证平台在转发服务请求时，如果服务请求中包含统一资源定位符(Uniform Resource Locator，URL)，那么可以根据URL将服务请求转发给指定的业务服务器。
比如，配置了服务为my-service，API Path为空，业务服务器的URL为http://127.0.0.1:8080/forward-service/，可以将那么服务请求http://{ip}:{port}/proxy/my-service/api-path将转发到http://127.0.0.1:8080/forward-service/api-path。
或者，本申请中，也可以根据服务请求所请求的业务服务，确定服务请求的请求路径，从而根据服务请求的请求路径将服务请求转发到对应的业务服务器。比如，服务请求是关于刷脸认证的，那么确定该服务请求的请求路径，从而将服务请求转发给提供刷脸认证服务的业务服务器。
可见，本申请中，API授权认证平台可以提供不同类型的转发方式，可以按照请求路径转发，也可以根据URL转发到指定的业务服务器，从而可以满足多样化需求。
步骤104，将服务结果返回给应用方。
本申请中，API授权认证平台可以将服务结果直接返回给应用方，或者为了提高数据的安全性，也可以对服务结果进行加密，将加密后服务结果返回给应用方。
本申请实施例中，通过接收应用方在调用API授权平台的目标API时发送的服务请求，并对服务请求中与服务请求参数关联的第一数字签名进行验证，在第一数字签名验证通过的情况下，将服务请求转发给对应的业务服务器，以获取业务服务器返回的服务请求对应的服务结果，并将服务结果返回给应用方。由此，API授权认证平台可以通过对第一数字签名进行验证，实现对应用方的身份进行验证，若验证通过，说明应用方有权限调用目标API，实现了对API授权认证管理，从而应用方可以通过API授权认证平台调用服务提供方的API，降低了应用方与服务提供方之间的对接成本，服务提供方也无需重复实现API访问控制逻辑，减少了服务提供方的处理负担。
图3是本申请另一实施例提供的API授权认证处理方法的流程示意图。
如图3所示，该API授权认证处理方法包括：
步骤301，接收应用方在调用API授权平台的目标API时发送的服务请求。
步骤302，对第一数字签名进行验证。
步骤303，在第一数字签名验证通过的情况下，将服务请求转发给对应的业务服务器，以获取业务服务器返回的服务请求对应的服务结果。
本申请中，步骤301-步骤303与上述实施例记载的内容类似，故在此不再赘述。
步骤304，利用API授权认证平台的第一私钥对服务结果进行加密，得到第二数字签名。
为了提高安全性，本申请中，API授权认证平台可以预先生成一对私钥和公钥，API授权认证平台可以利用自身的私钥对服务结果进行加密，以生成第二数字签名。
步骤305，将第二数字签名返回给应用方，以使应用方使用第一私钥对应的第一公钥对第二数字签名进行验证。
本申请中，API授权认证平台将第二数字签名返回给应用方，也即将数字签名后的服务结果返回给应用方。
若应用方为应用客户端，应用客户端可以将第二数字签名发送给应用服务端，应用服务端可以利用预先获取的与第一私钥对应的第一公钥，也即利用API授权认证平台的公钥，对第二数字签名进行验证。若通过验证，说明服务结果是API授权认证平台返回的，应用服务端可以将解密后得到的服务结果返回给应用客户端；如果未通过验证，说明服务结果不是API授权认证平台返回的。
若应用方为应用服务端，那么应用服务端可以利用API授权认证平台的第一公钥对第二数字签名进行验证，若验证通过得到解密后的服务结果。
本申请中实施例中，在将服务结果返回给应用方时，可以利用API授权认证平台的第一私钥对服务结果进行加密，得到第二数字签名，将第二数字签名返回给应用方，以使应用方获取利用第一私钥对应的第一公钥对第二数字签名验证后的结果。由此，通过对服务结果进行加密得到第二数字签名，将第二数字签名返回给应用方，可以便于应用方对API授权认证平台的身份进行验证，也提高了安全性。
图4是本申请另一实施例提供的API授权认证处理方法的流程示意图。如图4所示，该API授权认证处理方法包括步骤401-步骤408。
步骤401，接收应用方在调用API授权平台的目标API时发送的服务请求。
本申请中，应用方可以是应用客户端，用户在应用客户端使用某项服务时，应用客户端可以将相应的信息发送给应用服务端，应用服务端可以利用应用方的第二私钥对该信息进行加密得到第一数字签名，应用客户端可以根据第一数字签名调用API授权认证平台的目标API，API授权认证平台接收到服务请求，服务请求中可以包括第一数字签名，第一数字签名是利用应用方的第二私钥加密生成的。
本申请中，应用客户端在API授权认证平台注册成功时，API授权认证平台可以在工具界面生成应用方的公私钥，也即第二私钥和第二公钥。
步骤402，获取第二私钥对应的第二公钥。
本申请中，应用方在获取第二私钥和第二公钥后，可以登录API授权认证平台登记其公钥，由此，API授权认证平台可以获取应用方的第二公钥。
步骤403，根据第二公钥，对第一数字签名进行验证。
本申请中，API授权认证平台可以利用应用方的第二公钥，对第一数字签名进行解密，得到解密结果，并将解密结果与服务请求中的请求参数进行对比，根据对比结果，确定第一数字签名是否验证通过。如果解密结果与请求参数一致，可以认为第一数字签名验证通过；如果解密结果与请求参数不一致，可以认为第一数字签名未验证通过。
步骤404，第一数字签名是否验证通过。如果第一数字签名验证通过，可以执行步骤405，如果第一数字签名未验证通过，可以执行步骤408。
步骤405，将服务请求转发给对应的业务服务器，以获取业务服务器返回的服务请求对应的服务结果。
本申请中，如果第一数字签名验证通过，可以将服务请求转发给对应的业务服务器。
步骤406，利用API授权认证平台的第一私钥对服务结果进行加密，得到第二数字签名。
步骤407，将第二数字签名返回给应用方，以使应用方获取利用第一私钥对应的第一公钥对第二数字签名验证后的结果。
本申请中，步骤405-步骤407与上述实施例记载的内容类似，故在此不再赘述。
步骤408，返回应用方没有权限调用目标API的提示信息。
本申请中，如果第一数字签名未验证通过，说明应用方没有权限调用目标API，API授权认证平台可以向应用方返回应用方没有权限调用目标API的提示信息。
本申请实施例中，第一数字签名是利用应用方的第二私钥加密生成的，在对第一数字签名进行验证时，可以通过获取第二私钥对应的第二公钥，并根据第二公钥，对第一数字签名进行验证，由此，API授权认证平台可以通过应用方公钥对第一数字签名进行验证，以确定应用方是否有权限调用目标API，也即确定应用方的服务请求是否为合法请求，实现了对API授权认证管理。
图5是本申请另一实施例提供的API授权认证处理方法的流程示意图。如图5所示，该API授权认证处理方法包括步骤501-步骤508。
步骤501，接收应用方在调用API授权平台的目标API时发送的服务请求。
本申请中，应用方可以先在API授权认证平台进行注册，API授权认证平台可以接收应用方的注册请求，其中，注册请求中可以包含应用方的信息，API授权认证平台可以对注册请求进行验证，也即对应用方的信息进行审核验证，在验证通过的情况下，可以向应用方返回第一应用标识(APPID)和第一应用密钥(APPSECRET)。
其中，第一应用标识可以唯一标识应用方，第一应用标识可以是根据应用名称和时间通过哈希算法计算得到的。
本申请中，应用方可以为应用服务端，应用服务端可以利用应用方的第一应用密钥对服务请求参数进行加密，生成第一数字签名。
本申请中，应用方利用第一应用密钥对服务请求参数进行加密时，可以将请求参数按照key＝value的格式和ASCII码从小到大排序后拼接得到第一文本，并将第一文本转化成小写后得到第二文本，在第二文本拼接上第一应用密钥得到第三文本；对第三文本进行MD5信息摘要算法加密后即得到签名参数sign，也即得到第一数字签名。
在得到第一数字签名后，应用方可以将第一数字签名拼接到请求参数后面发送给API授权平台，也即服务请求中可以包括第一数字签名、请求参数等。
步骤502，根据服务请求中的第一应用标识，查询应用标识与应用密钥的对应关系，以确定第一应用标识对应的第一应用密钥。
本申请中，服务请求中还包括应用方的第一应用标识，API授权认证平台可以根据第一应用标识，查询各应用方的应用标识与应用密钥的对应关系，以确定该应用方的第一标识对应的第一应用密钥。
比如，服务请求中包括某应用方的第一应用标识为A，API授权认证平台可以根据第一应用标识A，查询应用标识与应用密钥之间的对应关系，以确定第一应用标识A对应的第一应用密钥。
步骤503，利用第一应用密钥对第一数字签名进行验证。
本申请中，API授权认证平台可以根据第一应用密钥，采用相同的签名算法对服务请求中的请求参数进行加密，生成得到第三数字签名，如果第一数字签名与第三数字签名一致，可以确定第一数字签名验证通过，如果第一数字签名与第三数字签名不一致，可以确定第一数字签名未验证通过。
步骤504，第一数字签名是否验证通过。如果第一数字签名验证通过，执行步骤505，如果第一数字签名未验证通过，可以执行步骤508。
步骤505，将服务请求转发给对应的业务服务器，以获取业务服务器返回的服务请求对应的服务结果。
步骤506，利用API授权认证平台的第一私钥对服务结果进行加密，得到第二数字签名。
步骤507，将第二数字签名返回给应用方，以使应用方获取利用第一私钥对应的第一公钥对第二数字签名验证后的结果。
步骤508，返回应用方没有权限调用目标API的提示信息。
本申请中，步骤505-步骤508与上述实施例记载的内容类似，故在此不再赘述。
本申请实施例中，第一数字签名可以是利用应用方的第一应用密钥加密生成的，在对第一数字签名进行验证时，可以根据服务请求中的第一应用标识，查询应用标识与应用密钥的对应关系，以确定第一应用标识对应的第一应用密钥，并利用第一应用密钥，对服务请求中的请求参数进行加密，生成第三数字签名，根据第三数字签名，对第一数字签名进行验证。由此，API授权认证平台可以通过应用方的应用密钥对第一数字签名进行验证，以确定应用方是否有权限调用目标API，也即确定应用方的服务请求是否为合法请求，实现了对API授权认证管理。
图6是本申请另一实施例提供的API授权认证处理方法的流程示意图。如图6所示，在接收应用方发送的服务请求之前，该API授权认证处理方法还包括步骤601-步骤607。
步骤601，获取应用方的API调用请求，其中，调用请求中包括目标API的标识、应用方的第二应用标识及第二应用密钥。
本申请中，第二应用标识与上述第一应用标识可以相同，第二应用密钥可以与上述第一应用密钥相同，第二应用标识和第二应用密钥的获取方式也与第一应用标识和第一应用密钥的获取方式类似，故在此不再赘述。
本申请中，应用方需要调用第三方业务服务时，可以先向API授权认证平台发送API调用请求，由此，API授权认证平台可以获取应用方的API调用请求。其中，调用请求中可以包括目标API的标识、应用方的第二应用标识、应用方的第二应用密钥等。
步骤602，根据第二应用标识和第二应用密钥，应用方是已在API授权认证平台注册。如果应用方已在API授权认证平台注册，可以执行步骤603，如果应用方未在API授权认证平台注册，则执行步骤604。
本申请中，可以根据第二应用标识和第二应用密钥，查询应用标识与应用密钥之间的对应关系，如果对应关系中存在第二应用标识和第二应用密钥、且第二应用标识与第二应用密钥对应，可以确定应用方已在API授权认证平台注册，如果对应关系中没有第二应用标识或第二应用密钥，或者第二应用标识与第二应用密钥不对应，可以确定应用方未在API授权认证平台注册。
步骤603，根据第二应用标识，查询应用方对应的API列表。
本申请中，应用方若API授权认证平台注册成功，可以规定应用方可以调用的API。本申请中，如果应用方已在API授权认证平台注册，那么API授权认证平台可以查询应用方对应的API列表。其中，API列表中包含应用方可以调用的API的标识。
步骤604，返回应用方没有权限调用API授权认证平台的API的提示信息。
本申请中，如果应用方未在API授权认证平台注册，说明应用方没有权限调用目标API，API授权认证平台可以向应用方返回应用方没有权限调用API授权认证平台的API的提示信息。
步骤605，在API列表中是否包含目标API的标识。如果API列表中包含目标API的标识，可以执行步骤606，如果API列表中未包含目标API的标识，执行步骤607。
步骤606，允许应用方调用目标API。
本申请中，如果API列表中包含目标API的标识，说明应用方可以调用目标API，因此可以允许应用方调用目标API。
步骤607，返回应用方没有权限调用目标API的提示信息。
本申请中，如果API列表中未包含目标API的标识，说明应用方虽然已经在API授权认证平台注册但没有权限调用目标API，API授权认证平台可以向应用方返回应用方没有权限调用目标API的提示信息。
本申请实施例中，在接收应用方发送的服务请求之前，还可以获取应用方的API调用请求，根据调用请求中的第二应用标识和所述第二应用密钥，确定应用方是否在API授权认证平台已注册，如果应用方已在API授权认证平台注册，根据第二应用标识，查询应用方对应的API列表，如果API列表中包含目标API的标识，则允许应用方调用目标API。由此，在接收应用方发送的服务请求之前，可以验证先应用方是否有权限调用目标API，若允许应用方调用目标API，还可以进一步对服务请求中的数字签名进行验证，进一步提高了安全性。
在本申请的一个实施例中，API授权认证平台还可以统计目标时间段内API授权认证平台的接口访问信息，并展示统计的接口访问信息。
其中，目标时间段比如可以是每天中一个或多个时间段，本申请对此不作限定。
其中，接收访问信息可以包括目标时间段内访问的API有哪些，访问同一API的次数等。
本申请中，在展示接口访问信息时，可以文本的形式展示，也可以图标的形式展示，或者是其他形式展示，本申请对此不作限定。
本申请实施例中，通过目标时间段内API授权认证平台的接口访问信息，并展示接口访问信息，可以便于观察接口的访问情况。
为了便于理解，下面以应用方为应用客户端，刷脸调用为例，结合图7进行说明，图7是本申请实施例提供的一交互流程示意图。
其中，上述的API授权认证平台可以包括认证平台客户端和认证平台服务端。
如图7所示，该交互流程包括步骤701-步骤711。
步骤701，用户发起刷脸调用。
步骤702，应用客户端将认证刷脸请求发送给应用服务端。
本申请中，应用服务端可以利用应用方私钥，采用RSA算法对刷脸信息进行加密，得到签名后的刷脸信息。
步骤703，应用服务端向应用客户端返回签名后的刷脸信息。
步骤704，应用客户端调用认证刷脸API。
步骤705，认证平台客户端将认证刷脸请求发送给认证平台服务端。
步骤706，认证平台服务端完成刷脸调用。
本申请中，认证平台服务端可以使用应用方公钥解密数字签名，解密成功表示认证刷脸请求是合法请求。认证平台服务端调用真正的刷脸业务操作，使用认证平台私钥加密刷脸结果。
步骤707，认证平台服务端向认证平台客户端返回加密刷脸结果。
步骤708，认证平台客户端向应用客户端返回加密刷脸结果。
步骤709，应用客户端向应用服务端同步加密的刷脸业务结果。
本申请中，应用服务端可以利用认证平台公钥对加密的刷脸结果验证签名，如果确认结果可以使用平台公钥解开，应用服务端返回最终刷脸结果给应用客户端。
步骤710，应用服务端向应用客户端返回最终刷脸结果。
步骤711，应用客户端显示最终刷脸结果。
为了便于理解，下面以应用方为应用服务端，利率查询请求为例，结合图8进行说明，图8是本申请实施例提供的另一交互流程示意图。
如图8所示，该交互流程包括步骤801-步骤808。
步骤801，用户进行业务操作请求查询利率***息。
步骤802，应用服务端获取利率***息查询请求。
本申请中，应用服务端用应用密钥对请求参数进行加密生成数字签名，将数字签名拼接在请求参数后面一同发送给认证平台。
步骤803，应用服务端将利率***息查询请求发送给认证平台
步骤804，认证平台验证签名。
本申请中，认证平台采用相同的签名算法，利用应用密钥对请求参数进行加密，得到一个数字签名(也即上述的第三数字签名)，将该数字签名与请求中的数字签名进行对比，以确定请求中的数字签名是否验证通过。
步骤805，如果验证通过，认证平台将利率***息查询请求转发给利率业务服务器。
本申请中，认证平台可以获取利率业务服务器返回的查询结果。
步骤806，利率业务服务器将查询结果返回给认证平台；
步骤807，认证平台对查询结果用平台私钥加密后返回给应用服务端。
步骤808，应用服务端用平台公钥验证签名并返回查询结果
步骤809，应用服务端将查询结果返回给应用客户端。
为了便于理解，下面以个人信息范围为例，结合图9进行说明，图9是本申请实施例提供的另一交互流程示意图。
如图9所示，该交互流程包括步骤901-步骤913。
步骤901，用户进行业务操作触发授权。
步骤902，应用服务端申请用户授权。
其中，申请的授权范围为用户个人信息。
步骤903，应用服务端附上应用方的应用标识、应用回调url将用户重定向到官方授权页面，请求地址。
步骤904，用户同意授权。
本申请中，用户同意授权，授权服务器收到用户请求，验证应用回调URL合法性，若应用标识和应用密钥正确，生成授权码。
步骤905，授权服务器把授权码重定向到回调URL。
本申请中，授权服务器把授权码重定向到回调URL，应用服务端取到授权码。
步骤906，应用服务端向授权服务器请求访问令牌。
本申请中，应用服务端根据授权码、应用标识和应用密钥，向授权服务器请求访问令牌，以获取访问令牌。
步骤907，认证平台向应用服务端返回访问令牌。
本申请中，认证平台验证授权码、应用标识和应用密钥，向应用服务端返回访问令牌。其中，访问令牌的有效时间为30分钟。
步骤908，应用服务端向认证平台发送访问用户个人信息请求。
本申请中，应用服务端根据访问令牌访问用户个人信息的业务接口。
步骤909，认证平台验证访问令牌，并将访问用户个人信息请求转发给资源服务器。
步骤910，资源服务器返回个人信息到认证平台。
步骤911，认证平台用平台私钥对个人信息进行加密，并返回给应用服务端。
步骤912，应用服务端对加密的个人信息用平台私钥解密，并返回给授权页面。
步骤913，应用客户端显示个人信息。
与上述图1、图3-图6实施例提供的API授权认证处理方法相对应，本申请还提供一种API授权认证处理装置，由于本申请实施例提供的API授权认证处理装置与上述图1、图3-图6实施例提供的API授权认证处理方法相对应，因此在API授权认证处理方法的实施方式也适用于本申请实施例提供的API授权认证处理装置，在本申请实施例中不再详细描述。图10是本申请一实施例提供的API授权认证处理装置的结构示意图。
参照图10，该API授权认证处理装置1000可以包括：
接收模块1010，被配置为接收应用方在调用所述API授权平台的目标API时发送的服务请求，其中，所述服务请求中包括与所述服务请求参数关联的第一数字签名；
验证模块1020，被配置为对所述第一数字签名进行验证；
转发模块1030，被配置为在所述第一数字签名通过验证的情况下，将所述服务请求转发给对应的业务服务器，以获取所述业务服务器返回的所述服务请求对应的服务结果；
发送模块1040，被配置为将第二数字签名返回给应用方，以使应用方获取利用第一私钥对应的第一公钥对第二数字签名验证后的结果。
在本申请实施例一种可能的实现方式中，所述发送模块1040，被配置为：
利用所述API授权认证平台的第一私钥对所述服务结果进行加密，得到第二数字签名；
将第二数字签名返回给所述应用方，以使应用方获取利用第一私钥对应的第一公钥对第二数字签名验证后的结果。
在本申请实施例一种可能的实现方式中，所述第一数字签名是利用所述应用方的第二私钥加密生成的，所述验证模块1020，被配置为：
获取所述第二私钥对应的第二公钥；
根据所述第二公钥，对所述第一数字签名进行验证。
在本申请实施例一种可能的实现方式中，所述第一数字签名是利用所述应用方的第一应用密钥加密生成的，所述验证模块1020，被配置为：
根据所述服务请求中的第一应用标识，查询应用标识与应用密钥的对应关系，以确定所述第一应用标识对应的所述第一应用密钥；
利用所述第一应用密钥，对所述服务请求中的请求参数进行加密，生成第三数字签名；
根据所述第三数字签名，对所述第一数字签名进行验证。
在本申请实施例一种可能的实现方式中，所述接收模块1010，还被配置为接收所述应用方发送的注册请求；
所述发送模块1040，还被配置为在所述注册请求验证通过的情况下，向所述应用方返回所述第一应用标识和所述第一应用密钥。
在本申请实施例一种可能的实现方式中，所述接收模块1010，还被配置为获取所述应用方的API调用请求，其中，所述调用请求中包括所述目标API的标识、所述应用方的第二应用标识及第二应用密钥；
该装置还可以包括：
确定模块，被配置为根据所述第二应用标识和所述第二应用密钥，确定所述应用方是已在所述API授权认证平台注册；
第一查询模块，被配置为在确定所述应用方已在所述API授权认证平台注册的情况下，根据所述第二应用标识，查询所述应用方对应的API列表；在所述API列表中包含所述目标API的标识的情况下，允许所述应用方调用所述目标API。
在本申请实施例一种可能的实现方式中，所述转发模块1030，被配置为：
确定所述服务请求对应的请求路径；
按照所述请求路径将所述服务请求转发到所述业务服务器。
在本申请实施例一种可能的实现方式中，所述转发模块1030，被配置为：
在所述服务请求中包括统一资源定位符的情况下，根据所述统一资源定位符，将所述服务请求转发到指定的所述业务服务器。
在本申请实施例一种可能的实现方式中，该装置还可以包括：
统计模块，被配置为统计目标时间段内所述API授权认证平台的接口访问信息；
展示模块，被配置为展示所述接口访问信息。
在本申请实施例一种可能的实现方式中，所述接收模块1010，还被配置为获取API注册请求，其中，所述创建请求中包括待注册API的标识；
该装置还可以包括：
第二查询模块，还配置根据所述待注册API的标识，查询API数据库；
添加模块，被配置为在所述API数据库中未包含所述待注册API的标识的情况下，将所述待注册API的标识添加到所述API数据库。
本申请实施例中，可以通过对第一数字签名进行验证，实现对应用方的身份进行验证，若验证通过，说明应用方有权限调用目标API，实现了对API授权认证管理，从而应用方可以通过API授权认证平台调用服务提供方的API，降低了应用方与服务提供方之间的对接成本。
需要说明的是，应理解以上装置的各个模块的划分仅仅是一种逻辑功能的划分，实际实现时可以全部或部分集成到一个物理实体上，也可以物理上分开。且这些模块可以全部以软件通过处理元件调用的形式实现；也可以全部以硬件的形式实现；还可以部分模块通过处理元件调用软件的形式实现，部分模块通过硬件的形式实现。
图11为本申请一实施例提供的电子设备的结构示意图。如图11所示，该电子设备可以包括：收发器1101、处理器1102、存储器1103。
处理器1102执行存储器存储的计算机执行指令，使得处理器1102执行上述实施例中的方案。处理器1102可以是通用处理器，包括中央处理器CPU、网络处理器(networkprocessor，NP)等；还可以是数字信号处理器DSP、专用集成电路ASIC、现场可编程门阵列FPGA或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件。
存储器1103通过***总线与处理器1102连接并完成相互间的通信，存储器1103用于存储计算机程序指令。
收发器1101可以用于获取待运行任务和待运行任务的配置信息。
***总线可以是外设部件互连标准(peripheral component interconnect，PCI)总线或扩展工业标准结构(extended industry standard architecture，EISA)总线等。***总线可以分为地址总线、数据总线、控制总线等。为便于表示，图中仅用一条粗线表示，但并不表示仅有一根总线或一种类型的总线。收发器用于实现数据库访问装置与其他计算机(例如客户端、读写库和只读库)之间的通信。存储器可能包含随机存取存储器(randomaccess memory，RAM)，也可能还包括非易失性存储器(non-volatile memory)。
本申请实施例提供的API授权认证平台可配置在上述电子设备中。
在示例性实施例中，还提供了一种包括指令的计算机可读存储介质，例如包括指令的存储器，上述指令可由电子设备的处理器执行以完成上述任一实施例提出的方法。可选地，计算机可读存储介质可以是ROM、随机存取存储器(RAM)、CD-ROM、磁带、软盘和光数据存储设备等。
在示例性实施例中，还提供一种计算机程序产品，包括计算机程序/指令，其特征在于，所述计算机程序/指令被处理器执行时实现上述任一实施例提出的方法。
本领域技术人员在考虑说明书及实践这里公开的发明后，将容易想到本申请的其它实施方案。本申请旨在涵盖本申请的任何变型、用途或者适应性变化，这些变型、用途或者适应性变化遵循本申请的一般性原理并包括本申请未公开的本技术领域中的公知常识或惯用技术手段。说明书和实施例仅被视为示例性的，本申请的真正范围和精神由下面的权利要求指出。
应当理解的是，本申请并不局限于上面已经描述并在附图中示出的精确结构，并且可以在不脱离其范围进行各种修改和改变。本申请的范围仅由所附的权利要求来限制。

Claims (23)

1.一种应用程序编程接口API授权认证处理方法，其特征在于，应用于API授权认证平台，所述方法包括：
接收应用方在调用所述API授权平台的目标API时发送的服务请求，其中，所述服务请求中包括与所述服务请求参数关联的第一数字签名；
对所述第一数字签名进行验证；
在所述第一数字签名通过验证的情况下，将所述服务请求转发给对应的业务服务器，以获取所述业务服务器返回的所述服务请求对应的服务结果；
将所述服务结果返回给所述应用方。
2.如权利要求1所述的方法，其特征在于，所述将所述服务结果返回给所述应用方，包括：
利用所述API授权认证平台的第一私钥对所述服务结果进行加密，得到第二数字签名；
将所述第二数字签名返回给所述应用方，以使所述应用方获取利用所述第一私钥对应的第一公钥对所述第二数字签名验证后的结果。
3.如权利要求1所述的方法，其特征在于，所述第一数字签名是利用所述应用方的第二私钥加密生成的，所述对所述第一数字签名进行验证，包括：
获取所述第二私钥对应的第二公钥；
根据所述第二公钥，对所述第一数字签名进行验证。
4.如权利要求1所述的方法，其特征在于，所述第一数字签名是利用所述应用方的第一应用密钥加密生成的，所述对所述第一数字签名进行验证，包括：
根据所述服务请求中的第一应用标识，查询应用标识与应用密钥的对应关系，以确定所述第一应用标识对应的所述第一应用密钥；
利用所述第一应用密钥，对所述服务请求中的请求参数进行加密，生成第三数字签名；
根据所述第三数字签名，对所述第一数字签名进行验证。
5.如权利要求4所述的方法，其特征在于，还包括：
接收所述应用方发送的注册请求；
在所述注册请求验证通过的情况下，向所述应用方返回所述第一应用标识和所述第一应用密钥。
6.如权利要求1所述的方法，其特征在于，在所述接收应用方在调用所述API授权平台的目标API时发送的服务请求之前，还包括：
获取所述应用方的API调用请求，其中，所述调用请求中包括所述目标API的标识、所述应用方的第二应用标识及第二应用密钥；
根据所述第二应用标识和所述第二应用密钥，确定所述应用方是已在所述API授权认证平台注册；
在确定所述应用方已在所述API授权认证平台注册的情况下，根据所述第二应用标识，查询所述应用方对应的API列表；
在所述API列表中包含所述目标API的标识的情况下，允许所述应用方调用所述目标API。
7.如权利要求1所述的方法，其特征在于，所述将所述服务请求转发给对应的业务服务器，包括：
确定所述服务请求对应的请求路径；
按照所述请求路径将所述服务请求转发到所述业务服务器。
8.如权利要求1所述的方法，其特征在于，所述将所述服务请求转发给对应的业务服务器，包括：
在所述服务请求中包括统一资源定位符的情况下，根据所述统一资源定位符，将所述服务请求转发到指定的所述业务服务器。
9.如权利要求1所述的方法，其特征在于，还包括：
统计目标时间段内所述API授权认证平台的接口访问信息；
展示所述接口访问信息。
10.如权利要求1所述的方法，其特征在于，还包括：
获取API注册请求，其中，所述注册请求中包括待注册API的标识；
根据所述待注册API的标识，查询API数据库；
在所述API数据库中未包含所述待注册API的标识的情况下，将所述待注册API的标识添加到所述API数据库。
11.一种API授权认证处理装置，其特征在于，所述装置包括：
接收模块，被配置为接收应用方在调用所述API授权平台的目标API时发送的服务请求，其中，所述服务请求中包括与所述服务请求参数关联的第一数字签名；
验证模块，被配置为对所述第一数字签名进行验证；
转发模块，被配置为在所述第一数字签名通过验证的情况下，将所述服务请求转发给对应的业务服务器，以获取所述业务服务器返回的所述服务请求对应的服务结果；
发送模块，被配置为将所述服务结果返回给所述应用方。
12.根据权利要求11所述的装置，其特征在于，所述发送模块，被配置为：
利用所述API授权认证平台的第一私钥对所述服务结果进行加密，得到第二数字签名；
将所述第二数字签名返回给所述应用方，以使所述应用方获取利用所述第一私钥对应的第一公钥对所述第二数字签名验证后的结果。
13.根据权利要求11所述的装置，其特征在于，所述第一数字签名是利用所述应用方的第二私钥加密生成的，所述验证模块，被配置为：
获取所述第二私钥对应的第二公钥；
根据所述第二公钥，对所述第一数字签名进行验证。
14.根据权利要求11所述的装置，其特征在于，所述第一数字签名是利用所述应用方的第一应用密钥加密生成的，所述验证模块，被配置为：
根据所述服务请求中的第一应用标识，查询应用标识与应用密钥的对应关系，以确定所述第一应用标识对应的所述第一应用密钥；
利用所述第一应用密钥，对所述服务请求中的请求参数进行加密，生成第三数字签名；
根据所述第三数字签名，对所述第一数字签名进行验证。
15.根据权利要求14所述的装置，其特征在于，
所述接收模块，还被配置为接收所述应用方发送的注册请求；
所述发送模块，还被配置为在所述注册请求验证通过的情况下，向所述应用方返回所述第一应用标识和所述第一应用密钥。
16.根据权利要求11所述的装置，其特征在于，
所述接收模块，还被配置为获取所述应用方的API调用请求，其中，所述调用请求中包括所述目标API的标识、所述应用方的第二应用标识及第二应用密钥；
所述装置还包括：
确定模块，被配置为根据所述第二应用标识和所述第二应用密钥，确定所述应用方是已在所述API授权认证平台注册；
第一查询模块，被配置为在确定所述应用方已在所述API授权认证平台注册的情况下，根据所述第二应用标识，查询所述应用方对应的API列表；在所述API列表中包含所述目标API的标识的情况下，允许所述应用方调用所述目标API。
17.根据权利要求11所述的装置，其特征在于，所述转发模块，被配置为：
确定所述服务请求对应的请求路径；
按照所述请求路径将所述服务请求转发到所述业务服务器。
18.根据权利要求11所述的装置，其特征在于，所述转发模块，被配置为：
在所述服务请求中包括统一资源定位符的情况下，根据所述统一资源定位符，将所述服务请求转发到指定的所述业务服务器。
19.根据权利要求11所述的装置，其特征在于，还包括：
统计模块，被配置为统计目标时间段内所述API授权认证平台的接口访问信息；
展示模块，被配置为展示所述接口访问信息。
20.根据权利要求11所述的装置，其特征在于，
所述接收模块，还被配置为获取API注册请求，其中，所述创建请求中包括待注册API的标识；
所述装置还包括：
第二查询模块，还配置根据所述待注册API的标识，查询API数据库；
添加模块，被配置为在所述API数据库中未包含所述待注册API的标识的情况下，将所述待注册API的标识添加到所述API数据库。
21.一种电子设备，其特征在于，包括：
处理器；
用于存储所述处理器可执行指令的存储器；
其中，所述处理器被配置为执行所述指令，以实现如权利要求1-10中任一项所述的方法。
22.一种计算机可读存储介质，当所述计算机可读存储介质中的指令由电子设备的处理器执行时，使得电子设备能够执行如权利要求1-10中任一项所述的方法。
23.一种计算机程序产品，包括计算机程序，其特征在于，所述计算机程序被处理器执行时实现如权利要求1-10任一项所述的方法。
CN202211158054.1A 2022-09-22 2022-09-22 Api授权认证处理方法、装置、电子设备和存储介质 Pending CN115622747A (zh)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN202211158054.1A CN115622747A (zh) 2022-09-22 2022-09-22 Api授权认证处理方法、装置、电子设备和存储介质

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN202211158054.1A CN115622747A (zh) 2022-09-22 2022-09-22 Api授权认证处理方法、装置、电子设备和存储介质

Publications (1)

Publication Number Publication Date
CN115622747A true CN115622747A (zh) 2023-01-17

Family

ID=84859056

Family Applications (1)

Application Number Title Priority Date Filing Date
CN202211158054.1A Pending CN115622747A (zh) 2022-09-22 2022-09-22 Api授权认证处理方法、装置、电子设备和存储介质

Country Status (1)

Country Link
CN (1) CN115622747A (zh)

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN116361753A (zh) * 2023-03-17 2023-06-30 深圳市东信时代信息技术有限公司 权限认证方法、装置、设备及介质
CN117331964A (zh) * 2023-12-01 2024-01-02 成都明途科技有限公司 数据查询方法、装置、设备及存储介质

Cited By (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN116361753A (zh) * 2023-03-17 2023-06-30 深圳市东信时代信息技术有限公司 权限认证方法、装置、设备及介质
CN116361753B (zh) * 2023-03-17 2024-03-22 深圳市东信时代信息技术有限公司 权限认证方法、装置、设备及介质
CN117331964A (zh) * 2023-12-01 2024-01-02 成都明途科技有限公司 数据查询方法、装置、设备及存储介质
CN117331964B (zh) * 2023-12-01 2024-02-27 成都明途科技有限公司 数据查询方法、装置、设备及存储介质

Similar Documents

Publication Publication Date Title
US10848310B2 (en) Method and device for identifying user identity
CN111556006B (zh) 第三方应用***登录方法、装置、终端及sso服务平台
CN110061846B (zh) 对区块链中用户节点进行身份认证和确认的方法、装置及计算机可读存储介质
US20190116038A1 (en) Attestation With Embedded Encryption Keys
WO2018164955A1 (en) Device enrollment protocol
CN115622747A (zh) Api授权认证处理方法、装置、电子设备和存储介质
US20100077467A1 (en) Authentication service for seamless application operation
WO2015143855A1 (zh) 一种对数据资源进行访问的方法、装置和***
CN110365684B (zh) 应用集群的访问控制方法、装置和电子设备
CN112823503B (zh) 一种数据访问方法、数据访问装置及移动终端
KR20170056536A (ko) 캐리어 시스템으로부터 획득된 고객 정보를 클라이언트 디바이스로 제공하는 것
CN111753014B (zh) 基于区块链的身份认证方法及装置
CN111444551B (zh) 账户的注册与登录方法、装置、电子设备及可读存储介质
CN113949566B (zh) 资源访问方法、装置、电子设备和介质
CN112528268B (zh) 跨渠道的小程序登录管理方法、装置及相关设备
JP2023518662A (ja) 暗号学的に安全な要求の検証
CN113765906A (zh) 终端应用程序的一键登录的方法、设备及***
US20240236049A1 (en) System and method for providing access to secured content
WO2018141219A1 (zh) 认证服务器、认证***及方法
CN109657170B (zh) 网页加载方法、装置、计算机设备及存储介质
CN114513373A (zh) 可信数据交换方法、装置、***、电子设备和存储介质
CN110399706B (zh) 授权认证方法、装置和计算机***
CN112702419A (zh) 基于区块链的数据处理方法、装置、设备和存储介质
CN111510421B (zh) 数据处理方法、装置、电子设备和计算机可读存储介质
CN112583602B (zh) 信息码数据传输方法、装置、***、计算机设备和介质

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