CN114513299B - 基于开放式授权的数据传输方法及电子设备 - Google Patents

基于开放式授权的数据传输方法及电子设备 Download PDF

Info

Publication number
CN114513299B
CN114513299B CN202011176630.6A CN202011176630A CN114513299B CN 114513299 B CN114513299 B CN 114513299B CN 202011176630 A CN202011176630 A CN 202011176630A CN 114513299 B CN114513299 B CN 114513299B
Authority
CN
China
Prior art keywords
server
key
user data
encrypted
client
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.)
Active
Application number
CN202011176630.6A
Other languages
English (en)
Other versions
CN114513299A (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 Technologies 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 CN202011176630.6A priority Critical patent/CN114513299B/zh
Publication of CN114513299A publication Critical patent/CN114513299A/zh
Application granted granted Critical
Publication of CN114513299B publication Critical patent/CN114513299B/zh
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Classifications

    • 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/08—Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
    • H04L9/0816—Key establishment, i.e. cryptographic processes or cryptographic protocols whereby a shared secret becomes available to two or more parties, for subsequent use
    • H04L9/0838—Key agreement, i.e. key establishment technique in which a shared key is derived by parties as a function of information contributed by, or associated with, each of these
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/60—Protecting data
    • G06F21/602—Providing cryptographic facilities or services
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/60—Protecting data
    • G06F21/64—Protecting data integrity, e.g. using checksums, certificates or signatures
    • 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/08—Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
    • H04L9/0861—Generation of secret information including derivation or calculation of cryptographic keys or passwords
    • H04L9/0866—Generation of secret information including derivation or calculation of cryptographic keys or passwords involving user or device identifiers, e.g. serial number, physical or biometrical information, DNA, hand-signature or measurable physical characteristics
    • 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/08—Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
    • H04L9/0861—Generation of secret information including derivation or calculation of cryptographic keys or passwords
    • H04L9/0869—Generation of secret information including derivation or calculation of cryptographic keys or passwords involving random numbers or seeds
    • 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
    • H04L9/3213—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 using tickets or tokens, e.g. Kerberos
    • 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
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F2221/00—Indexing scheme relating to security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F2221/21—Indexing scheme relating to G06F21/00 and subgroups addressing additional information or applications relating to security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F2221/2141—Access rights, e.g. capability lists, access control lists, access tables, access matrices

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Theoretical Computer Science (AREA)
  • Computer Hardware Design (AREA)
  • General Engineering & Computer Science (AREA)
  • Bioethics (AREA)
  • Health & Medical Sciences (AREA)
  • General Health & Medical Sciences (AREA)
  • Software Systems (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Computing Systems (AREA)
  • Information Transfer Between Computers (AREA)
  • Mobile Radio Communication Systems (AREA)

Abstract

本申请提供一种基于开放式授权的数据传输方法及电子设备，涉及终端技术领域，其中，该方法包括第一服务器接收第一客户端发送的第一消息，所述第一消息包括与第一客户端对应的第二服务器的服务器地址，所述第一服务器存储有与第二客户端对应的第一用户数据，所述第一服务器基于所述第二服务器的服务器地址，生成第一密钥，所述第一服务器基于所述第二服务器的地址，向所述第二服务器发送所述第一密钥，所述第一服务器基于所述第一密钥，向所述第二服务器传输所述第一用户数据。本申请提供的技术方案能够提高传输用户数据的安全性。

Description

基于开放式授权的数据传输方法及电子设备
技术领域
本申请涉及终端技术领域，尤其涉及一种基于开放式授权(open authorization，oauth)的数据传输方法及电子设备。
背景技术
客户端-服务器模式是一种常见的网络架构。客户端可以在服务器进行注册并登录该服务器，从而获取该服务器所提供的服务。其中，客户端可以通过第三方服务器的用户数据来快速实现上述注册和登录功能。
现有技术中，第一客户端可以指示第三方的第一服务器，向与第一客户端对应的第二服务器发送用户数据。但由于第一客户端通常是明文向第三客户端发送用户数据的而用户数据可能是用户的比较敏感的信息，比如邮箱、电话或住址等，因此上述获取用户数据的过程可能会导致用户数据泄露，安全性较低。
发明内容
有鉴于此，本申请提供一种基于oauth的数据传输方法及电子设备，以提高传输用户数据的安全性。
为了实现上述目的，第一方面，本申请实施例提供基于oauth的数据传输方法，包括：
第一服务器接收第一客户端发送的第一消息，所述第一消息包括与第一客户端对应的第二服务器的服务器地址，所述第一服务器存储有与第二客户端对应的第一用户数据；
所述第一服务器基于所述第二服务器的服务器地址，生成第一密钥；
所述第一服务器基于所述第二服务器的地址，向所述第二服务器发送所述第一密钥；
所述第一服务器基于所述第一密钥，向所述第二服务器传输所述第一用户数据。
其中，当第一客户端或第二服务器需要通过第一服务器中的账号和密码进行第三方登录，并获取第一服务器存储的用户数据时，第一客户端和第二服务器可以作为依赖方(relying party，RP)，第一服务器可以作为公开身份提供方(openID provider，OP)，第一客户端和第二服务器需要信赖第一服务器的鉴权结果。
需要说明的是，第一客户端可以与第二客户端不同，相应的，第一服务器可以与第二服务器不同。例如，第一客户端为游戏应用，第二服务器是与游戏应用对应的游戏服务器；第一客户端为通讯应用，第一服务器是与该通讯应用对应的通讯服务器。
还需要说明的是，第一用户数据可以是比较敏感的、对安全性要求较高的用户数据，比如邮箱、电话和住址等用户数据。
在本申请实施例中，第一服务器存储有与第二客户端对应的第一用户数据，第二服务器与第一客户端对应。第一服务器可以接收第一客户端发送的第一消息。由于第一消息中包括第二服务器的服务器地址，因此，第一客户端可以基于第二服务器的服务器地址，生成第一密钥，并将第一密钥提供给第二服务器。那么在第一服务器和第二服务器都存储有第一密钥的情况下，第一服务器便可以基于第一密钥和第一密钥的密钥标识，向第二服务器加密传输第一用户数据，从而提高了第一服务器向第二服务器提供用户数据的安全性。
可选地，所述第一服务器基于所述第二服务器的地址，向所述第二服务器发送所述第一密钥，包括：
所述第一服务器向所述第二服务器发送所述第一密钥和所述第一密钥的密钥标识，所述密钥标识用于所述第二服务器从至少一个密钥中获取所述第一密钥。
可选地，所述第一服务器向所述第二服务器发送所述第一密钥和所述第一密钥的密钥标识，包括：
所述第一服务器向所述第二服务器发送第一脚本对象简谱(javascript objectnotat ion，JSON)网络令牌(json web token，JWT)，所述第一JWT携带所述第一密钥和所述密钥标识。
其中，JWT是一种跨域认证解决方案，可以用于在网络应用环境间传递信息。JWT包括头部(header)、载荷部(payload)和签证部(signature)，载荷部可以用于存放需要传递的有效信息。
例如，第一服务器可以将“auth_key:xxx”和“auth_key_id:xxx”等两个字段封装在第一JWT的载荷中，封装之后的字段可以命名为auth_key_jwt。其中，“auth_key:xxx”为密钥字段，表示第一密钥，“auth_key_id:xxx”为密钥标识字段，表示第一密钥的密钥标识。
需要说明的是，在实际应用中，第一服务器和第二服务器也可以通过其他方式获取第一密钥，所以，在一些实施例中，第一服务器可以不生成第一密钥，也不向第二服务器发送第一密钥。
可选地，所述第一消息包括所述第一客户端的客户端标识，所述第一服务器基于所述第二服务器的服务器地址，生成第一密钥，包括：
所述第一服务器基于预设的授权接口协议生成授权码；
所述第一服务器获取与所述客户端标识对应的客户端密钥；
所述第一服务器基于所述授权码、所述第二服务器的服务器地址、预设长度的随机字符串和所述客户端密钥，生成所述第一密钥。
其中，第一客户端的客户端密钥和客户端标识，可以由第一客户端的供应商事先在第一服务器进行注册得到。
可选地，所述授权接口协议为请求评论(request for comment，RFC)授权接口协议。
可选地，所述第一消息包括第一授权模式指示符，所述第一授权模式指示符用于指示向所述第二服务器发送所述授权码，在所述第一服务器基于所述第二服务器的地址，向所述第二服务器发送所述第一密钥之前，所述方法还包括：
所述第一服务器向所述第二服务器发送所述授权码；
若所述第一服务器接收到所述第二服务器发送的第二消息，且所述第二消息包括所述授权码和所述密钥标识，则所述第一服务器基于所述授权接口协议生成网络令牌；
所述第一服务器向所述第二服务器发送所述网络令牌。
需要说明的是，若第一服务器向第二服务器发送授权码，则第一服务器可以通过一个消息来向第二服务器发送授权码、第一密钥和第一密钥的密钥标识。
可选地，所述第一消息包括一次性的非重复随机数值(number used once，Nounce)，所述第一服务器基于所述授权码、所述第二服务器的服务器地址、预设长度的随机字符串和所述客户端密钥，生成所述第一密钥，包括：
所述第一服务器基于所述授权码、所述Nounce、所述第二服务器的服务器地址、预设长度的随机字符串和所述客户端密钥，生成所述第一密钥。
可选地，所述授权接口协议为公开身份连接(openID connect，OIDC)授权接口协议权接口协议。
例如，第一服务器可以通过HMACSHA512(授权码+第二服务器的服务器地址+32字节随机数，第一客户端的客户端密钥)，得第一密钥。也即是，第一服务器可以通过第一客户端的客户端密钥，对授权码、第二服务器的服务器地址和32字节随机数进行HMACSHA512计算，从而针对每个第一客户端的每一次授权，产生独一无二的第一密钥，且不同次产生的第一密钥之间互不干扰，其中，安全散列算法(secure hash algorithm，SHA)512是SHA族的一种安全散列算法。或者，第一消息包括Nounce为n-0S6_WzA2Mj，第一服务器可以通过HMACSHA512(授权码+n-0S6_WzA2Mj+第二服务器的服务器地址+32字节随机数，第一客户端的客户端密钥)，得到第二密钥。
可选地，所述第一消息包括第二授权模式指示符，所述第二授权模式指示符用于指示向所述第二服务器发送网络令牌，所述方法还包括：
所述第一服务器基于所述授权接口协议，生成所述网络令牌；
所述第一服务器向所述第二服务器发送所述网络令牌。
需要说明的是，若第一服务器在向第二服务器发送网络令牌之前，不向第二服务器发送授权码，则第一服务器可以通过一个消息向第二服务器发送网络令牌、第一密钥和第一密钥的密钥标识。
可选地，第一服务器和第二服务器，可以将第一密钥与第一密钥的密钥标识，存储至密钥与密钥标识之间的对应关系中，将授权码和第一密钥的密钥标识，存储至授权码与密钥标识之间的对应关系中，将网络令牌和第一密钥的密钥标识，存储至网络令牌和密钥标识之间的对应关系中。也即是，第一服务器和第二服务器可以建立授权码、第一密钥与网络令牌之间的对应关系，从而能够根据一个快速准确地获取到另外两个。
可选地，所述第一服务器基于所述第一密钥，向所述第二服务器传输所述第一用户数据，包括：
所述第一服务器接收所述第二服务器发送的第三消息，所述第三消息包括所述网络令牌；
所述第一服务器基于所述第一密钥，对所述第一用户数据进行加密，得到加密的所述第一用户数据；
所述第一服务器向所述第二服务器发送所述密钥标识和加密的所述第一用户数据。
可选地，所述第一服务器基于所述第一密钥，对所述第一用户数据进行加密，得到加密的所述第一用户数据，包括：
所述第一服务器基于所述第一密钥和预设的第一向量字段，对所述第一用户数据进行加密，得到加密的所述第一用户数据；
所述第一服务器向所述第二服务器发送所述密钥标识和加密的所述第一用户数据，包括：
所述第一服务器向所述第二服务器发送所述密钥标识、所述第一向量字段和加密的所述第一用户数据。
可选地，第一服务器可以基于第一密钥和高级加密标准(advanced encry ptionstandard，AES)，对第一用户数据加密。
例如，第一服务器可以以第一密钥作为密钥，基于AES256_伽罗瓦/计数器模式(galois/counter mode，GCM)对第一用户数据进行base64编码，从而得到加密的第一用户数据，第一向量字段即为采用base64编码所采用的向量字段。
可选地，所述第一服务器向所述第二服务器发送所述密钥标识、第一向量和加密的所述第一用户数据，包括：
所述第一服务器向所述第二服务器发送第二JWT，所述第二JWT中携带所述密钥标识、所述第一向量字段和加密的所述第一用户数据。
其中，可以在JWT的载荷中增加加密用户数据字段，该加密用户数据字段可以用于存放加密的第一用户数据。相似的，可以在JWT中增加向量字段，该向量字段可以用于存放第一向量字段。
例如，可以在第二JWT的载荷中增加“ciphertext”、“auth_key_id”和“iv”等三个字段。其中，“ciphertext”为加密用户数据字段，其中携带加密的第一用户数据，“auth_key_id”为密钥标识字段，“iv”为向量字段，其中携带第一向量字段。
可选地，所述第一服务器存储有与所述第二客户端对应的第二用户数据，所述方法还包括：
所述第一服务器向所述第二服务器发送所述第二用户数据。
可选地，所述第一服务器基于所述第二服务器的服务器地址，生成第一密钥，包括：
若所述第一消息包括第一密钥协商标志符，则所述第一服务器基于所述第二服务器的服务器地址，生成所述第一密钥。若第一消息包括第二密钥协商标志符，则第一服务器可以不生成第一密钥。
可选地，第一服务器可以通过oauth私钥对第一用户数据或加密的第一用户数据进行签名，那么第一服务器向第二服务器发送的加密的第一用户数据可以携带第一服务器的签名。相应的，第二服务器可以通过预设oauth公钥，对携带第一服务器签名的加密的第一用户数据进行验签，以校验第一用户数据来源的合法性。若验签成功则对加密的第一用户数据进行解密，否则不对加密的第一用户数据进行解密。
例如，第一服务器可以通过oauth私钥，对第二JWT进行加密，相应的，第二服务器可以通过oauth公钥对第二JWT进行验签。若验签成功，则第二服务器再对第二JWT进行解密，若验签失败，则第二服务器不对第二JWT进行解密。
需要说明的是，第一服务器也可以通过oauth私钥对向第二服务器发送的其他数据进行签名(如第一JWT)，相应的，第二服务器可以通过oauth公钥对该数据进行验签，从而校验该数据来源的合法性。
第二方面，本申请实施例提供一种基于oauth的数据传输方法，包括：
第二服务器接收第一服务器发送的第一密钥；
所述第二服务器基于所述第一密钥，获取所述第一服务器传输的第一用户数据；
其中，所述第二服务器与第一客户端对应，所述第一服务器存储有与第二客户端对应的第一用户数据，所述第一密钥由所述第一服务器在接收到所述第一客户端发送的第一消息时生成并发送，所述第一消息包括所述第二服务器的服务器地址。
可选地，所述第二服务器接收第一服务器发送的第一密钥，包括：
所述第二服务器接收所述第一服务器发送的所述第一密钥和所述第一密钥的密钥标识，所述密钥标识用于所述第二服务器从至少一个密钥中获取所述第一密钥。
可选地，所述第二服务器接收所述第一服务器发送的所述第一密钥和所述第一密钥的密钥标识，包括：
所述第二服务器接收所述第一服务器发送的第一JWT，所述第一JWT携带所述第一密钥和所述密钥标识。
可选地，所述第一消息包括第一授权模式指示符，所述第一授权模式指示符用于指示向所述第二服务器发送授权码，所述方法还包括：
所述第二服务器接收所述第一服务器发送的所述授权码，所述授权码由所述第一服务器基于预设的授权接口协议生成；
所述第二服务器向所述第一服务器发送第二消息，所述第二消息包括所述授权码和所述密钥标识；
所述第二服务器接收所述第一服务器发送的网络令牌，所述网络令牌由所述第一服务器基于所述授权接口协议生成。
可选地，所述第一消息包括第二授权模式指示符，所述第二授权模式指示符用于指示向所述第二服务器发送网络令牌，所述方法还包括：
所述第二服务器接收所述第一服务器发送的所述网络令牌，所述网络令牌由所述第一服务器基于预设的授权接口协议生成。
可选地，所述方法还包括：
所述第二服务器向所述第一服务器发送第三消息，所述第三消息包括所述网络令牌；
所述第二服务器接收所述第一服务器发送的所述密钥标识和加密的所述第一用户数据；
所述第二服务器基于所述密钥标识，从至少一个密钥中获取所述第一密钥；
所述第二服务器基于所述第一密钥对加密的所述第一用户数据进行解密，得到所述第一用户数据。
可选地，所述第二服务器接收所述第一服务器发送的所述密钥标识和加密的所述第一用户数据，包括：
所述第二服务器接收所述第一服务器发送的所述密钥标识、第一向量字段和加密的所述第一用户数据；
所述第二服务器基于所述第一密钥对加密的所述第一用户数据进行解密，得到所述第一用户数据，包括：
所述第二服务器基于所述第一密钥和所述第一向量字段，对加密的所述第一用户数据进行解密的，得到所述第一用户数据。
可选地，所述第二服务器接收所述第一服务器发送的所述密钥标识、第一向量字段和加密的所述第一用户数据，包括：
所述第二服务器接收所述服务器发送的第二JWT，所述第二JWT中携带所述密钥标识、所述第一向量字段和加密的所述第一用户数据。
可选地，所述第一服务器存储有与所述第二客户端对应的第二用户数据，所述方法还包括：
所述第二服务器接收所述第一服务器发送的所述第二用户数据。
第三方面，本申请实施例提供了一种基于oauth的数据传输方法，包括：
第一服务器接收第二服务器发送的第三消息，所述第三消息包括网络令牌；
所述第一服务器基于第一密钥，对第一用户数据进行加密，得到加密的所述第一用户数据；
所述第一服务器向所述第二服务器发送所述第一密钥的密钥标识和加密的所述第一用户数据，所述密钥标识用于所述第二服务器从至少一个密钥中获取所述第一密钥。
在本申请实施例中，第一服务器若接收到第二服务器发送的第三消息，且第三消息包括网络令牌，则可以基于第一密钥，对第一用户数据进行加密，得到加密的第一用户数据，并向第二服务器发送第一密钥的密钥标识和加密的第一用户数据。由于密钥标识可以用于第二服务器从至少一个密钥中获取第一密钥。那么，第一服务器便可以通过第一密钥向第二服务器传输加密的第一用户数据进行加密，提高了传输用户数据的安全性。
第四方面，本申请实施例提供了一种基于oauth的数据传输方法，包括：
第二服务器向第一服务器发送第三消息，所述第三消息包括网络令牌；
所述第二服务器接收所述第一服务器发送的密钥标识和加密的第一用户数据；
所述第二服务器基于所述密钥标识，从至少一个密钥中获取第一密钥；
所述第二服务器基于所述第一密钥对加密的所述第一用户数据进行解密，得到所述第一用户数据。
第五方面，本申请实施例提供了一种基于oauth的数据传输装置，该装置用于实施上述第一方面中任一项、第二方面任一项、第三方面任一项或第四方面任一项所述的方法。
第六方面，本申请实施例提供一种电子设备，包括：存储器和处理器，存储器用于存储计算机程序；处理器用于在调用计算机程序时执行上述第一方面中任一项、第二方面任一项、第三方面任一项或第四方面任一项所述的方法。
第七方面，本申请实施例提供一种芯片系统，所述芯片系统包括处理器，所述处理器与存储器耦合，所述处理器执行存储器中存储的计算机程序，以实现上述第一方面中任一项、第二方面任一项、第三方面任一项或第四方面任一项所述的方法。
其中，所述芯片系统可以为单个芯片，或者多个芯片组成的芯片模组。
第八方面，本申请实施例提供一种计算机可读存储介质，其上存储有计算机程序，计算机程序被处理器执行时实现上述第一方面中任一项、第二方面任一项、第三方面任一项或第四方面任一项所述的方法。
第九方面，本申请实施例提供一种计算机程序产品，当计算机程序产品在电子设备上运行时，使得电子设备执行上述第一方面中任一项、第二方面任一项、第三方面任一项或第四方面任一项所述的方法。
可以理解的是，上述第三方面至第九方面的有益效果可以参见上述第一方面中的相关描述，在此不再赘述。
附图说明
图1为本申请实施例所提供的一种电子设备的结构示意图；
图2为本申请实施例所提供一种传输数据的系统的结构示意图；
图3为本申请实施例提供的一种基于oauth的数据传输方法的流程图；
图4为本申请实施例提供的一种登录界面的示意图；
图5为本申请实施例提供的一种登录界面的示意图；
图6为本申请实施例提供的一种第一服务器向第二服务器发送网络令牌、第一密钥和密钥标识的方法流程；
图7为本申请实施例所提供的另一种电子设备的结构示意图。
具体实施方式
本申请实施例提供的基于oauth的数据传输方法可以应用于电子设备的中。其中，电子设备可以包括手机、平板电脑、可穿戴设备、车载设备、增强现实(augmented reality，AR)/虚拟现实(virtual reality，VR)设备、笔记本电脑、超级移动个人计算机(ultra-mobile personal computer，UMPC)、上网本、个人数字助理(personal digitalassistant，PDA)、服务器等电子设备上，本申请实施例对客户端的具体类型不作任何限制。
图1是本申请实施例提供的一例电子设备100的结构示意图。电子设备100可以是第一客户端、第二客户端、第一服务器或第二服务器，电子设备100可以是包括处理器110、存储器120和通信模块130等。
其中，处理器110可以包括一个或多个处理单元，存储器120用于存储程序代码和数据。在本申请实施例中，处理器110可执行存储器120存储的计算机执行指令，用于对电子设备100的动作进行控制管理。
通信模块130可以用于电子设备100的各个内部模块之间的通信、或者电子设备100和其他外部电子设备之间的通信等。示例性的，如果电子设备100通过有线连接的方式和其他电子设备通信，通信模块130可以包括接口等，例如USB接口，USB接口可以是符合USB标准规范的接口，具体可以是Mini USB接口，Micro USB接口，USB Type C接口等。USB接口可以用于连接充电器为电子设备100充电，也可以用于电子设备100与外围设备之间传输数据。也可以用于连接耳机，通过耳机播放音频。该接口还可以用于连接其他电子设备，例如AR设备等。
或者，通信模块130可以包括音频器件、射频电路、蓝牙芯片、无线保真(wirelessfidelity，Wi-Fi)芯片、近距离无线通讯技术(near-field communication，NFC)模块等，可以通过多种不同的方式实现电子设备100与其他电子设备之间的交互。
可选地，电子设备100还可以包括显示屏140，显示屏140可以显示人机交互界面中的图像或视频等。
可选地，电子设备100还可以包括外设设备150，例如鼠标、键盘、扬声器、麦克风等。
应理解，除了图1中列举的各种部件或者模块之外，本申请实施例对电子设备100的结构不做具体限定。在本申请另一些实施例中，电子设备100还可以包括比图示更多或更少的部件，或者组合某些部件，或者拆分某些部件，或者不同的部件布置。图示的部件可以以硬件，软件或软件和硬件的组合实现。
为了便于理解本申请施例中的技术方案，下面首先对本申请实施例的应用场景予以介绍。
请参照图2，为本申请实施例所提供的一种传输数据的系统的结构示意图。该系统包括用户210、第一客户端220、第一服务器230和第二服务器240，第一客户端220、第一服务器230和第二服务器240可以包括如图1所示的电子设备100。
用户210，或称为resource owner，可以操作第一客户端220，比如在第一客户端220打开登录第二服务器240的登录界面、在该登录页面输入账号和密码等。
第一客户端220与第二服务器240对应，第一客户端220可以与第二服务器240进行交互。
需要说明的是，第一客户端220可以包括安装有与第二服务器240对应应用的电子设备，或者，第一客户端220可以包括通过浏览器访问第二服务器240的电子设备。
第一服务器230可以与第二客户端(图2中未示出)对应，并存储有与第二客户端对应的用户数据。在一些实施例中，用户210可以通过第二客户端在第一服务器230进行注册，并提交该用户数据。当然，在实际应用中，第一服务器230还可以通过其他方式来事先获取到该用户数据，本申请实施例对第一服务器230获取到该用户数据的方式不做具体限定。
需要说明的是，本申请实施例对此第一客户端或第二客户端的类型并不做具体限定，且第一客户端220可以与第二客户端不同，相应的，第一服务器230可以与第二服务器240不同。例如，第一客户端220为游戏客户端，第二服务器240是与游戏客户端对应的游戏服务器；第一客户端为通讯客户端，第一服务器130是与该通讯客户端对应的通讯服务器。
还需要说明的是，第一客户端220和第二客户端可以指代同一电子设备。
还需要说明的是，第一服务器130或第二服务器140可以为一个服务器、一个服务器集群或者一个服务器中的服务器模块。
在上述系统中，第一客户端220和第二服务器240可以为RP，第一服务器130可以作为OP。且在一些实施例中，第一客户端220与第二服务器240的角色可以结合。第一服务器230可以用于对第一客户端220进行鉴权，包括向第一客户端220或第二服务器240提供授权、凭据颁发、验证以及用户数据等服务。相应的，第一客户端220和第二服务器240需要信任OP的鉴权结果，
其中，openID是一种去中心化的网上身份认证系统。基于该系统，用户210只要预先在某个客户端(如第二客户端)对应的服务器(如第一服务器230)进行注册并提用户数据后，在使用其他客户端(如第一客户端220)时，可以不重复进行注册或提交用户数据，而是基于之前在该服务器注册的账号和密码，在该其他客户端对应的服务器(如第二服务器240)进行登录并获取该客户端对应的服务器中存储的用户数据。之后，第一客户端可以与第二服务器进行内部交互。
例如，用户事先通过手机中的某通讯客户端，在与该通讯客户端对应的通讯服务器进行了注册，账号为Agt47，密码为123456，用户还通过该通讯客户端向该通讯服务器提交了“姓名：张三”、“邮箱：zhagnsan@example.com”、“证件照：pic1.jpg”以及“住址：A省B市C小区”。之后，用户在手机中下载了游戏客户端。为了减少繁琐的注册以及提交用户数据的过程，用户可以通过之前在通讯服务器注册的账号和密码登录游戏服务器，该游戏服务器可以获取通讯服务器已经存储的该用户的用户数据。
在一些实施例中，第一客户端220可以向第一服务器230发送第一消息，该第一消息包括第二服务器240的服务器地址。当第一服务器230接收到该第一消息时，可以基于第二服务器240的服务器地址，向第二服务器240发送网络令牌。第二服务器240可以通过该网络令牌从第一服务器230获取明文发送的用户数据。
但由于用户数据可能是用户的比较敏感的信息，比如邮箱、电话或住址等，而在上述获取用户数据的过程中，用户数据通常是明文发送的，从而可能会导致用户数据泄露，安全性较低。
为解决上述技术问题，本申请实施例提供了另一种基于oauth的数据传输方法。第一服务器存储有与第二客户端对应的第一用户数据，第二服务器与第一客户端对应。第一服务器可以接收第一客户端发送的第一消息，由于第一消息中包括第二服务器的服务器地址，因此，第一客户端可以基于第二服务器的服务器地址，生成第一密钥，并将第一密钥提供给第二服务器。那么在第一服务器和第二服务器都存储有第一密钥的情况下，第一服务器便可以基于第一密钥，向第二服务器加密传输第一用户数据，从而提高了第一服务器向第二服务器提供用户数据的安全性。
下面以具体地实施例对本申请的技术方案进行详细说明。下面这几个具体的实施例可以相互结合，对于相同或相似的概念或过程可能在某些实施例不再赘述。
请参照图3，为本申请实施例所提供的一种基于oauth的数据传输方法的流程图。需要说明的是，该方法并不以图3以及以下所述的具体顺序为限制，应当理解，在其它实施例中，该方法其中部分步骤的顺序可以根据实际需要相互交换，或者其中的部分步骤也可以省略或删除。该方法包括如下步骤：
S301，第二客户端在第一服务器进行注册并提交用户数据。
第二客户端与第一服务器对应。第二客户端可以向第一服务器发送注册请求，从而在第一服务器进行注册，得到账号和密码，且第二客户端还可以向第一服务器提交用户数据，诸如用户的姓名、电话、邮箱和住址等。第一服务器可以存储第二客户端提交的账号、密码以及用户数据。
需要说明的是，第一服务器也可以通过其他方式来获取到与第二客户端对应的用户数据，本申请实施例对第一服务器获取到该用户数据的方式不做具体限定。
S302，第一客户端向第一服务器发送第一消息。
第一客户端在访问与第一客户端对应的第二服务器之前或者在访问第二服务器期间，可能需要获取该用户的用户数据，但若使用第一客户端和第二客户端的是同一用户，则会导致用户重复进行注册以及提交用户数据的操作，因此，为了便于后续第一客户端通过作为第三方的第一服务器所存储的账号和密码进行登录，并获取第一服务器所存储的用户数据，提高与用户的交互效率，第一客户端可以向第一服务器发送第一消息。
其中，第一消息可以包括第二服务器的服务器地址。
在一些实施例中，第一消息可以包括第一授权模式指示符或第二授权模式指示符。其中，第一授权模式指示符可以用于指示第一服务器基于第一消息，向第二服务器发送授权码(code)，该授权码可以用于第二服务器从第一服务器获取网络令牌(token)；第二授权模式指示符可以用于指示第一服务器直接向第二服务器发送网络令牌，而不需要在发送网络令牌之前再发送授权码。
在一些实施例中，第一消息可以包括第一客户端的客户端标识。其中，第一客户端的客户端标识可以由第一客户端的厂商事先在第一服务器进行注册得到。
在一些实施例中，第一消息可以包括第一密钥协商标志符或第二密钥协商标志符。其中，第一密钥协商标志符可以用于指示第一服务器生成第一密钥，第二密钥协商标志信息用于指示第一服务器不生成该第一密钥。
需要说明的是，上述第一授权模式指示符、第二授权模式指示符、第一密钥协商标志符和第二密钥协商标志符可以通过事先确的字符或字符串表示。
在一些实施例中，第一消息可以包括第一客户端的状态参数，该状态参数能够表示第一客户端当前的状态，从而能够用于后续第一客户端、第二服务器以及第一服务器之间传输的信息进行验证。其中，状态参数可以是一个字符或字符串，例如，该状态参数可以是由第一客户端生成的一个随机数。
在一些实施例中，第一消息可以包括Nounce，Nounce可以用于后续第一服务器生成第一密钥。
在一些实施例中，第一消息包括请求授权的用户数据范围参数，该用户数据范围参数可以用于指示请求授权的用户数据的范围。
例如，第一客户端可以基于RFC6749授权接口协议，向第一服务器发送get形式的第一消息：
“GET/authorize？
response_type＝code
&client_id＝s6BhdRkqt3
&state＝xyz
&redirect_uri＝https％3A％2F％2Fclient％2Eexample％2Ecom％2Fcb
&consult_auth_key＝<true>
&HTTP/1.1Host:server.example.com”
其中，“response_type＝code”表示当前第一客户端所请求的响应模式为code模式，以指示第一服务器反馈授权码，“client_id＝s6BhdRkqt3”表示第一客户端的客户端标识为s6BhdRkqt3，“state＝xyz”表示状态参数为xyz，“redirect_uri＝https％3A％2F％2Fclient％2Eexample％2Ecom％2Fcb”表示第二服务器的服务器地址，“consult_auth_key＝<true>”表示请求第一服务器协商第一密钥。
需要说明的是，RFC6749授权接口协议是oauth协议和协议框架的编号为6749的请求评论文档。oauth是第三方应用授权的开放标准，使得第三方应用在无需使用用户账号信息(如账号和密码)的情况下，就可以获取到用户数据。RFC6749授权接口协议说明了各设备在该认证授权过程中的角色定义、授权模式以及其他相关信息。
或者，第一客户端可以基于OIDC授权接口协议，向第一服务器发送get形式的第一消息：
“GET/authorize？
response_type＝id_token token
&client_id＝s6BhdRkqt3
&redirect_uri＝https％3A％2F％2Fclient.example.org％2Fcb
&scope＝openid％20profile
&state＝af0ifjsldkj
&nonce＝n-0S6_WzA2Mj
&consult_auth_key＝<true>
HTTP/1.1Host:server.example.com”
其中，“response_type＝id_token token”表示当前第一客户端所请求的响应模式为网络令牌模式，以指示第一服务器反馈网络令牌，“client_id＝s6BhdRkqt3”表示第二客户端的客户端标识为s6BhdRkqt3，“redirect_uri＝https％3A％2F％2Fclient.example.org％2Fcb”表示第二服务器的服务器地址为https％3A％2F％2Fclient.example.org％2Fcb，“scope＝openid％20profile”表示请求授权的用户数据范围，“state＝af0ifjsldkj”表示状态参数为af0ifjsld kj，“nonce＝n-0S6_WzA2Mj”表示Nounce为n-0S6_WzA2Mj，“consult_auth_key＝<true>”表示请求第一服务器协商第一密钥。当然，如果“consult_auth_key＝<false”则表示请求第一服务器不协商第一密钥。
需要说明的是，OIDC授权接口协议是在oauth2.0的基础上构建了一个身份层，OIDC授权接口协议是一个基于oauth2.0的身份认证标准协议，可以兼容oauth。
例如，某游戏客户端的登录界面如图4所指示。该登录界面包括提交该游戏客户端己方账号和密码的输入窗口、登录按钮以及注册按钮。该游戏客户端可以在基于账号和密码的输入窗口，接收用户提交账号和密码来登录游戏服务器，当然也在基于注册按钮接收到用户的点击操作时，向用户展示账号注册界面，以便于接收用户向游戏服务器注册的账号和密码。另外，在该登录界面中，还提供有“用XX账号登录”按钮，XX为某通讯客户端的客户端标识。当该游戏客户端基于该“用XX账号登录”按钮接收到点击操作时，可以向该通讯客户端对应的通讯服务器发送第一消息，以请求授权以用户之前在该通讯服务器注册的账号和密码，登录该游戏服务器，并获取用户在该通讯服务器中的用户数据。
S303，第一服务器接收用户的确认授权操作。
第一服务器在接收到客户端发送的第一消息时，可以基于客户端接收用户的确认授权操作，以便于授权第二服务器获取第一服务器存储的与第二客户端对应的用户数据。
其中，第一服务器可以基于RFC6749授权接口协议，通过第一客户端或第二客户端接收用户提交的账号和密码，在确定该账号和密码匹配的时，接收用户针对至少部分用户数据的确认授权操作。
例如，接上述图4。通讯服务器在接收到游戏客户端发送的第一消息时，在游戏客户端向用户展示登录界面如图5所示。该登录界面包括账号和密码的输入窗口以及登录按钮，还包括需要授权的至少部分用户数据(如昵称和头像、电话、邮箱以及好友信息)。游戏客户端可以基于该登录界面接收用户输入的账号和密码，并基于该账号和密码在该通讯服务器进行登录。游戏客户端还可以在基于任一用户数据(如昵称和邮箱)对应的复选框接收到用户的确认授权操作时，确定可以授权第二服务器获取该任一用户数据。当然，图5所示的登录界面中也可以不显示需要授权的至少部分用户收据，而是在确定用户所提交的账号和密码匹配时，再通过向用户展示用户数据授权界面，该用户数据授权界面中包括需要授权的至少部分用户数据，然后接收用户针对任一部分用户数据的确认授权操作。也即是，第一服务器可以同时接收用户所输入的账号和密码，并确定用户所允许授权的用户数据，也可以先确定用户登录成功，再确定用户所允许授权的用户数据。
S304，第一服务器生成第一密钥、第一密钥的密钥标识和网络令牌。
由于用户数据可能是与用户相关的敏感信息，如果用户数据泄露可能会给用户造成困扰和损失，因此为了便于后续向第二服务器提供加密的用户数据，第一服务器可以生成第一密钥。且为了便于其他设备在不需要提供账号和密码的情况下，访问第一服务器从而获取到用户数据，第一服务器可以生成网络令牌。
其中，第一服务器可以基于第二服务器的服务器地址，生成第一密钥。
在一些实施例中，第一服务器可以通过预设的密钥相关的哈希运算消息认证码(hash-based message authentication code，HMAC)算法，基于第二服务器的服务器地址以及第二密钥，生成第一密钥。其中，HMAC可以通过哈希算法，以密钥和一个消息为输入，生成一个消息摘要作为输出。
在一些实施例中，第一服务器可以通过HMAC算法，基于授权码和第二服务器的服务器地址以及第二密钥，生成第一密钥。
其中，第一服务器可以基于预设的授权接口协议(如RFC6749授权接口协议)，生成授权码。
在一些实施例中，第一服务器可以基于授权码、第二服务器的服务器地址、预设长度的随机字符串以及第二密钥，生成第一密钥。
其中，预设长度的随机字符串，可以使得针对每个授权都可以产生独一无二的第一密钥，进一步提高了后续数据传输的安全性。预设长度的随机字符串可以由第一服务器确定，例如，一种预设长度的随机字符串可以为32字节的随机数。
需要说明的是，第二密钥可以由第一服务器通过任意方式获取得到。在一些实施例中，由前述可知，第一消息包括第一客户端的客户端标识，因此，第一服务器可以基于该客户端标识获取第一客户端的客户端密钥。其中，该客户端密钥可以由对应客户端的厂商事先在第一服务器进行注册得到。
在一些实施例中，第一服务器可以基于授权码、第二服务器的服务器地址、第一消息包括的Nounce、预设长度的随机字符串以及第二密钥，生成第一密钥。
例如，第一服务器可以通过HMACSHA512(授权码+第二服务器的服务器地址+32字节随机数，第一客户端的客户端密钥)，得第一密钥。也即是，第一服务器可以通过第一客户端的客户端密钥，对授权码、第二服务器的服务器地址和32字节随机数进行HMACSHA512计算，从而针对每个第一客户端的每一次授权，产生独一无二的第一密钥，且不同次产生的第一密钥之间互不干扰，其中，SHA512是SHA族的一种安全散列算法。或者，第一消息包括Nounce为n-0S6_WzA2Mj，第一服务器可以通过HMACSHA512(授权码+n-0S6_WzA2Mj+第二服务器的服务器地址+32字节随机数，第一客户端的客户端密钥)，得到第二密钥。
在一些实施例中，为了便于对所生成的第一密钥进行管理，第一服务器可以生成第一密钥的密钥标识，并将第一密钥与该密钥标识存储至密钥与密钥标识的对应关系中。
在一些实施例中，第一服务器可以将第一密钥的密钥标识，与本次授权过程中生成的授权码，存储至密钥标识与授权码之间的对应关系中。
在一些实施例中，第一服务器可以将第一密钥、第一密钥的密钥标识和授权码，存储在数据库中，以便于对第一密钥、第一密钥的密钥标识和授权码进行持久化保存。
另外，在一些实施例中，S304也可以由第一服务器在S307之前的其他时机执行。
需要说明的是，S304中生成第一密钥的步骤可以省略，比如若第一服务器接收到第一消息且该第一消息包括第二密钥协商标志符，则第一服务器可以不生成第一密钥。在一些实施例中，第一服务器可以通过其他方式来获取到第一密钥，比如可以由第一客户端或第二服务器生成，第一服务器可以从第一客户端或第二服务器获取该第一密钥。
在一些实施例中，网络令牌可以包括访问令牌(access token)。在一些实施例中，网络令牌还可以包括ID令牌(identity token)。其中，访问令牌可以用于授权其他设备访问第一服务器，ID令牌可以用于对用户的身份进行验证。
其中，第一服务器可以基于预设的授权接口协议(如RFC6749授权接口协议或OIDC授权接口协议)生成网络令牌。在一些实施例中，第一服务器可以基于RFC6749授权接口协议生成访问令牌，或者第一服务器可以基于OIDC授权接口协议生成访问令牌和ID令牌。
在一些实施例中，第一服务器可以将网络令牌与第一密钥的密钥标识，存储至网络令牌与密钥标识之间的对应关系中。
其中，当第一服务器存储了网络令牌与密钥标识之间的对应关系、密钥标识与授权码之间的对应关系以及密钥与密钥标识的对应关系，也就建立了第一密钥、授权码和网络令牌之间的对应关系，可以基于其中的任一个快速准确地获取到另外两个。
S305，第一服务器向第二服务器发送网络令牌、第一密钥和第一密钥的密钥标识。
由前述可知，第一服务器接收到的第一消息包括第二服务器的服务器地址，因此，第一服务器可以基于第二服务器的服务器地址，向第二服务器发送网络令牌、第一密钥以及第一密钥的密钥标识。
在一些实施例中，若第一消息包括第二授权模式指示符，则第一服务器可以向第二服务器发送网络令牌。
其中，第一服务器可以通过同一个消息，向第二服务器发送网络令牌、第一密钥和第一密钥的密钥标识。
在一些实施例中，第一服务器可以将第一密钥和第一密钥的密钥标识携带在第一JWT的载荷部中。
其中，JWT是一种跨域认证解决方案，可以用于在网络应用环境间传递信息。JWT包括头部(header)、载荷部和签证部(signature)，载荷部可以用于存放需要传递的有效信息。因此，可以在第一JWT的载荷部中增加用于存放第一密钥的密钥字段和存放第一密钥的密钥标识的密钥标识字段。
例如，第一服务器可以将“auth_key:xxx”和“auth_key_id:xxx”等两个字段封装在第一JWT的载荷中，封装之后的字段可以命名为auth_key_jwt。其中，“auth_key:xxx”为密钥字段，表示第一密钥，“auth_key_id:xxx”为密钥标识字段，表示第一密钥的密钥标识。
在一些实施例中，第一服务器可以通过预设的oauth私钥对第一JWT进行加密，即对第一JWT进行签名。
在一些实施例中，第一服务器向第二服务器发送网络令牌有效时长。该网络有效时长可以用于指示网络令牌有效的时间范围，如果某时刻超出该网络令牌有效时长，则网络令牌会失效。
在一些实施例中，第一服务器可以向第二服务器发送状态参数，该状态参数与第一消息中的状态参数相同。
例如，第一服务器可以通过下述消息向第二服务器发送网络令牌、第一密钥和第一密钥的密钥标识：
“HTTP/1.1 302Found
Location:https://client.example.org/cb#
access_token＝SlAV32hkKG
&token_type＝bearer
&id_token＝eyJ0...NiJ9.eyJ1c...I6IjIifX0.DeWt4Qu...ZXso
&expires_in＝3600
&state＝af0ifjsldkj
&auth_key_jwt＝xxxx”
其中，“access_token＝SlAV32hkKG”表示访问令牌为SlAV32hkKG，“token_type＝bearer”表示网络令牌的类型为bearer，“id_token＝eyJ0...NiJ9.eyJ1c...I6IjIifX0.DeWt4Q u...ZXso”表示ID令牌为eyJ0...NiJ9.eyJ1c...I6IjIifX0.DeWt4Q u...ZXso，expires_in＝3600表示网络令牌的有效时长为3600秒，“state＝af0ifjsldkj”表示状态参数，该状态参数与第一消息包括的状态参数相同，“auth_key_jwt＝xxxx”表示JWT，该JWT的载荷部分中携带有第一密钥以及第一密钥的密钥标识。
在一些实施例中，若第一消息包括第一授权模式指示符，则第一服务器可以向第二服务器发送授权码、第一密钥和第一密钥的密钥标识。当第二服务器接收到授权码时，向第一服务器发送第二消息，第二消息包括该授权码和第一密钥的密钥标识，以通过授权码从第一服务器网络令牌接口，置换得到网络令牌。第一服务器在接收到第二消息时，若确定该授权码与第一密钥的密钥标识对应，则向第二服务器发送网络令牌。具体也可以参照下述图6所提供的第一服务器向第二服务器发送网络令牌、第一密钥和第一密钥的密钥标识的方法流程图中的相关描述。
其中，在一些实施例中，第一服务器可以在接收到第二消息时，按照与前述相似的方法生成网络令牌。当然，若第一服务器在此之前已经生成了网络令牌，则可以在接收到第二消息时，从存储的至少一个网络令牌中，获取与第二消息包括的密钥标识对应的网络令牌。
例如，第一服务器可以通过下述消息向第二服务器发送授权码、第一密钥和第一密钥的密钥标识：
“HTTP/1.1 302Found
Location:https://client.example.com/cb？
code＝SplxlOBeZQQYbYS6WxSbIA
&state＝xyz
&auth_key_jwt＝xxxx”
其中，“code＝SplxlOBeZQQYbYS6WxSbIA”表示授权码为SplxlOBeZQQYbYS6WxSbIA，“state＝xyz”表示状态参数为xyz，该状态参数与第一消息包括的状态参数相同，
“auth_key_jwt＝xxxx”表示JWT。
相应的，第一服务器可以通过下述消息向第二服务器发送网络令牌：
“POST/token HTTP/1.1
Host:server.example.com
Authorization:Basic czZCaGRSa3F0MzpnWDFmQmF0M2JW
Content-Type:application/x-www-form-urlencoded
grant_type＝authorization_code
&code＝SplxlOBeZQQYbYS6WxSbIA
&redirect_uri＝https％3A％2F％2Fclient％2Eexample％2Ecom％2Fcb
&auth_key_id＝<String>”
其中，“code＝SplxlOBeZQQYbYS6WxSbIA”表示授权码为SplxlOBeZQQYbYS6WxSbIA，“redirect_uri＝https％3A％2F％2Fclient％2Eexample％2Ecom％2Fcb”用于表示第二服务器的服务器地址，“auth_key_id＝<String>”表示第一密钥的密钥标识。
在一些实施例中，第二服务器可以从接收到的第一JWT载荷中的密钥字段获取第一密钥，从第一JWT载荷中的密钥标识字段获取第一密钥的密钥标识。
其中，第二服务器可以将获取到的第一密钥和第一密钥的密钥标识，存储至密钥和密钥之间的对应关系中，将获取到的授权码与第一密钥的密钥标识，存储至授权码与密钥标识之间的对应关系中，将获取到的网络令牌与第一密钥的密钥标识，存储至网络网络令牌和密钥标识之间的对应关系中，从而建立授权码、第一密钥以及网络令牌之间的对应关系。
在一些实施例中，第二服务器可以基于预设的oauth公钥对第一JWT进行解密，即对第一JWT进行验签。如果验签成功则可以确定第一JWT是来源于第一服务器，则获取第一JWT中携带的第一密钥和密钥标识，并继续进行后续步骤。如果验签失败，则不能确定第一JWT的具体来源，可以反馈失败并终止实施后续步骤。
其中，第二服务器中预设的oauth公钥，可以与第一服务器中的oauth私钥对应。
通过上述步骤，第一服务器与第二服务器已经获取得到了第一密钥，因此在后续步骤中，可以通过第一密钥确保所传输的数据的安全性。且需要说明的是，在实际应用中，第一服务器与第二服务器也可以通过其他方式来获取得到第一密钥，因此在上述S304和S305中，第一服务器也可以不生成并向第二服务器发送第一密钥和第一密钥的密钥标识。
S306，第二服务器向第一服务器发送第三消息，第三消息包括网络令牌。
第二服务器若获取到网络令牌，则可以通过网络令牌调用预设的授权接口协议中定义的用户数据获取接口来获取用户数据。
在一些实施例中，第三消息包括的网络令牌可以为访问令牌。
例如，一种第三消息可以如下所示：
“GET/userinfo HTTP/1.1
Host:server.example.com
Authorization:Bearer SlAV32hkKG”
其中，“SlAV32hkKG”即为第二服务器从第一服务器获取到的访问令牌。
S307，第一服务器向第二服务器发送第一密钥的密钥标识和加密的第一用户数据。
若第一服务器未生成第一密钥，也未从其他方式获取到第一密钥，则第一服务器向第二服务器发送的是明文的用户数据。
例如，第一服务器发送的一种用户数据可以如下所示：
“{
"sub":"248289761001",
"name":"Jane Doe",
"given_name":"Jane",
"family_name":"Doe",
"preferred_username":"j.doe",
"email":"janedoe@example.com",
"mobile":"18680112915",
"picture":"http://example.com/janedoe/me.jpg"
}”
其中，在OIDC协议中，"sub":"248289761001"表示客户端当前用户的主体标识符为248289761001，"name":"Jane Doe"表示该用户的全名为Jane Doe，"given_name":"Jane"表示该用户的名字为Jane，"family_name":"Doe"表示该用户的姓为Doe，"preferred_user name":"j.doe"表示该用户的简写名称为j.doe，"email":janedoe@example.com表示该用户的邮箱是janedoe@example.com，"mobile":"18680112915"表示该用户的电话为18680112915，"picture":http://example.com/janedoe/me.jpg表示该用户的概要文件的地址。
当然，在实际应用中，用户数据也可以包括更多或更少的与用户相关信息，本申请实施例对此用户数据所包括的具体内容不做具体限定。
用户数据可能会涉及用户隐私，比如前述中的邮箱和电话。如果这些用户数据泄露，可能会给用户带来困扰和损失。因此，第一服务器可以向第二服务器发送加密的第一用户数据，第一用户数据可以是前述用户确认授权的用户数据中的至少部分用户数据。当然，第一服务器还可以向第二服务器明文发送第二用户数据，第二用户数据可以是前述用户确认授权的用户数据中剩余的用户数据。
例如，第一服务器发送的用户数据可以如下所示：
“{
"sub":"248289761001",
"name":"Jane Doe",
"given_name":"Jane",
"family_name":"Doe",
"preferred_username":"j.doe",
"email":"eyJ0...NiJ9.eyerk...I4589fX0.DeWgghiQu...ZXso",
"mobile":"eyJ0...NiJ9.eyJ1c...I6IjIifX0.DeWt4Qu...ZXso",
"picture":"http://example.com/janedoe/me.jpg"
}”
与前一示例中第一服务器所发送的用户数据相比可知，其中，邮箱和电话等比较敏感的用户数据是加密的，极大地确保了这些用户数据的安全性。
在一些实施例中，当第一服务器向第二服务器发送用户数据时，若确定所将要发送的用户数据包括预设数据类型的用户数据时，将预设数据类型的用户数据确定为第一用户数据，并将剩余的用户数据确定为第二用户数据，从而对第一用户数据进行加密。当然，在实际应用中，第一服务器也可以通过其他方式来确定需要加密的第一用户数据，本申请实施例对此确定需要加密的第一用户数据的方式不做具体限定。
在一些实施例中，第一服务器可以获取第三消息包括的网络令牌，获取该网络令牌对应的密钥标识，并基于该密钥标识从存储的至少一个密钥中确定第一密钥。当获取到第一密钥时，第一服务器可以基于第一密钥对第一用户数据加密。
在一些实施例中，第一服务器可以基于第一密钥和高级加密标准(advancedencry ption standard，AES)，对第一用户数据加密。
例如，第一服务器可以以第一密钥作为密钥，基于AES256_伽罗瓦/计数器模式(galois/counter mode，GCM)对第一用户数据进行base64编码，从而得到加密的第一用户数据。
在一些实施例中，第一服务器可以向第二服务器发送第一密钥的密钥标识，以便于第二服务器后续基于第一密钥对加密的第一用户数据进行解密。
在一些实施例中，第一服务器可以向第二服务器发送前述进行base64编码所采用的第一向量字段，以便于后续第二服务器基于第一向量字段对加密的第一用户数据进行解密。
在一些实施例中，第一服务器可以将第一密钥的密钥标识、第一向量字段和加密的第一用户数据携带在第二JWT的载荷部分中，从而向第二服务器发送第二JWT。
其中，可以在JWT的载荷中增加加密用户数据字段，该加密用户数据字段可以用于存放加密的第一用户数据。相似的，可以在JWT中增加向量字段，该向量字段可以用于存放第一向量字段。
例如，可以在第二JWT的载荷中增加“ciphertext”、“auth_key_id”和“iv”等三个字段。其中，“ciphertext”为加密用户数据字段，其中携带加密的第一用户数据，“auth_key_id”为密钥标识字段，“iv”为向量字段，其中携带第一向量字段。
在一些实施例中，第一服务器可以通过预设的oauth私钥对加密的第一用户数据进行签名，那么第一服务器向第二服务器发送的为加密且携带第一服务器签名的第一用户数据。
其中，第一服务器可以对第二JWT进行签名。
在一些实施例中，第一服务器也可以不向第二服务器发送第一密钥的密钥标识。
S308，第二服务器基于第一密钥对加密的第一用户数据进行解密，从而得到第一用户数据。
当第二服务器获取到加密的第一用户数据时，可以基于第一密钥对加密的第一用户数据进行解密。可以看出，通过第一密钥可以确保对第一用户数据进行加密传输，除第二服务器和第一服务器之外的其他设备，由于无法获取得到第一密钥，那么即使获取到加密的第一用户数据，也难以对加密的第一用户数据进行解密，从而难以获取到第一用户数据的具体内容，提高了第一用户数据的安全性。
在一些实施例中，第二服务器可以判断接收到的用户数据中是否包括第二JWT，即是否包括JWT格式的用户数据。如果是，则获取预设的oauth公钥对第二JWT进行验签。如果验签成功则对第二JWT进行解析，包括从第二JWT载荷中的加密用户数据字段获取的加密的第一用户数据，从向量字段获取第一向量字段，从密钥标识字段获取第一密钥的密钥标识。第二服务器基于第一密钥的密钥标识，从存储的至少一个密钥中获取第一密钥，然后基于第一密钥和第一向量字段，对加密的第一用户数据进行解密，得到第一用户数据。
例如，第二服务器可以分别从第二JWT的“ciphertext”字段中获取到加密的第一用户数据包括“email":"eyJ0...NiJ9.eyerk...I4589fX0.DeWgghiQu...ZXso”和“mobile":"eyJ0...NiJ9.eyJ1c...I6IjIifX0.DeWt4Qu...ZXso”，从“auth_key_id”字段获取到第一密钥的密钥标识，进而获取到第一密钥，从“iv”字段获取到进行base64编码所使用的向量表。第二服务器基于第一密钥、该向量表和AES256_GCM，对加密的第一用户数据进行解码，得到明文的第一用户数据，包括“"email":"janedoe@example.com"”和“"mobile":"18680112915"”。
在一些实施例中，第二服务器若对第二JWT验签失败，则可以终止实施后续步骤。在一些实施例中，第二JWT可以不携带第一服务器的签名，因此，第二服务器可以不必对第二JWT进行验签。
在一些实施例中，第一JWT中可以不包括向量字段，那么第二服务器可以基于第一密钥，对加密的第一用户数据进行解密，得到第一用户数据。
在一些实施例中，第二服务器可以不获取第一密钥的密钥标识，而是可以通过授权码或者网络令牌，获取对应的第一密钥。或者，在另一些实施例中，第二服务器可以通过其他方式来获取第一密钥。
在一些实施例中，第二服务器可以获取第一服务器明文发送的第二用户数据。也即是，第一服务器可以只对向第二服务器发送的部分用户数据进行加密，以精准地对敏感的用户数据进行加密。
在本申请实施例中，第一服务器存储有与第二客户端对应的第一用户数据，第二服务器与第一客户端对应。第一服务器可以接收第一客户端发送的第一消息，由于第一消息中包括第二服务器的服务器地址，因此，第一客户端可以基于第二服务器的服务器地址，生成第一密钥，并将第一密钥提供给第二服务器。那么在第一服务器和第二服务器都存储有第一密钥的情况下，第一服务器便可以基于第一密钥，向第二服务器加密传输第一用户数据，从而提高了第一服务器向第二服务器提供用户数据的安全性。
请参照图6，为本申请实施例所提供的一种第一服务器向第二服务器发送网络令牌、第一密钥和密钥标识的方法流程图。在图6中，将以第一消息中携带第一授权模式指示符为例，说明第一服务器如何向爹服务器发送网络令牌和第一密钥。
S601，若第一服务器确定第一消息包括第一授权模式指示符，且接收到用户的确认授权操作，则生成授权码、第一密钥以及第一密钥的密钥标识。
其中，第一服务器可以将授权码与第一密钥的密钥标识，存储至授权码与密钥标识之间的对应关系中。
S602，第一服务器向第二服务器发送授权码、第一密钥和第一密钥的密钥标识。
其中，第一密钥和第一密钥的密钥标识可以携带在第一JWT的载荷中，且第一JWT携带第一服务器的签名。
S603，若第二服务器获取到授权码、第一密钥和第一密钥的密钥标识，则向第一服务器发送第二消息，第二消息包括该授权码和该密钥标识。
其中，第二服务器可以对第一JWT进行验签，如果验签成功，则从第一JWT中获取第一密钥和第一密钥的密钥标识。
在一些实施例中，第二服务器可以将授权码与第一密钥的密钥标识，存储至授权码与密钥标识之间的对应关系中，第二服务器可以将第一密钥与第一密钥的密钥标识，存储至密钥与密钥标识之间的对应关系中。
S604，若第一服务器确定第二消息包括的授权码与密钥标识对应，则生成网络令牌。
其中，第一服务器可以将网络令牌与第一密钥的密钥标识，存储至网络令牌与密钥标识之间的对应关系中。
S605，第一服务器向第二服务器发送网络令牌。
其中，第二服务器可以将网络令牌与第一密钥的密钥标识，存储至网络令牌与密钥标识之间的对应关系中。
基于同一发明构思，本申请实施例还提供了一种电子设备。图7为本申请实施例提供的电子设备700的结构示意图，如图7所示，本实施例提供的服务器700包括：存储器710和处理器720，存储器710用于存储计算机程序；处理器720用于在调用计算机程序时执行上述方法实施例所述的方法。
本实施例提供的电子设备700可以执行上述方法实施例，其实现原理与技术效果类似，此处不再赘述。
基于同一发明构思，本申请实施例还提供了一种芯片系统。该所述芯片系统包括处理器，所述处理器与存储器耦合，所述处理器执行存储器中存储的计算机程序，以实现上述方法实施例所述的方法。
其中，该芯片系统可以为单个芯片，或者多个芯片组成的芯片模组。
本申请实施例还提供一种计算机可读存储介质，其上存储有计算机程序，计算机程序被处理器执行时实现上述方法实施例所述的方法。
本申请实施例还提供一种计算机程序产品，当计算机程序产品在电子设备上运行时，使得电子设备执行时实现上述方法实施例所述的方法。
上述集成的单元如果以软件功能单元的形式实现并作为独立的产品销售或使用时，可以存储在一个计算机可读取存储介质中。基于这样的理解，本申请实现上述实施例方法中的全部或部分流程，可以通过计算机程序来指令相关的硬件来完成，所述的计算机程序可存储于一计算机可读存储介质中，该计算机程序在被处理器执行时，可实现上述各个方法实施例的步骤。其中，所述计算机程序包括计算机程序代码，所述计算机程序代码可以为源代码形式、对象代码形式、可执行文件或某些中间形式等。所述计算机可读存储介质至少可以包括：能够将计算机程序代码携带到拍照装置/终端设备的任何实体或装置、记录介质、计算机存储器、只读存储器(read-only memory，ROM)、随机存取存储器(random accessmemory，RAM)、电载波信号、电信信号以及软件分发介质。例如U盘、移动硬盘、磁碟或者光盘等。在某些司法管辖区，根据立法和专利实践，计算机可读介质不可以是电载波信号和电信信号。
在上述实施例中，对各个实施例的描述都各有侧重，某个实施例中没有详述或记载的部分，可以参见其它实施例的相关描述。
本领域普通技术人员可以意识到，结合本文中所公开的实施例描述的各示例的单元及算法步骤，能够以电子硬件、或者计算机软件和电子硬件的结合来实现。这些功能究竟以硬件还是软件方式来执行，取决于技术方案的特定应用和设计约束条件。专业技术人员可以对每个特定的应用来使用不同方法来实现所描述的功能，但是这种实现不应认为超出本申请的范围。
在本申请所提供的实施例中，应该理解到，所揭露的装置/设备和方法，可以通过其它的方式实现。例如，以上所描述的装置/设备实施例仅仅是示意性的，例如，所述模块或单元的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，例如多个单元或组件可以结合或者可以集成到另一个系统，或一些特征可以忽略，或不执行。另一点，所显示或讨论的相互之间的耦合或直接耦合或通讯连接可以是通过一些接口，装置或单元的间接耦合或通讯连接，可以是电性，机械或其它的形式。
应当理解，当在本申请说明书和所附权利要求书中使用时，术语“包括”指示所描述特征、整体、步骤、操作、元素和/或组件的存在，但并不排除一个或多个其它特征、整体、步骤、操作、元素、组件和/或其集合的存在或添加。
还应当理解，在本申请说明书和所附权利要求书中使用的术语“和/或”是指相关联列出的项中的一个或多个的任何组合以及所有可能组合，并且包括这些组合。
如在本申请说明书和所附权利要求书中所使用的那样，术语“如果”可以依据上下文被解释为“当...时”或“一旦”或“响应于确定”或“响应于检测到”。类似地，短语“如果确定”或“如果检测到[所描述条件或事件]”可以依据上下文被解释为意指“一旦确定”或“响应于确定”或“一旦检测到[所描述条件或事件]”或“响应于检测到[所描述条件或事件]”。
另外，在本申请说明书和所附权利要求书的描述中，术语“第一”、“第二”、“第三”等仅用于区分描述，而不能理解为指示或暗示相对重要性。
在本申请说明书中描述的参考“一个实施例”或“一些实施例”等意味着在本申请的一个或多个实施例中包括结合该实施例描述的特定特征、结构或特点。由此，在本说明书中的不同之处出现的语句“在一个实施例中”、“在一些实施例中”、“在其他一些实施例中”、“在另外一些实施例中”等不是必然都参考相同的实施例，而是意味着“一个或多个但不是所有的实施例”，除非是以其他方式另外特别强调。术语“包括”、“包含”、“具有”及它们的变形都意味着“包括但不限于”，除非是以其他方式另外特别强调。
最后应说明的是：以上各实施例仅用以说明本申请的技术方案，而非对其限制；尽管参照前述各实施例对本申请进行了详细的说明，本领域的普通技术人员应当理解：其依然可以对前述各实施例所记载的技术方案进行修改，或者对其中部分或者全部技术特征进行等同替换；而这些修改或者替换，并不使相应技术方案的本质脱离本申请各实施例技术方案的范围。

Claims (32)

1.一种基于开放式授权的数据传输方法，其特征在于，包括：
第一服务器接收第一客户端发送的第一消息，所述第一消息包括与第一客户端对应的第二服务器的服务器地址，所述第一服务器存储有与第二客户端对应的第一用户数据；
所述第一服务器基于所述第二服务器的服务器地址，生成第一密钥；
所述第一服务器基于所述第二服务器的地址，向所述第二服务器发送所述第一密钥；
所述第一服务器基于所述第一密钥，向所述第二服务器传输所述第一用户数据。
2.根据权利要求1所述的方法，其特征在于，所述第一服务器基于所述第二服务器的地址，向所述第二服务器发送所述第一密钥，包括：
所述第一服务器向所述第二服务器发送所述第一密钥和所述第一密钥的密钥标识，所述密钥标识用于所述第二服务器从至少一个密钥中获取所述第一密钥。
3.根据权利要求2所述的方法，其特征在于，所述第一服务器向所述第二服务器发送所述第一密钥和所述第一密钥的密钥标识，包括：
所述第一服务器向所述第二服务器发送第一脚本对象简谱网络令牌JWT，所述第一JWT携带所述第一密钥和所述密钥标识。
4.根据权利要求2或3所述的方法，其特征在于，所述第一消息包括所述第一客户端的客户端标识，所述第一服务器基于所述第二服务器的服务器地址，生成第一密钥，包括：
所述第一服务器基于预设的授权接口协议生成授权码；
所述第一服务器获取与所述客户端标识对应的客户端密钥；
所述第一服务器基于所述授权码、所述第二服务器的服务器地址、预设长度的随机字符串和所述客户端密钥，生成所述第一密钥。
5.根据权利要求4所述的方法，其特征在于，所述授权接口协议为请求评论RFC9749授权接口协议。
6.根据权利要求5所述的方法，其特征在于，所述第一消息包括第一授权模式指示符，所述第一授权模式指示符用于指示向所述第二服务器发送所述授权码，在所述第一服务器基于所述第二服务器的地址，向所述第二服务器发送所述第一密钥之前，所述方法还包括：
所述第一服务器向所述第二服务器发送所述授权码；
若所述第一服务器接收到所述第二服务器发送的第二消息，且所述第二消息包括所述授权码和所述密钥标识，则所述第一服务器基于所述授权接口协议生成网络令牌；
所述第一服务器向所述第二服务器发送所述网络令牌。
7.根据权利要求4所述的方法，其特征在于，所述第一消息包括第一授权模式指示符，所述第一授权模式指示符用于指示向所述第二服务器发送所述授权码，在所述第一服务器基于所述第二服务器的地址，向所述第二服务器发送所述第一密钥之前，所述方法还包括：
所述第一服务器向所述第二服务器发送所述授权码；
若所述第一服务器接收到所述第二服务器发送的第二消息，且所述第二消息包括所述授权码和所述密钥标识，则所述第一服务器基于所述授权接口协议生成网络令牌；
所述第一服务器向所述第二服务器发送所述网络令牌。
8.根据权利要求4所述的方法，其特征在于，所述第一消息包括一次性的非重复随机数值Nounce，所述第一服务器基于所述授权码、所述第二服务器的服务器地址、预设长度的随机字符串和所述客户端密钥，生成所述第一密钥，包括：
所述第一服务器基于所述授权码、所述Nounce、所述第二服务器的服务器地址、预设长度的随机字符串和所述客户端密钥，生成所述第一密钥。
9.根据权利要求8所述的方法，其特征在于，所述授权接口协议为开放身份连接OIDC授权接口协议。
10.根据权利要求8或9所述的方法，其特征在于，所述第一消息包括第二授权模式指示符，所述第二授权模式指示符用于指示向所述第二服务器发送网络令牌，所述方法还包括：
所述第一服务器基于所述授权接口协议，生成所述网络令牌；
所述第一服务器向所述第二服务器发送所述网络令牌。
11.根据权利要求10所述的方法，其特征在于，所述第一服务器基于所述第一密钥，向所述第二服务器传输所述第一用户数据，包括：
所述第一服务器接收所述第二服务器发送的第三消息，所述第三消息包括所述网络令牌；
所述第一服务器基于所述第一密钥，对所述第一用户数据进行加密，得到加密的所述第一用户数据；
所述第一服务器向所述第二服务器发送所述密钥标识和加密的所述第一用户数据。
12.根据权利要求11所述的方法，其特征在于，所述第一服务器基于所述第一密钥，对所述第一用户数据进行加密，得到加密的所述第一用户数据，包括：
所述第一服务器基于所述第一密钥和预设的第一向量字段，对所述第一用户数据进行加密，得到加密的所述第一用户数据；
所述第一服务器向所述第二服务器发送所述密钥标识和加密的所述第一用户数据，包括：
所述第一服务器向所述第二服务器发送所述密钥标识、所述第一向量字段和加密的所述第一用户数据。
13.根据权利要求12所述的方法，其特征在于，所述第一服务器向所述第二服务器发送所述密钥标识、第一向量和加密的所述第一用户数据，包括：
所述第一服务器向所述第二服务器发送第二JWT，所述第二JWT中携带所述密钥标识、所述第一向量字段和加密的所述第一用户数据。
14.根据权利要求6或7所述的方法，其特征在于，所述第一服务器基于所述第一密钥，向所述第二服务器传输所述第一用户数据，包括：
所述第一服务器接收所述第二服务器发送的第三消息，所述第三消息包括所述网络令牌；
所述第一服务器基于所述第一密钥，对所述第一用户数据进行加密，得到加密的所述第一用户数据；
所述第一服务器向所述第二服务器发送所述密钥标识和加密的所述第一用户数据。
15.根据权利要求14所述的方法，其特征在于，所述第一服务器基于所述第一密钥，对所述第一用户数据进行加密，得到加密的所述第一用户数据，包括：
所述第一服务器基于所述第一密钥和预设的第一向量字段，对所述第一用户数据进行加密，得到加密的所述第一用户数据；
所述第一服务器向所述第二服务器发送所述密钥标识和加密的所述第一用户数据，包括：
所述第一服务器向所述第二服务器发送所述密钥标识、所述第一向量字段和加密的所述第一用户数据。
16.根据权利要求15所述的方法，其特征在于，所述第一服务器向所述第二服务器发送所述密钥标识、第一向量和加密的所述第一用户数据，包括：
所述第一服务器向所述第二服务器发送第二JWT，所述第二JWT中携带所述密钥标识、所述第一向量字段和加密的所述第一用户数据。
17.根据权利要求1-3中的任一、5-9中的任一、11-13中的任一或15-16中任一所述的方法，其特征在于，所述第一服务器存储有与所述第二客户端对应的第二用户数据，所述方法还包括：
所述第一服务器向所述第二服务器发送所述第二用户数据。
18.根据权利要求1-3中的任一、5-9中的任一、11-13中的任一或15-16中任一所述的方法，其特征在于，所述第一服务器基于所述第二服务器的服务器地址，生成第一密钥，包括：
若所述第一消息包括第一密钥协商标志符，则所述第一服务器基于所述第二服务器的服务器地址，生成所述第一密钥。
19.一种基于开放式授权的数据传输方法，其特征在于，包括：
第二服务器接收第一服务器发送的第一密钥；
所述第二服务器基于所述第一密钥，获取所述第一服务器传输的第一用户数据；
其中，所述第二服务器与第一客户端对应，所述第一服务器存储有与第二客户端对应的第一用户数据，所述第一密钥由所述第一服务器在接收到所述第一客户端发送的第一消息时生成并发送，所述第一消息包括所述第二服务器的服务器地址。
20.根据权利要求19所述的方法，其特征在于，所述第二服务器接收第一服务器发送的第一密钥，包括：
所述第二服务器接收所述第一服务器发送的所述第一密钥和所述第一密钥的密钥标识，所述密钥标识用于所述第二服务器从至少一个密钥中获取所述第一密钥。
21.根据权利要求20所述的方法，其特征在于，所述第二服务器接收所述第一服务器发送的所述第一密钥和所述第一密钥的密钥标识，包括：
所述第二服务器接收所述第一服务器发送的第一JWT，所述第一JWT携带所述第一密钥和所述密钥标识。
22.根据权利要求20或21所述的方法，其特征在于，所述第一消息包括第一授权模式指示符，所述第一授权模式指示符用于指示向所述第二服务器发送授权码，所述方法还包括：
所述第二服务器接收所述第一服务器发送的所述授权码，所述授权码由所述第一服务器基于预设的授权接口协议生成；
所述第二服务器向所述第一服务器发送第二消息，所述第二消息包括所述授权码和所述密钥标识；
所述第二服务器接收所述第一服务器发送的网络令牌，所述网络令牌由所述第一服务器基于所述授权接口协议生成。
23.根据权利要求20或21所述的方法，其特征在于，所述第一消息包括第二授权模式指示符，所述第二授权模式指示符用于指示向所述第二服务器发送网络令牌，所述方法还包括：
所述第二服务器接收所述第一服务器发送的所述网络令牌，所述网络令牌由所述第一服务器基于预设的授权接口协议生成。
24.根据权利要求22所述的方法，其特征在于，所述方法还包括：
所述第二服务器向所述第一服务器发送第三消息，所述第三消息包括所述网络令牌；
所述第二服务器接收所述第一服务器发送的所述密钥标识和加密的所述第一用户数据；
所述第二服务器基于所述密钥标识，从至少一个密钥中获取所述第一密钥；
所述第二服务器基于所述第一密钥对加密的所述第一用户数据进行解密，得到所述第一用户数据。
25.根据权利要求24所述的方法，其特征在于，所述第二服务器接收所述第一服务器发送的所述密钥标识和加密的所述第一用户数据，包括：
所述第二服务器接收所述第一服务器发送的所述密钥标识、第一向量字段和加密的所述第一用户数据；
所述第二服务器基于所述第一密钥对加密的所述第一用户数据进行解密，得到所述第一用户数据，包括：
所述第二服务器基于所述第一密钥和所述第一向量字段，对加密的所述第一用户数据进行解密的，得到所述第一用户数据。
26.根据权利要求25所述的方法，其特征在于，所述第二服务器接收所述第一服务器发送的所述密钥标识、第一向量字段和加密的所述第一用户数据，包括：
所述第二服务器接收所述服务器发送的第二JWT，所述第二JWT中携带所述密钥标识、所述第一向量字段和加密的所述第一用户数据。
27.根据权利要求23所述的方法，其特征在于，所述方法还包括：
所述第二服务器向所述第一服务器发送第三消息，所述第三消息包括所述网络令牌；
所述第二服务器接收所述第一服务器发送的所述密钥标识和加密的所述第一用户数据；
所述第二服务器基于所述密钥标识，从至少一个密钥中获取所述第一密钥；
所述第二服务器基于所述第一密钥对加密的所述第一用户数据进行解密，得到所述第一用户数据。
28.根据权利要求27所述的方法，其特征在于，所述第二服务器接收所述第一服务器发送的所述密钥标识和加密的所述第一用户数据，包括：
所述第二服务器接收所述第一服务器发送的所述密钥标识、第一向量字段和加密的所述第一用户数据；
所述第二服务器基于所述第一密钥对加密的所述第一用户数据进行解密，得到所述第一用户数据，包括：
所述第二服务器基于所述第一密钥和所述第一向量字段，对加密的所述第一用户数据进行解密的，得到所述第一用户数据。
29.根据权利要求28所述的方法，其特征在于，所述第二服务器接收所述第一服务器发送的所述密钥标识、第一向量字段和加密的所述第一用户数据，包括：
所述第二服务器接收所述服务器发送的第二JWT，所述第二JWT中携带所述密钥标识、所述第一向量字段和加密的所述第一用户数据。
30.根据权利要求19-21中任一或24-29中任一所述的方法，其特征在于，所述第一服务器存储有与所述第二客户端对应的第二用户数据，所述方法还包括：
所述第二服务器接收所述第一服务器发送的所述第二用户数据。
31.一种电子设备，其特征在于，包括：存储器和处理器，所述存储器用于存储计算机程序；所述处理器用于在调用所述计算机程序时执行如权利要求1-18任一项或如权利要求19-30任一项所述的方法。
32.一种计算机可读存储介质，其上存储有计算机程序，其特征在于，所述计算机程序被处理器执行时实现如权利要求1-18任一项或如权利要求19-30任一项所述的方法。
CN202011176630.6A 2020-10-28 2020-10-28 基于开放式授权的数据传输方法及电子设备 Active CN114513299B (zh)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN202011176630.6A CN114513299B (zh) 2020-10-28 2020-10-28 基于开放式授权的数据传输方法及电子设备

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN202011176630.6A CN114513299B (zh) 2020-10-28 2020-10-28 基于开放式授权的数据传输方法及电子设备

Publications (2)

Publication Number Publication Date
CN114513299A CN114513299A (zh) 2022-05-17
CN114513299B true CN114513299B (zh) 2024-01-30

Family

ID=81547064

Family Applications (1)

Application Number Title Priority Date Filing Date
CN202011176630.6A Active CN114513299B (zh) 2020-10-28 2020-10-28 基于开放式授权的数据传输方法及电子设备

Country Status (1)

Country Link
CN (1) CN114513299B (zh)

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN109788002A (zh) * 2019-03-12 2019-05-21 北京首汽智行科技有限公司 一种Http请求加密、解密方法及系统
CN111327582A (zh) * 2019-08-22 2020-06-23 刘高峰 一种基于OAuth协议的授权方法、装置及系统

Family Cites Families (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US9130926B2 (en) * 2012-12-27 2015-09-08 Microsoft Technology Licensing, Llc Authorization messaging with integral delegation data
JP6904857B2 (ja) * 2017-08-31 2021-07-21 キヤノン株式会社 権限委譲システム、制御方法、およびプログラム

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN109788002A (zh) * 2019-03-12 2019-05-21 北京首汽智行科技有限公司 一种Http请求加密、解密方法及系统
CN111327582A (zh) * 2019-08-22 2020-06-23 刘高峰 一种基于OAuth协议的授权方法、装置及系统

Also Published As

Publication number Publication date
CN114513299A (zh) 2022-05-17

Similar Documents

Publication Publication Date Title
WO2022206349A1 (zh) 一种信息验证的方法、相关装置、设备以及存储介质
US10554420B2 (en) Wireless connections to a wireless access point
KR101636028B1 (ko) 로컬 기능을 갖는 아이덴티티 관리
US8532620B2 (en) Trusted mobile device based security
US8091116B2 (en) Communication system and method
WO2019079356A1 (en) AUTHENTICATION TOKEN WITH CUSTOMER KEY
WO2016177052A1 (zh) 一种用户认证方法和装置
US9264420B2 (en) Single sign-on for network applications
US20130159711A1 (en) Communication System and Method
US11824854B2 (en) Communication system and computer readable storage medium
WO2010078755A1 (zh) 电子邮件的传送方法、系统及wapi终端
TWI632798B (zh) 伺服器、行動終端機、網路實名認證系統及方法
US11777743B2 (en) Method for securely providing a personalized electronic identity on a terminal
CN113992346B (zh) 一种基于国密加固的安全云桌面的实现方法
US20140095873A1 (en) Method and system for hypertext transfer protocol digest authentication
WO2018141219A1 (zh) 认证服务器、认证系统及方法
JP2020078067A (ja) モバイルデバイスを有するユーザがスタンドアロンコンピューティングデバイスの能力にアクセスすることをセキュアに可能にするためのシステム及び方法
RU2698424C1 (ru) Способ управления авторизацией
CN117336092A (zh) 一种客户端登录方法、装置、电子设备和存储介质
CN108306881A (zh) 一种身份验证方法和装置
CN114513299B (zh) 基于开放式授权的数据传输方法及电子设备
WO2016003310A1 (en) Bootstrapping a device to a wireless network
CN111835734A (zh) 信息处理方法、装置、电子设备、服务器及存储介质
US20200274873A1 (en) Method for authenticating a user with an authentication server
US11343078B2 (en) System and method for secure input at a remote service

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
GR01 Patent grant
GR01 Patent grant