Access token processing method, device and cloud

Abstract

The application relates to an access token processing method, device and cloud. The access token processing method comprises the following steps: a first device receives an encrypted access token, the encrypted access token being obtained by encrypting at least one level of access token by using an access key of the first device; and the first device decrypts the encrypted access token by using the access key. According to the embodiment of the application, the at least one level of access token is encrypted, so that the access permission of a finer granularity can be safely controlled.

Description

Technical Field

[0001] This application relates to the field of communications, and more specifically, to an access token processing method, device, and cloud. Background Technology

[0002] The Open Link Alliance (OLA) specification for smart homes does not yet define access control permissions and methods for application terminals. Users issue access tokens to devices via mobile applications or cloud platforms, or devices actively request access tokens from the cloud platform, enabling devices under a user's account to access each other. The cloud platform is also known as the cloud itself or access cloud. However, current access tokens cannot achieve more granular and secure access control. Summary of the Invention

[0003] This application provides an access token processing method, device, and cloud that can securely control more granular access permissions.

[0004] This application provides an access token processing method, including:

[0005] The first device receives an encrypted access token, which is obtained by encrypting an access token of at least one level using the first device's access key;

[0006] The first device uses the access key to decrypt the encrypted access token.

[0007] This application provides an access token processing method, including:

[0008] The configuration device receives an encrypted access token from a first cloud, which is obtained by the first cloud encrypting an access token of at least one level using the access key of the first device;

[0009] The configured device sends the encrypted access token to the first device.

[0010] This application provides an access token processing method, including:

[0011] The first cloud uses the access key of the first device to encrypt the access token at at least one level;

[0012] The first cloud sends an encrypted access token.

[0013] This application provides an access token processing method, including:

[0014] The second cloud receives a token sharing request from the second device, which includes information about at least one level of access token that needs to be shared;

[0015] The second cloud encrypts the access token corresponding to the information of at least one level of access token.

[0016] The second cloud sends an encrypted access token.

[0017] This application provides an access token processing method, including:

[0018] The second device sends a token sharing request, which includes information about at least one level of access token to be shared and information about the first device.

[0019] The second device receives an encrypted access token, which is obtained by encrypting at least one level of access token to be shared using the access key corresponding to the information of the first device.

[0020] The second device sends the encrypted access token.

[0021] This application provides a first device, including:

[0022] A receiving unit is used to receive an encrypted access token, which is obtained by encrypting an access token of at least one level using the access key of the first device;

[0023] The decryption unit is used to decrypt the encrypted access token using the access key.

[0024] This application provides a configuration device, including:

[0025] The receiving unit is configured to receive an encrypted access token from the first cloud, wherein the encrypted access token is obtained by the first cloud encrypting an access token of at least one level using the access key of the first device;

[0026] The sending unit is used to send the encrypted access token to the first device.

[0027] This application provides a first cloud platform, including:

[0028] The first encryption unit is used to encrypt an access token of at least one level using the access key of the first device;

[0029] The first sending unit is used to send encrypted access tokens.

[0030] This application provides a second cloud platform, including:

[0031] A receiving unit is configured to receive a token sharing request from a second device, the token sharing request including information about at least one level of access tokens that need to be shared;

[0032] An encryption unit is used to encrypt the access token corresponding to the information of the access token at least one level;

[0033] The sending unit is used to send encrypted access tokens.

[0034] This application provides a second device, including:

[0035] The first sending unit is used to send a token sharing request, which includes information about at least one level of access token to be shared and information about the first device.

[0036] The receiving unit is used to receive an encrypted access token, which is obtained by encrypting an access token of at least one level that needs to be shared using the access key corresponding to the information of the first device.

[0037] The second sending unit sends the encrypted access token.

[0038] This application provides a first device, including a processor and a memory. The memory stores a computer program, and the processor calls and runs the computer program stored in the memory to cause the terminal device to perform the access token processing method described above.

[0039] This application provides a configuration device including a processor and a memory. The memory stores a computer program, and the processor calls and runs the computer program stored in the memory to cause the network device to perform the access token processing method described above.

[0040] This application provides a first cloud platform, including a processor and a memory. The memory stores computer programs, and the processor calls and runs the computer programs stored in the memory to cause the terminal device to perform the access token processing method described above.

[0041] This application provides a second cloud platform, including a processor and a memory. The memory stores computer programs, and the processor calls and runs the computer programs stored in the memory to cause the terminal device to perform the access token processing method described above.

[0042] This application provides a second device, including a processor and a memory. The memory stores a computer program, and the processor calls and runs the computer program stored in the memory to cause the terminal device to perform the access token processing method described above.

[0043] This application provides a chip for implementing the access token processing method described above.

[0044] Specifically, the chip includes a processor for retrieving and running a computer program from memory, causing a device equipped with the chip to perform the aforementioned access token processing method.

[0045] This application provides a computer-readable storage medium for storing a computer program that, when run by a device, causes the device to perform the access token processing method described above.

[0046] This application provides a computer program product, including computer program instructions that cause a computer to execute the access token processing method described above.

[0047] This application provides a computer program that, when run on a computer, causes the computer to execute the access token processing method described above.

[0048] In this embodiment of the application, more granular access permissions can be securely controlled by encrypting access tokens at at least one level. Attached Figure Description

[0049] Figure 1 This is a schematic diagram of an OLA device model according to an embodiment of this application.

[0050] Figure 2 This is a flowchart illustrating an example of issuing an access token.

[0051] Figure 3 This is a schematic flowchart of an access token processing method according to an embodiment of this application.

[0052] Figure 4 This is a schematic flowchart of an access token processing method according to another embodiment of this application.

[0053] Figure 5 This is a schematic flowchart of an access token processing method according to another embodiment of this application.

[0054] Figure 6 This is a schematic flowchart of an access token processing method according to another embodiment of this application.

[0055] Figure 7 This is a schematic flowchart of an access token processing method according to another embodiment of this application.

[0056] Figure 8 This is a flowchart illustrating an example of issuing a token.

[0057] Figure 9 This is a flowchart of an example of updating a token.

[0058] Figure 10 This is a flowchart illustrating an example of deleting a token.

[0059] Figure 11 This is a flowchart illustrating an example of sharing tokens through the same access cloud.

[0060] Figure 12 This is a flowchart illustrating an example of sharing tokens through different access clouds.

[0061] Figure 13 This is a schematic block diagram of a first device according to an embodiment of this application.

[0062] Figure 14 This is a schematic block diagram of a first device according to another embodiment of this application.

[0063] Figure 15 This is a schematic block diagram of a configuration device according to an embodiment of this application.

[0064] Figure 16 This is a schematic block diagram of a first cloud according to an embodiment of this application.

[0065] Figure 17 This is a schematic block diagram of a first cloud according to another embodiment of this application.

[0066] Figure 18 This is a schematic block diagram of a second cloud according to an embodiment of this application.

[0067] Figure 19 This is a schematic block diagram of a second device according to an embodiment of this application.

[0068] Figure 20 This is a schematic block diagram of a communication device according to an embodiment of this application.

[0069] Figure 21 This is a schematic block diagram of a chip according to an embodiment of this application.

[0070] Figure 22 This is a schematic block diagram of a communication system according to an embodiment of this application. Detailed Implementation

[0071] The technical solutions in the embodiments of this application will now be described with reference to the accompanying drawings.

[0072] To facilitate understanding of the technical solutions of the embodiments of this application, the relevant technologies of the embodiments of this application are described below. The following relevant technologies are optional solutions and can be combined with the technical solutions of the embodiments of this application in any way, and they all fall within the protection scope of the embodiments of this application.

[0073] 1. Regarding the device model of the Open Link Alliance (OLA):

[0074] According to the draft OLA (Optical Home Architecture) specification for smart homes, the device model for OLA can be found in [link / reference]. Figure 1 The devices can include various application terminals, such as smart home devices in a smart home scenario. Application terminals can be described by different service sets. A service can be an independent and meaningful group of functions, and can include attributes, methods, events, etc. Attributes are the smallest unit describing the state and function of an application terminal. Methods are used to implement specific functions of a service; these functions generally cannot be accomplished by reading or writing a single attribute. Events can include specific information that the application terminal actively reports to other devices.

[0075] For example, a device may include the following fields:

[0076] type: Device type, which may include device name, device type unique identifier (deviceUUID), etc.;

[0077] Description: A description of the device, used to explain its functions, etc.

[0078] serviceList: A list of services, where each service can be identified by its type and whether it is required on this device.

[0079] For example, a service can include the following fields:

[0080] type: Service type, which may include service name, unique identifier of service type (ServiceUUID), etc.;

[0081] Description: A description of the service, used to explain the purpose of the service, etc.

[0082] actionList: A list of methods, where each method can include its type and whether it is required in this service;

[0083] eventList: A list of events, where each event can include its type and whether it is required in this service;

[0084] propertyList: A list of properties, where each property can include its type and whether it is required in this service.

[0085] For example, a property can include the following fields:

[0086] type: The property type, which may include the property name (name), the unique identifier of the property type (propertyUUID), etc.;

[0087] dataType: The data type of the attribute value, such as integer, string, structure, etc.;

[0088] access: Access permissions for an attribute, such as read (R), write (W), notification (N), and any combination of the three. Generally, attributes that support notification (N) permissions also need to support read (R) permissions; attributes that only support write (W) permissions and do not support read (R) permissions should not support notification (N) permissions.

[0089] For example, an action can include the following fields:

[0090] type: Method type, which may include operation name (name), unique identifier of operation type (actionUUID), etc.;

[0091] Description: A description of the operation, used to explain the purpose of the operation or the rules for its use;

[0092] inParameter: A list of input parameters, which can be zero or more;

[0093] outParameter: Output parameter list, which can be 0 or more.

[0094] For example, an event can include the following fields:

[0095] type: Event type, which can include event name, event unique identifier (eventUUID), etc.; for example, event type can include: message (general message, such as device online / offline), alert (alarm message, such as refrigerator door not closed) and fault (device failure message, such as compressor not working), etc.

[0096] outParameter: The reported event message may contain 0 or more parameters; the above attribute should support notification.

[0097] Description: A description of the event, used to explain the purpose of the event or the rules used, etc.

[0098] 2. Access the cloud and issue access keys to application terminals.

[0099] When an application terminal (or smart device, IoT device, etc.) is configured to join the network or connects to the access cloud for the first time, the access cloud can issue a unique access key, such as a pre-shared key (PSK), to the application terminal to verify the identities of both parties.

[0100] 3. Access Token Management Methods:

[0101] Users issue access tokens to devices via mobile applications or cloud platforms, or devices actively request access tokens from the cloud platform, enabling devices under a user's account to access each other. The cloud platform can also be referred to as the cloud itself, access cloud, etc. See also Figure 2 The following is an example of the process of issuing a token for access:

[0102] (1) An example of a process for issuing access tokens to devices via the cloud may include:

[0103] S11 and S12. Configure device network access. For example, users configure IoT (Internet of Things) devices to access the network via a mobile application.

[0104] S13. Equipment is connected to the network for the first time.

[0105] S14. If there is no account-level access token in the access cloud, an account-level token can be generated and saved; if there is an account-level token in the access cloud, then S15 will be executed directly to issue the account-level token to the device. Generally, when a device first joins the network, there is no account-level token in the access cloud; when the device joins the network again, there may be an access token in the access cloud.

[0106] S15. Access the cloud and issue an account-level token to the device.

[0107] (2) An example of a process for issuing an access token to a device via a mobile phone may include:

[0108] S21. The mobile application requests an account-level token from the access cloud.

[0109] S22. If there is no account-level token in the cloud, an account-level token can be generated and saved. If there is an account-level token in the cloud, then S23 will be executed directly to send the account-level token to the mobile application.

[0110] S23. Access the cloud to issue account-level tokens to mobile applications.

[0111] S24. The mobile application sends an account-level token to the device.

[0112] (3) Examples of a process in which a device actively requests an access token may include.

[0113] S31. The IoT device checks whether it has an account-level token. If not, it executes S32 to request the access cloud.

[0114] S32. IoT devices request an account-level token from the access cloud.

[0115] S33. If there is no account-level token in the cloud, an account-level token can be generated and saved. If there is an account-level token in the cloud, S34 can be executed directly to send the account-level token to the device.

[0116] S34. Access the cloud and send an account-level token to the device.

[0117] In this example, the access token only provides account-level access control, which is not granular enough to allow for more flexible access control of devices, services, attributes, etc.

[0118] 4. Multi-level access tokens:

[0119] This application embodiment can provide multi-level access tokens and perform various management functions on these tokens. An example of the attributes and level description of a multi-level access token is as follows:

[0120]

[0121] Optionally, if a device belongs to multiple accounts on the same platform, the token ID can be a combination of the account ID and the index within the account to avoid conflicts between token indexes under different accounts.

[0122] Optionally, if a device belongs to accounts on multiple different platforms, the token ID can be a combination of the platform ID, the account ID, and the index within the account to avoid conflicts between token indexes under different accounts.

[0123] Depending on the user's actual permission control needs, a device can be set with zero or one device-level tokens, zero or one service-level tokens, or zero or one attribute-level tokens.

[0124] In this embodiment of the application, it is also possible to prevent unauthorized mobile applications from issuing, updating, deleting, or sharing access tokens to application terminals (smart devices).

[0125] Figure 3This is a schematic flowchart of an access token processing method 30 according to an embodiment of this application. This method can optionally be applied to... Figure 1 The device model shown is not limited to this. The method includes at least a portion of the following.

[0126] S310, The first device receives an encrypted access token, which is obtained by encrypting an access token of at least one level using the access key of the first device;

[0127] S320, The first device uses the access key to decrypt the encrypted access token.

[0128] Optionally, the access token for at least one level includes at least one of the following:

[0129] Account-level access tokens;

[0130] Device-level access tokens;

[0131] Service-level access token;

[0132] Attribute-level access tokens.

[0133] In this embodiment of the application, account-level access tokens can control account-level access permissions, device-level access tokens can control device-level access permissions, service-level access tokens can control service-level access permissions, and attribute-level access tokens can control attribute-level access permissions. The granularity of control is finer, which is conducive to flexible access control of devices, services, attributes, etc.

[0134] Optionally, an account-level access token is used to access at least one of the unrestricted attributes, unrestricted methods, and unrestricted events of unrestricted services of a device under the same account.

[0135] For example, the scope of permissions for an account-level access token may include at least one of unrestricted attributes, unrestricted methods, and unrestricted events that allow access to unrestricted services on all devices under a certain account. In this embodiment, allowing access to unrestricted attributes may include allowing read, write, add, delete, and modify operations on the unrestricted attribute.

[0136] In a specific example of permission scopes, an account includes device A and device B. Device A has restricted services S1 and S2 and unrestricted service S3. S1 has unrestricted attributes C1 and C2 and a restricted event E0. S2 has restricted attribute C3 and unrestricted attribute C4. S3 has unrestricted method F1 and restricted method F2. Device B has unrestricted service S4 and restricted services S5 and S6. S4 has unrestricted attribute C5. S5 has unrestricted attribute C6 and an unrestricted event E1. S6 has unrestricted attribute C7, restricted attribute C8, and restricted method F3.

[0137] If the scope of the account-level access token for this account can include allowing access to unrestricted method F1 of unrestricted service S3 on device A, and unrestricted attribute C5 of unrestricted service S4 on device B, and if C5 supports read and write permissions, then the scope of the account-level access token can also include allowing read and write operations on C5.

[0138] Optionally, a device-level access token is used to access at least one of the unrestricted attributes, unrestricted methods, and unrestricted events of unrestricted services on the same device or multiple devices under the same account.

[0139] For example, the scope of a device-level access token may include at least one of the following: unrestricted attributes, unrestricted methods, and unrestricted events that allow access to all unrestricted services on the same device. If all devices under an account use the same device-level access token, then the scope of that device-level access token is equivalent to the scope of the account-level access token. Referring to the examples of scopes above, in a specific example, the scope of a device-level access token for device A may include unrestricted method F1 that allows access to unrestricted service S3 on device A. The scope of a device-level access token for device B may include unrestricted attribute C5 that allows access to unrestricted service S4 on device B.

[0140] Optionally, service-level access tokens include:

[0141] Service-level access tokens for the same device;

[0142] Service-level access tokens across devices.

[0143] For example, the scope of a service-level access token may include all unrestricted attributes that allow access to one or more restricted services on one or more specified devices.

[0144] Optionally,

[0145] A service-level access token for the same device is used to access at least one of the unrestricted attributes, unrestricted methods, and unrestricted events of at least one restricted service on the same device;

[0146] A cross-device service-level access token is used to access at least one of the unrestricted attributes, unrestricted methods, and unrestricted events of at least one restricted service across multiple devices.

[0147] In a specific example, the scope of access tokens for the same service level on the same device may include: allowing access to unrestricted attributes C1 and C2 of restricted service S1 on device A.

[0148] In a specific example, the scope of access tokens for service-level access across devices may include: allowing access to unrestricted attributes C1 and C2 of restricted service S1 on device A, and unrestricted attribute C7 of restricted service S6 on device B.

[0149] Optionally, attribute-level access tokens include:

[0150] Access tokens at the attribute level of the same service;

[0151] Cross-service attribute-level access tokens;

[0152] Cross-device attribute-level access tokens.

[0153] For example, the scope of an attribute-level access token may include one or more restricted attributes, restricted methods, or restricted events that allow access to one or more restricted services on one or more specified devices. The scope of an attribute-level access token may also include one or more restricted attributes, restricted methods, or restricted events that allow access to one or more unrestricted services on one or more specified devices.

[0154] Optionally,

[0155] An access token at the attribute level of the same service is used to access at least one of the restricted attributes, restricted methods, and restricted events of the same service on the same device;

[0156] Cross-service attribute-level access tokens are used to access at least one of at least one of the restricted attributes, restricted methods, and restricted events of multiple services on the same device;

[0157] A cross-device attribute-level access token is used to access at least one of at least one of the restricted attributes, restricted methods, and restricted events of multiple services across multiple devices.

[0158] The same service mentioned above can be either the same restricted service or the same unrestricted service.

[0159] The aforementioned multiple services may include multiple restricted services, multiple unrestricted services, or both restricted and unrestricted services.

[0160] In a specific example, the permission scope of an access token at the attribute level for the same service may include: allowing access to restricted attribute C3 of restricted service S2 on device A.

[0161] In a specific example, the permission scope of an access token at the attribute level for the same service may include: a restricted method F2 that allows access to the unrestricted service S3 on device A.

[0162] In a specific example, the scope of access tokens at the attribute level across services may include: restricted event E0 of restricted service S1 on device A, and restricted attribute C3 of restricted service S2.

[0163] In a specific example, the scope of access tokens at the attribute level across services can include: restricted events E0 of restricted service S1 that allows access to device A, and restricted methods F2 of unrestricted service S3.

[0164] In a specific example, the scope of access token permissions across device attribute levels may include: restricted attribute C3 allowing access to restricted service S2 on device A, and restricted attribute C8 and restricted method F3 for restricted service S6 on device B.

[0165] In a specific example, the scope of access token permissions across device attribute levels may include: restricted method F2 that allows access to unrestricted service S3 on device A, and restricted attribute C8 and restricted method F3 for restricted service S6 on device B.

[0166] Optionally, the encrypted access token includes at least one of the following:

[0167] Encrypted account-level access keys;

[0168] Encrypted device-level access keys;

[0169] Encrypted service-level access tokens;

[0170] Encrypted attribute-level access tokens.

[0171] For example, during the token issuance process, the first device may receive one or more of the following: encrypted account-level access tokens, encrypted device-level access tokens, encrypted service-level access tokens, and encrypted attribute-level access tokens issued by the first cloud or configuration device. The permission scope of the access tokens at different encryption levels may differ. Based on the permission scope required by the first device, it may receive one or more access tokens corresponding to that permission scope from the first cloud or configuration device.

[0172] In this embodiment of the application, more granular access permissions can be securely controlled by encrypting access tokens at at least one level.

[0173] Optionally, the method further includes:

[0174] The first device receives the access key from the first cloud.

[0175] For example, a first cloud can send its own access key to one or more first devices. Each device's access key can be unique. The access key can be a symmetric key or an asymmetric key. In the case of an asymmetric key, the public key can be stored in the cloud, and the corresponding private key can be pre-installed in the first device; alternatively, the public and private keys can be generated when the first device joins the network or accesses the cloud for the first time, with the private key stored internally and the public key uploaded to the cloud. The first cloud can obtain the corresponding access key based on the information of each first device requiring a token. Then, it uses the obtained access key of the first device to encrypt one or more of the following: account-level access token, device-level access token, service-level access token, and attribute-level access token to be issued to the first device. Then, the first cloud can directly or through a configured device, such as a mobile application, issue one or more of the following: encrypted account-level access token, encrypted device-level access token, encrypted service-level access token, and encrypted attribute-level access token to each first device.

[0176] Optionally, in the method of issuing tokens through a configuration device, the first device receiving the encrypted access token includes: the first device receiving the encrypted access token from the configuration device, wherein the encrypted access token is received by the configuration device from the first cloud, and the encrypted access token is obtained by the first cloud encrypting an access token of at least one level using the access key.

[0177] Optionally, in the method of directly issuing tokens from the first cloud, the first device receiving the encrypted access token includes: the first device receiving the encrypted access token from the first cloud, wherein the encrypted access token is obtained by the first cloud encrypting an access token of at least one level using the access key.

[0178] For example, the first device or configuration device can send a token issuance request to the first cloud. The first cloud can obtain the access key corresponding to the controlled device identifier and use the obtained access key to encrypt the device-level access token of the controlled device generated by the first cloud. Subsequently, the first device can receive the encrypted access token from the first cloud or configuration device. For example, the first cloud sends the encrypted access token to the configuration device, and the configuration device issues the encrypted token from the first cloud to the first device.

[0179] Optionally, the token issuance request may include one of the following:

[0180] The list of controlled device identifiers; the token issuance request is used to request a device-level access token.

[0181] The controlled device identifier and service name list, the token issuance request is used to request a service-level access token;

[0182] The controlled device identifier, service name, and attribute-related information are used to request an attribute-level access token.

[0183] Optionally, the attribute-related information includes at least one of the following: a list of attribute names, a list of read, write, add, delete, or modify methods corresponding to the attribute, and a list of event names.

[0184] Optionally, the token issuance request may also include a list of master device identifiers.

[0185] Optionally, during the token sharing process, the first device receives an encrypted access token, including: the first device receives the encrypted access token from the first cloud, wherein the encrypted access token is obtained by the first cloud encrypting at least one level of access token that the second device needs to share using the access key.

[0186] For example, an access token for a second device can be shared with a first device via a cloud platform. Both the first and second devices are connected to a first cloud platform. The second device needs to share at least one of the following access tokens: account-level, device-level, or attribute-level. The second device can send information about the at least one level of access token to be shared, along with information about the first device, to the first cloud platform via a token sharing request. The first cloud platform obtains the access key corresponding to the first device's information, and the access token corresponding to the information about the at least one level of access token to be shared. The first cloud platform encrypts the obtained access token using the obtained access key. Then, the first cloud platform can send the encrypted access token to the first device based on the first device's information. Alternatively, the first cloud platform can directly send the encrypted access token to the second device, which then sends the encrypted access token to the first device. The second device can decrypt the encrypted access token using its own access key, thereby achieving secure token sharing.

[0187] Optionally, during the token sharing process, the first device receives an encrypted access token, including: the first device receives the encrypted access token from the first cloud, wherein the encrypted access token is obtained by the first cloud using the access key to perform a second encryption on the first encrypted access token, and the first encrypted access token is obtained by the first cloud using a temporary key to perform a first encryption on the access token of at least one level that the second device needs to share.

[0188] For example, access tokens for a second device can be shared between two cloud providers. The first device connects to a first cloud, and the second device connects to a second cloud; the first and second clouds can interact. The second device needs to share at least one of the following access tokens with the first device: account-level, device-level, or attribute-level. Double encryption can be used in this case.

[0189] Specifically, the second device can send a temporary key, information about at least one level of access token to be shared, and information about the first device to the second cloud via a token sharing request. The second cloud can also generate its own temporary key; in this case, the token sharing request may not include the temporary key. The second cloud obtains the access token corresponding to the information about at least one level of access token to be shared, i.e., the access token to be shared. It can then encrypt the access token to be shared using the temporary key to obtain a first encrypted access token. The second cloud then sends the first encrypted access token and the first device's information to the first cloud. The first cloud obtains the access key corresponding to the first device's information, i.e., the first device's access key. The first cloud uses the first device's access key to encrypt the first encrypted access token, obtaining a second encrypted access token.

[0190] Then, the first cloud can send a second encrypted access token to the first device based on the information of the first device. Alternatively, the first cloud can directly send the second encrypted access token to the second device, which then sends the second encrypted access token back to the first device. The second device can use a temporary key and its own access key to decrypt the encrypted access token, thereby achieving secure token sharing. The second device can obtain the temporary key in several ways. For example, it can receive the temporary key from the first device and / or the second cloud. Other methods include obtaining the temporary key through scanning, verbal communication, etc.

[0191] Optionally, during the token update process, the method further includes:

[0192] The first device receives an encrypted update message, which is obtained by encrypting information about the access token of at least one level that needs to be updated and the content that needs to be updated using the access key;

[0193] The first device uses the access key to decrypt the update message, obtaining information about the access token of at least one level that needs to be updated and the content that needs to be updated;

[0194] Based on the content that needs to be updated, the first device updates the access token corresponding to the information of at least one level of access token that needs to be updated.

[0195] Optionally, during the token update process, the configuration device can forward an encrypted update message to the first device. Specifically, the first device receiving the encrypted update message includes: the first device receiving the encrypted update message from the configuration device, the encrypted update message being received by the configuration device from the first cloud, and the encrypted update message being encrypted in the first cloud.

[0196] Optionally, during the token update process, an encrypted update message can be sent from the first cloud to the first device. Specifically, the first device receives the encrypted update message, which includes the first device receiving the encrypted update message from the first cloud, wherein the encrypted update message is encrypted on the first cloud.

[0197] Optionally, the information to be updated may include the validity period, permission scope, etc. of one or more tokens. One or more access tokens can be updated at once.

[0198] For example, a user can configure their device to send an identifier of a specific level of access token that needs updating, along with the content to be updated, to a first cloud platform. After the first cloud platform updates the access token, it can send an encrypted update message to a first device, such as an IoT device. This encrypted update message can include the identifier of at least one level of access token to be updated, such as a device-level access token, and the content to be updated. Upon receiving this encrypted update message, the IoT device modifies the content to be updated in the access token corresponding to the identifier of the updated device-level access token locally.

[0199] For example, a user can send the identifier of a specific access token level that needs updating and the content to be updated to the first cloud via a configuration device. After the first cloud updates the access token, it can send an encrypted update message to the configuration device. This encrypted update message can include the identifier of at least one level of access token to be updated, such as a service-level access token, and the content to be updated. The configuration device then sends this encrypted update message to the first device, such as an IoT device. Upon receiving the encrypted update message, the IoT device modifies the content to be updated in the access token corresponding to the identifier of the updated service-level access token locally.

[0200] Optionally, during the token deletion process, the method further includes:

[0201] The first device receives an encrypted deletion message, which is obtained by encrypting information of at least one level of access token to be deleted using the access key;

[0202] The first device uses the access key to decrypt the encrypted deletion message and obtain information about the access token for at least one level that needs to be deleted;

[0203] The first device deletes the corresponding access token based on the information of the access token of at least one level that needs to be deleted.

[0204] Optionally, during the token deletion process, the configuration device can forward an encrypted deletion message to the first device. Specifically, the first device receiving the encrypted deletion message includes: the first device receiving the encrypted deletion message from the configuration device, the encrypted deletion message being received by the configuration device from the first cloud, and the encrypted deletion message being encrypted in the first cloud.

[0205] Optionally, during the token deletion process, an encrypted deletion message can be sent from the first cloud to the first device. Specifically, the first device receiving the encrypted deletion message includes: the first device receiving the encrypted deletion message from the first cloud, wherein the encrypted deletion message is encrypted on the first cloud.

[0206] Optionally, the identifier of at least one level of access token to be deleted can be obtained on the configuration device in response to the user's selection action. One or more access tokens can be deleted at a time.

[0207] For example, a user can configure the device to send the identifier of at least one level of access token, such as a service-level token, to a first cloud platform for deletion. After the first cloud platform deletes the access token corresponding to the identifier, it can obtain the access keys of all first devices, such as IoT devices, associated with that access token. The identifier of the deleted access token is then encrypted using the access keys of each first device to obtain encrypted deletion information. The first cloud platform then sends this encrypted deletion information to each first device to notify them of the deleted access token identifier.

[0208] For example, a user can send the identifier of at least one level of access token to be deleted, such as an attribute-level token, to the first cloud via a configuration device. After the first cloud deletes the access token corresponding to the identifier, it can obtain the access keys of all first devices (e.g., IIoT devices) associated with that access token. The identifier of the deleted access token is then encrypted using the access keys of each first device to obtain encrypted deletion information. The first cloud can then send this encrypted deletion information to each of the involved first devices via the configuration device to notify them of the deleted access token identifier.

[0209] In this embodiment of the application, by using an access key to encrypt the access token of at least one level of a multi-level access token, the system can securely issue, update, delete, or share multi-level access tokens locally, thereby improving system security.

[0210] Figure 4This is a schematic flowchart of an access token processing method 40 according to another embodiment of this application. This method can optionally be applied to... Figure 1 The device model shown is not limited to this. The method includes at least a portion of the following.

[0211] S410, The configuration device receives an encrypted access token from the first cloud, the encrypted access token being obtained by the first cloud encrypting an access token of at least one level using the access key of the first device.

[0212] S420, The configuration device sends the encrypted access token to the first device.

[0213] Optionally, the encrypted access token includes at least one of the following:

[0214] Encrypted account-level access keys;

[0215] Encrypted device-level access keys;

[0216] Encrypted service-level access tokens;

[0217] Encrypted attribute-level access tokens.

[0218] Optionally, the method further includes:

[0219] The configured device sends a token issuance request to the first cloud to request an access token for at least one level.

[0220] Optionally, the token issuance request includes one of the following:

[0221] The list of controlled device identifiers; the token issuance request is used to request a device-level access token.

[0222] The controlled device identifier and service name list, the token issuance request is used to request a service-level access token;

[0223] The controlled device identifier, service name, and attribute-related information are used to request an attribute-level access token.

[0224] Optionally, the attribute-related information includes at least one of the following: a list of attribute names, a list of read, write, add, delete, or modify methods corresponding to the attribute, and a list of event names.

[0225] Optionally, the token issuance request may also include a list of master device identifiers.

[0226] For example, if the first device needs to request a device-level access token, and the first device is an IoT device, the IoT device can directly send a token issuance request to the first cloud, or it can send a token issuance request to the first cloud through a configuration device. The first cloud can obtain the access key corresponding to the controlled device identifier and use the obtained access key to encrypt the device-level access token of the controlled device generated by the first cloud.

[0227] For example, if the first device needs to request a service-level access token, and the first device is an IoT device, the IoT device can send a token issuance request, including the controlled device identifier and a list of service names, to the first cloud through its configuration. The first cloud can obtain the access key corresponding to the controlled device identifier and use the obtained access identifier to encrypt the service-level access token for the controlled device generated by the first cloud.

[0228] For example, if the first device needs to request an attribute-level access token, and the first device is an IoT device, the IoT device can send a token issuance request to the first cloud, including the controlled device identifier, service name, and attribute-related information, through the configuration device. The first cloud can obtain the access key corresponding to the controlled device identifier and use the obtained access identifier to encrypt the attribute-level access token of the controlled device generated by the first cloud.

[0229] Subsequently, the encrypted token can be sent directly from the first cloud to the first device, or the encrypted token from the first cloud can be sent from the configuration device to the first device.

[0230] Optionally, the method further includes:

[0231] The configured device receives an encrypted update message from the first cloud, which is obtained by the first cloud using the access key to encrypt information of at least one level of access token that needs to be updated and the content that needs to be updated.

[0232] The configured device sends the encrypted update message to the first device.

[0233] Optionally, the method further includes:

[0234] The configured device receives an encrypted deletion message from the first cloud, which is obtained by the first cloud encrypting information of at least one level of access token to be deleted using the access key;

[0235] The configured device sends the encrypted deletion message to the first device.

[0236] For a detailed explanation and example of the configuration device execution method 40 in this embodiment, please refer to the relevant description of the configuration device in the above method 30. For the sake of brevity, it will not be repeated here.

[0237] Figure 5 This is a schematic flowchart of an access token processing method 50 according to another embodiment of this application. The method can optionally be applied to... Figure 1 The device model shown is not limited to this. The method includes at least a portion of the following.

[0238] S510, The first cloud uses the access key of the first device to encrypt the access token at least one level;

[0239] S520, the first cloud sends an encrypted access token.

[0240] Optionally, the encrypted access token includes at least one of the following:

[0241] Encrypted account-level access keys;

[0242] Encrypted device-level access keys;

[0243] Encrypted service-level access tokens;

[0244] Encrypted attribute-level access tokens.

[0245] Optionally, the first cloud sends an encrypted access token, including:

[0246] The first cloud sends the encrypted access token to the configuration device, and the configuration device then sends the encrypted access token back to the first device.

[0247] Optionally, the first cloud sends an encrypted access token, including:

[0248] The first cloud sends an encrypted access token to the first device.

[0249] Optionally, the method further includes:

[0250] The first cloud receives information from the second device regarding at least one level of access token that needs to be shared, as well as information from the first device.

[0251] Optionally, the first cloud uses the access key of the first device to encrypt the access token at at least one level, including:

[0252] The first cloud encrypts the access token of at least one level that needs to be shared based on the access key corresponding to the information of the first device.

[0253] Optionally, the method further includes:

[0254] The first cloud receives a first encrypted access token and information from the first device from the second cloud. The first encrypted access token is obtained by the second cloud using a temporary key to first encrypt the access token of at least one level that needs to be shared.

[0255] Optionally, the first cloud uses the access key of the first device to encrypt the access token at at least one level, including:

[0256] The first cloud platform encrypts the first encrypted access token using the access key corresponding to the information of the first device, thus obtaining a second encrypted access token.

[0257] Optionally, the first cloud sends an encrypted access token, including:

[0258] The first cloud sends the second encrypted access token.

[0259] Optionally, the first cloud sends the second encrypted access token, including:

[0260] The first cloud sends the second encrypted access token to the second device through the second cloud, and the second device sends the second encrypted access token to the first device.

[0261] Optionally, the first cloud sends the second encrypted access token, including:

[0262] The first cloud sends the second encrypted access token to the first device.

[0263] Optionally, the method further includes:

[0264] The first cloud sends the access key to at least one of the first devices.

[0265] Optionally, the method further includes:

[0266] The first cloud receives a token issuance request from the configuration device for requesting an access token for at least one level.

[0267] Optionally, the token issuance request includes one of the following:

[0268] The list of controlled device identifiers; the token issuance request is used to request a device-level access token.

[0269] The controlled device identifier and service name list, the token issuance request is used to request a service-level access token;

[0270] The controlled device identifier, service name, and attribute-related information are used to request an attribute-level access token.

[0271] Optionally, the attribute-related information includes at least one of the following: a list of attribute names, a list of read, write, add, delete, or modify methods corresponding to the attribute, and a list of event names.

[0272] Optionally, the token issuance request may also include a list of master device identifiers.

[0273] Optionally, the method further includes:

[0274] The first cloud uses the access key to encrypt the information of the access token that needs to be updated at least one level and the content that needs to be updated, and obtains an encrypted update message;

[0275] The first cloud sends the encrypted update message.

[0276] Optionally, the first cloud sends the encrypted update message, including:

[0277] The first cloud sends the encrypted update message to the configuration device, and the configuration device then sends the encrypted update message back to the first device.

[0278] Optionally, the first cloud sends the encrypted update message, including:

[0279] The first cloud sends the encrypted update message to the first device.

[0280] Optionally, the method further includes:

[0281] The first cloud platform uses the access key to encrypt information about the access tokens of at least one level that need to be deleted, resulting in an encrypted deletion message.

[0282] The first cloud server sends the encrypted deletion message.

[0283] Optionally, the first cloud sends the encrypted deletion message, including:

[0284] The first cloud sends the encrypted deletion message to the configuration device, and the configuration device then sends the encrypted deletion message back to the first device.

[0285] Optionally, the first cloud sends the encrypted deletion message, including:

[0286] The first cloud sends the encrypted deletion message to the first device.

[0287] For a detailed explanation and example of the first cloud execution method 50 in this embodiment, please refer to the relevant descriptions of the first cloud in methods 30 and 40 above. For the sake of brevity, they will not be repeated here.

[0288] Figure 6This is a schematic flowchart of an access token processing method 60 according to another embodiment of this application. The method can optionally be applied to... Figure 1 The device model shown is not limited to this. The method includes at least a portion of the following.

[0289] S610, the second cloud receives a token sharing request from the second device, the token sharing request including information about at least one level of access token that needs to be shared;

[0290] S620. The second cloud encrypts the access token corresponding to the information of the access token at least one level.

[0291] S630, the second cloud sends an encrypted access token.

[0292] Optionally, the token sharing request may also include information about the first device, and the second cloud may encrypt the access token corresponding to the information of the access token at least one level, including:

[0293] The second cloud encrypts the access token corresponding to the information of the first device based on the access key corresponding to the information of the access token at least one level.

[0294] Optionally, the second cloud encrypts the access token corresponding to the information of the access token at least one level, including:

[0295] The second cloud uses a temporary key to encrypt the access token corresponding to the information of the access token at least one level for the first time.

[0296] Optionally, the temporary key may be included in the token sharing request, or the temporary key may be generated in the second cloud.

[0297] Optionally, the second cloud sends an encrypted access token, including:

[0298] The second cloud sends the first encrypted access token and information about the first device to the first cloud.

[0299] Optionally, the method further includes:

[0300] The second cloud receives a second encrypted access token from the first cloud. This second encrypted access token is obtained by the first cloud using the access key corresponding to the information of the first device to encrypt the first encrypted access token a second time.

[0301] Optionally, the second cloud sends an encrypted access token, which may also include at least one of the following:

[0302] The second cloud sends the second encrypted access token to the second device, and the second device sends the second encrypted access token and the temporary key to the first device;

[0303] The second cloud sends the second encrypted access token and the temporary key to the first device.

[0304] For a detailed explanation and example of the second cloud execution method 60 in this embodiment, please refer to the relevant descriptions of the second cloud in methods 30, 40, and 50 above. For the sake of brevity, they will not be repeated here.

[0305] Figure 7 This is a schematic flowchart of an access token processing method 70 according to another embodiment of this application. This method can optionally be applied to... Figure 1 The device model shown is not limited to this. The method includes at least a portion of the following.

[0306] S710, the second device sends a token sharing request, which includes information about at least one level of access token to be shared and information about the first device;

[0307] S720, The second device receives an encrypted access token, which is obtained by encrypting at least one level of access token to be shared using the access key corresponding to the information of the first device.

[0308] S730, the second device sends the encrypted access token.

[0309] Optionally, the second device sends a token sharing request, including:

[0310] The second device sends a token sharing request to the first cloud.

[0311] Optionally, the second device receives an encrypted access token, including:

[0312] The second device receives the encrypted access token from the first cloud, which is obtained by the first cloud encrypting at least one level of access token to be shared using the access key corresponding to the information of the first device.

[0313] Optionally, the second device sends the encrypted access token, which includes at least one of the following:

[0314] The second device sends the encrypted access token to the first device;

[0315] The second device sends the encrypted access token to the first device via the second cloud;

[0316] The second device sends the encrypted access token to the first device through the second cloud and the first cloud.

[0317] Optionally, the second device sends a token sharing request, including:

[0318] The second device sends a token sharing request to the second cloud.

[0319] Optionally, the second device receives an encrypted access token, including:

[0320] The second device receives a second encrypted access token from the second cloud. This second encrypted access token is obtained by encrypting the access token of at least one level that needs to be shared using a temporary key and the access key corresponding to the information of the first device.

[0321] Optionally, the temporary key may be included in the token sharing request sent by the second device to the second cloud, or the temporary key may be generated in the second cloud.

[0322] Optionally, the second device sends the encrypted access token, including:

[0323] The second device sends the second encrypted access token and the temporary key.

[0324] Optionally, the second device sends the second encrypted access token and the temporary key, including at least one of the following:

[0325] The second device sends the second encrypted access token and the temporary key to the first device;

[0326] The second device sends the second encrypted access token and the temporary key to the first device through the second cloud;

[0327] The second device sends the second encrypted access token and the temporary key to the first device through the second cloud and the first cloud.

[0328] For a detailed explanation and example of the second device execution method 70 in this embodiment, please refer to the relevant descriptions of the second device in the above methods 30, 40, 50 and 60. For the sake of brevity, they will not be repeated here.

[0329] 1.1 Example of issuing tokens

[0330] In this example, the first device is an IoT device (application terminal), the first cloud is the access cloud, and the configured device can include a mobile application. The access cloud encrypts the token (including the permission scope) to be issued to each application terminal using the device's unique access key (PSK), and then passes it to a device with user account login capabilities (such as a mobile application or smart TV) to issue it to each application terminal. The specific process is as follows, please refer to [link / reference]. Figure 8 :

[0331] S101 and S102. Configure device network access. Users can configure IoT (Internet of Things) devices to access the network through configuration tools such as mobile applications.

[0332] S103. If an IoT device is joining the network for the first time, a new access token can be generated in the access cloud. If the IoT device is joining the network again, it can use the already generated access token.

[0333] S104. If there is no account-level token in the access cloud, an account-level token can be generated and saved; if there is an account-level token in the access cloud, then execute S15 directly to issue the account-level token to the device. Generally speaking, when a device first joins the network, there is no account-level token in the access cloud; when the device joins the network again, there may be an access token in the access cloud.

[0334] S105. Access the cloud and issue an account-level token to the device.

[0335] S106. Device discovery. For example, discovering IoT devices through a mobile application. IoT devices can be controlling devices and / or controlled devices.

[0336] S107. The user selects one or more controlled devices from the discovered IoT devices through a mobile application, and / or selects one or more master devices.

[0337] S108. The mobile application sends the selected list of controlled device IDs and / or the list of master device IDs to the access cloud.

[0338] S109. The cloud generates a device-level token for the selected controlled device and saves the token along with the corresponding list of controlled device IDs and the list of master device IDs.

[0339] S110. The access cloud will encrypt the token (including the permission scope) using the access key (PSK) of each controlled device and each master control device.

[0340] S111. Access the cloud and return the device ID and a list of encrypted device-level tokens corresponding to the device ID to the mobile application.

[0341] S112. The mobile application sends encrypted device-level tokens to each selected controlled device, and / or sends an encrypted list of controlled device IDs and encrypted device-level tokens to each master control device.

[0342] S113. Each device decrypts the token using its own access key. For example, upon receiving an encrypted device-level token, each controlled device decrypts the encrypted device-level token using its own access key. Similarly, upon receiving an encrypted device-level token, each master device decrypts the encrypted device-level token using its own access key.

[0343] S114. Discovering devices and services. For example, a mobile application discovers services in IoT devices. In this embodiment, a service may also be referred to as a device service.

[0344] S115. The user selects the controlled device and some of its services through a mobile application, and selects one or more master control devices.

[0345] S116. The mobile application sends the selected list of controlled device IDs and service names to the access cloud, and / or sends the selected list of master control device IDs to the access cloud.

[0346] S117. The cloud generates a service-level token for the controlled device and saves the token along with at least one of the following: the controlled device ID, the list of device service names, and the list of master device IDs.

[0347] S118. Encrypt the token (including the scope of permissions) using the access keys (PSK) of the controlled device and each master control device.

[0348] S119. Access Cloud returns a list of device IDs and the encrypted service-level tokens corresponding to those device IDs to the mobile application.

[0349] S120. The mobile application sends an encrypted list of service names and an encrypted service level token to the controlled device, and / or sends an encrypted list of service names, a controlled device ID, and an encrypted service level token to each master control device.

[0350] S121. The devices decrypt using their respective access keys. For example, upon receiving an encrypted service-level token, each controlled device decrypts the encrypted service-level token using its own access key. Similarly, upon receiving an encrypted service-level token, each master device decrypts the encrypted service-level token using its own access key.

[0351] S122. Discovering devices, services, attributes, methods, and events. For example, discovering IoT devices, services within the devices, and at least one of the attributes, methods, and events within the services via a mobile application. In embodiments of this application, attributes may also be referred to as device attributes.

[0352] S123. The user selects the controlled device and some attributes (distinguishing between read and write) / methods / events of the device through the mobile application, and / or selects one or more master control devices.

[0353] S124. The mobile application sends a list of controlled device IDs, service names, attributes (distinguishing between read and write) / methods / event names, and / or a list of master device IDs to the access cloud.

[0354] S125. The cloud generates an attribute-level token for the controlled device, and saves the token along with the corresponding controlled device ID, service name, list of attributes (distinguishing between read and write) / methods / event names, and list of master device IDs.

[0355] S126. The access cloud will encrypt the token (including the scope of permissions) using the access keys (PSK) of the controlled device and each master control device.

[0356] S127. Access the cloud and return the device ID and a list of encrypted attribute-level tokens corresponding to the device ID to the mobile application.

[0357] S128. The mobile application sends an encrypted list of service names and device attributes (distinguishing between read and write) / methods / event names and an encrypted attribute-level token to the controlled device, and / or sends an encrypted controlled device ID, service name and list of attributes (distinguishing between read and write) / methods / event names and an encrypted attribute-level token to each master control device.

[0358] S129. Each device decrypts the token using its own access key. For example, upon receiving an encrypted attribute-level token, each controlled device decrypts the encrypted attribute-level token using its own access key. Similarly, upon receiving an encrypted attribute-level token, each master device decrypts the encrypted attribute-level token using its own access key.

[0359] In this example, the steps of issuing access tokens at the account level, device level, service level, and attribute level have no time limit and do not need to be executed in all order. You can execute the steps of issuing access tokens at any one or more levels according to specific needs.

[0360] In another example, encrypted access tokens can be issued directly from the cloud to IoT devices.

[0361] For example, replace S111 and S112 with: Access the cloud to issue encrypted device-level tokens to each selected controlled device, and / or issue an encrypted list of controlled device IDs and encrypted device-level tokens to each master control device.

[0362] For example, replace S119 and S120 with: sending an encrypted list of service names and an encrypted service level token to the controlled device via the cloud, and / or sending an encrypted list of service names, the controlled device ID, and an encrypted service level token to each master control device.

[0363] For example, replace S127 and S128 with: Access the cloud to send an encrypted service name and device attribute (distinguishing between read and write) / method / event name list and an encrypted attribute-level token to the controlled device, and / or send an encrypted controlled device ID, service name and attribute (distinguishing between read and write) / method / event name list and an encrypted attribute-level token to each master control device.

[0364] By encrypting at least one level of the multi-level access token using an access key, multi-level access tokens can be securely issued locally, enhancing system security. For example, this prevents unauthorized configuration devices, such as mobile applications, from issuing access tokens to application terminals (smart devices). Furthermore, it can further ensure the security of issuing multi-level access tokens to devices via cloud access.

[0365] 1.2 Example of updating tokens

[0366] For example: The updated token information is sent to all devices associated with that token (both the controller and the controlled devices). The specific process is as follows (see below). Figure 9 :

[0367] S201. The mobile application obtains all token information under the account from the access cloud, or obtains relevant token information based on the device ID involved.

[0368] S202. Users can select a token from the tokens displayed in the mobile application and specify the content to be modified, such as modifying at least one of its validity period, permission scope, or token value.

[0369] S203. The mobile application caches the original and modified information of the token.

[0370] S204. The mobile application sends an access token identifier (token ID) and modified content to the access cloud, such as at least one of the modified token validity period, permission scope, and token value.

[0371] S205. Access the cloud and update at least one of the following: the validity period, permission scope, and token value of the corresponding token based on the token ID.

[0372] S206. Cloud update successful. For example, accessing the cloud can send a message to the mobile application that the token has been successfully updated in the cloud.

[0373] S207. The mobile application can send encrypted updated token information to all devices (master device and / or controlled device) involved in the token.

[0374] For example, if a device is removed from the list, the device is notified to delete the token, and the deletion instruction and token ID in the notification message are encrypted using the device's access key.

[0375] For example, if a device is added to the list, a new token is issued to that device, and the token (including the permission scope) in the message is encrypted using the device's access key.

[0376] For example, if the device is already in the original list, then notify the device to update the token information, and use the device's access key to encrypt the token (including the permission scope) in the message.

[0377] In another example, the access cloud can also directly send encrypted updated token IDs to IoT devices. For example, replacing S206 and S207, the access cloud can send encrypted updated token IDs to all devices (master and / or controlled devices) associated with that token.

[0378] In this example, the purpose of the mobile application caching the original token information can include: determining whether a device (master device and / or controlled device) has been removed from or added to the list; and resending the update message when the mobile application fails to update the token (e.g., the device is temporarily offline). Alternatively, the original token information can be cached in the cloud for purposes including: determining whether a device (master device and / or controlled device) has been removed from or added to the list; and resending the update message when the cloud fails to update the token (e.g., the device is temporarily offline).

[0379] By encrypting at least one level of the multi-level access token using an access key, secure local updates of the multi-level access token are achieved, enhancing system security. For example, this prevents unauthorized device configuration, such as mobile applications, from notifying devices to update access tokens. Furthermore, it can further ensure the security of notifying devices to update access tokens via cloud access.

[0380] 1.3 Example of deleting a token

[0381] For example, a device with user account login capabilities (such as a mobile app or smart TV) notifies the application terminal (smart device) to delete the access token. The specific process is as follows, see below. Figure 10 :

[0382] S301. The mobile application obtains all token information under the account from the access cloud, or obtains relevant token information based on the device ID involved.

[0383] S302. Users can select a token from the tokens displayed in the mobile application and request its deletion.

[0384] S303. The mobile application caches the original information of this token.

[0385] S304. The mobile application can send the token ID of the access token that needs to be deleted to the access cloud.

[0386] S305. Access the cloud and delete its token information based on the token ID.

[0387] S306. Deletion successful. The cloud can send a message to the mobile application indicating that the token has been successfully deleted.

[0388] S307. The mobile application sends an encrypted notification to all devices (including the controlling device and / or the controlled device) associated with the token, instructing them to delete the token based on the token ID. During this process, the deletion instruction and the token ID in the notification message are encrypted using the device's access key.

[0389] In another example, the access cloud can also directly send encrypted deletion token IDs to IoT devices. For example, replacing S306 and S307, the access cloud can send encrypted deletion token IDs to all devices (master and / or controlled devices) associated with that token.

[0390] In this example, the purpose of the mobile application caching the original token information can include: resending the deletion message when the mobile application fails to delete the token (e.g., the device is temporarily offline). Alternatively, the original token information can be cached in the cloud, for purposes such as resending the deletion message when deleting the token via the cloud fails (e.g., the device is temporarily offline).

[0391] By encrypting access tokens with access keys, the system can securely delete access tokens locally and set up multi-level access tokens, thereby improving system security.

[0392] 1.4 Example of a shared token

[0393] A device with user account login capability (such as a mobile app or smart TV) shares an access token with another application terminal (smart device) under another account through another device with user account login capability (such as a mobile app or smart TV):

[0394] 1.4.1 Same access cloud

[0395] See Figure 11 The first device includes mobile application B, and the second device includes mobile application A. The cloud is the access cloud (also known as the cloud platform) C1. Mobile application A is the mobile application for user account A, and mobile application B is the mobile application for user account B.

[0396] User account A's mobile application, user account B's mobile application, and devices under those accounts all connect to the same access cloud C1. After user A's mobile application searches for user B's mobile application, it can obtain one or more tokens from access cloud C1, encrypted with B's access key, and send them to B's mobile application, thus enabling B's mobile application to access devices under A's account. A can also request one or more tokens from B's account; B shares its tokens with A using the same method, allowing A's mobile application to access devices under B's account.

[0397] The specific process may include:

[0398] S401. Mobile application B establishes a secure connection with access cloud C1.

[0399] S402. Mobile application A establishes a secure connection with access cloud C1.

[0400] The above S401 and S402 have no timing restrictions; they can be processed in sequence or in parallel.

[0401] S403. Mobile application A discovers mobile application B.

[0402] S404. Mobile application A sends the user ID of mobile application B and the token ID to be shared to the access cloud C1.

[0403] S405. Access Cloud C1 uses B's access key to encrypt the token to be shared. For example, Access Cloud C1 obtains the access key corresponding to the user ID of mobile application B, and obtains the token to be shared corresponding to the token ID. Then, Access Cloud C1 uses the obtained access key of B to encrypt the token to be shared.

[0404] S406. Access cloud C1 returns an encrypted token to mobile application A.

[0405] S407. Mobile application A sends an encrypted token to mobile application B.

[0406] Optionally, access cloud C1 can also directly send an encrypted token to mobile application B.

[0407] S408. Mobile application B uses its own unique access key to decrypt and obtain the token that A wants to share.

[0408] 1.4.2 Different Cloud Access Methods

[0409] See Figure 12 The first device includes mobile application B, and the first cloud is access cloud (also known as cloud platform) C2. The second device includes mobile application A, and the second cloud is access cloud (also known as cloud platform) C1. Mobile application A is the mobile application for user account A, and mobile application B is the mobile application for user account B.

[0410] User account A and device D1 connect to access cloud C1. User account B and device D2 connect to access cloud C2. After user A uses the mobile application of account A (hereinafter referred to as mobile application A) to search for the mobile application of account B (hereinafter referred to as mobile application A), mobile application A generates a temporary key K. Then, it requests cloud platform C1 to encrypt one or more tokens under account A using mobile application A's temporary key K and send them to access cloud C2. C2 encrypts the encrypted token again using mobile application B's access key and returns it to mobile application A through C1. Mobile application A sends the returned encrypted token and temporary key K together to mobile application B. Mobile application B uses its own access key and the aforementioned temporary key K to decrypt and obtain the token, thus enabling mobile application B to also access devices under account A. Mobile application A can also request one or more tokens under account B from mobile application B. Mobile application B uses the same method as described above to share account B's tokens with mobile application A, thus enabling user A's mobile application to also access devices under account B.

[0411] The aforementioned temporary key K can also be generated by C1 and returned to A along with the encrypted token.

[0412] The aforementioned temporary key K can be sent from mobile application A to mobile application B using in-band methods, or it can be sent using out-of-band methods (such as scanning a code, speaking, etc.).

[0413] The specific process may include:

[0414] S501. Mobile application B establishes a secure connection with access cloud C2.

[0415] S502. Mobile application A establishes a secure connection with access cloud C1.

[0416] S503. Mobile application A discovers mobile application B.

[0417] S504. Mobile application A generates temporary key K.

[0418] S505. Mobile application A sends a temporary key K, platform information and user ID of mobile application B, and the token ID to be shared to the access cloud C1.

[0419] S506. Access Cloud C1 uses the first encryption algorithm and temporary key K to encrypt the token to be shared.

[0420] Alternatively, if a temporary key is generated in C1, S504 can be omitted, and in S505, mobile application A does not need to send the temporary key K to access cloud C1.

[0421] S507. Access Cloud C1 forwards an encrypted token to Access Cloud C2 based on the user account association (such as the platform information and user ID of mobile application B).

[0422] S508. Accessing Cloud C2 uses a second encryption algorithm to re-encrypt the previously encrypted token using B's access key.

[0423] S509. Access Cloud C2 returns a double-encrypted token to Access Cloud C1.

[0424] S510. Access cloud C1 returns a double-encrypted token to mobile application A.

[0425] S511. Mobile application A sends a temporary key K and a double-encrypted token to mobile application B.

[0426] S512. Mobile application B first uses its own unique access key to decrypt, and then uses the temporary key K to decrypt, to obtain the token that mobile application A wants to share.

[0427] Optionally, the access cloud C2 can also directly send a double-encrypted token to the mobile application B. In this case, S509 and S510 are not required, and in S511, the mobile application A only sends the temporary key K to the mobile application B. Alternatively, S509, S510, and S511 are not required, and other methods are used to inform the mobile application B of the temporary key K.

[0428] By encrypting access tokens with access keys, multi-level access tokens can be set up for secure local sharing of access tokens, thereby improving system security.

[0429] Figure 13 This is a schematic block diagram of a first device 300 according to an embodiment of this application. The first device 300 may include:

[0430] The receiving unit 310 is used to receive an encrypted access token, which is obtained by encrypting an access token of at least one level using the access key of the first device;

[0431] The decryption unit 320 is used to decrypt the encrypted access token using the access key.

[0432] Optionally, the encrypted access token includes at least one of the following:

[0433] Encrypted account-level access keys;

[0434] Encrypted device-level access keys;

[0435] Encrypted service-level access tokens;

[0436] Encrypted attribute-level access tokens.

[0437] Optionally, the receiving unit 310 is configured to receive the encrypted access token from the configuration device, wherein the encrypted access token is received by the configuration device from the first cloud, and the encrypted access token is obtained by the first cloud encrypting an access token of at least one level using the access key.

[0438] Optionally, the receiving unit 310 is used to receive the encrypted access token from the first cloud, wherein the encrypted access token is obtained by the first cloud encrypting an access token of at least one level using the access key.

[0439] Optionally, the receiving unit 310 is used to receive the encrypted access token from the first cloud, wherein the encrypted access token is obtained by the first cloud encrypting at least one level of access token that the second device needs to share using the access key.

[0440] Optionally, the receiving unit 310 is used to receive the encrypted access token from the first cloud, wherein the encrypted access token is obtained by the first cloud using the access key to perform a second encryption on the first encrypted access token, and the first encrypted access token is obtained by the second cloud receiving the first cloud using a temporary key to perform a first encryption on the access token of at least one level that the second device needs to share.

[0441] Optionally, the receiving unit 310 is also configured to receive the access key from the first cloud.

[0442] Optionally, such as Figure 14 As shown, the receiving unit 310 is also used to receive an encrypted update message, which is obtained by encrypting the information of the access token of at least one level that needs to be updated and the content that needs to be updated using the access key;

[0443] The decryption unit 320 is used to decrypt the update message using the access key to obtain information about the access token of at least one level that needs to be updated and the content that needs to be updated.

[0444] The first device 300 also includes an update unit 330, which updates the access token corresponding to the information of at least one level of access token that needs to be updated, based on the content that needs to be updated.

[0445] Optionally, the receiving unit 310 is configured to receive the encrypted update message from the configuration device, the encrypted update message being received by the configuration device from the first cloud, and the encrypted update message being encrypted in the first cloud.

[0446] Optionally, the receiving unit 310 is configured to receive the encrypted update message from the first cloud, wherein the encrypted update message is encrypted on the first cloud.

[0447] Optionally, the receiving unit 310 is further configured to receive an encrypted deletion message, which is obtained by encrypting information of at least one level of access token to be deleted using the access key;

[0448] The decryption unit 320 is used to decrypt the encrypted deletion message using the access key to obtain information about the access token of at least one level that needs to be deleted;

[0449] The first device also includes a deletion unit 340 for deleting the corresponding access token based on information about the access token of at least one level that needs to be deleted.

[0450] Optionally, the receiving unit 310 is configured to receive the encrypted deletion message from the configuration device, wherein the encrypted deletion message is received by the configuration device from the first cloud, and the encrypted deletion message is encrypted in the first cloud.

[0451] Optionally, the receiving unit 310 is used to receive the encrypted deletion message from the first cloud, wherein the encrypted deletion message is encrypted on the first cloud.

[0452] The first device 300 in this embodiment can implement the corresponding functions of the first device in the aforementioned method 30 embodiment. The processes, functions, implementation methods, and beneficial effects of each module (sub-module, unit, or component, etc.) in the first device 300 can be found in the corresponding descriptions in the above method embodiments, and will not be repeated here. It should be noted that the functions described for each module (sub-module, unit, or component, etc.) in the first device 300 of this embodiment can be implemented by different modules (sub-modules, units, or components, etc.) or by the same module (sub-module, unit, or component, etc.).

[0453] Figure 15 This is a schematic block diagram of a configuration device 400 according to an embodiment of the present application. The configuration device 400 may include:

[0454] The receiving unit 410 is used to receive an encrypted access token from the first cloud, which is obtained by the first cloud encrypting an access token of at least one level using the access key of the first device.

[0455] Sending unit 420 is used to send the encrypted access token to the first device.

[0456] Optionally, the encrypted access token includes at least one of the following:

[0457] Encrypted account-level access keys;

[0458] Encrypted device-level access keys;

[0459] Encrypted service-level access tokens;

[0460] Encrypted attribute-level access tokens.

[0461] Optionally, the sending unit 420 is also configured to send a token issuance request to the first cloud for requesting an access token for at least one level.

[0462] Optionally, the token issuance request includes one of the following:

[0463] The list of controlled device identifiers; the token issuance request is used to request a device-level access token.

[0464] The controlled device identifier and service name list, the token issuance request is used to request a service-level access token;

[0465] The controlled device identifier, service name, and attribute-related information are used to request an attribute-level access token.

[0466] Optionally, the attribute-related information includes at least one of the following: a list of attribute names, a list of read, write, add, delete, or modify methods corresponding to the attribute, and a list of event names.

[0467] Optionally, the token issuance request may also include a list of master device identifiers.

[0468] Optionally, the receiving unit 410 is further configured to receive an encrypted update message from the first cloud, wherein the encrypted update message is obtained by the first cloud using the access key to encrypt information of at least one level of access token that needs to be updated and the content that needs to be updated.

[0469] The sending unit 420 is also used to send the encrypted update message to the first device.

[0470] Optionally, the receiving unit 410 is further configured to receive an encrypted deletion message from the first cloud, wherein the encrypted deletion message is obtained by the first cloud encrypting information of at least one level of access token to be deleted using the access key;

[0471] The sending unit 420 is also used to send the encrypted deletion message to the first device.

[0472] The configuration device 400 of this application embodiment can realize the corresponding functions of the configuration device in the aforementioned method 40 embodiment. The processes, functions, implementation methods, and beneficial effects of each module (sub-module, unit, or component, etc.) in the configuration device 400 can be found in the corresponding descriptions in the above method embodiments, and will not be repeated here. It should be noted that the functions described for each module (sub-module, unit, or component, etc.) in the configuration device 400 of the application embodiment can be implemented by different modules (sub-modules, units, or components, etc.) or by the same module (sub-module, unit, or component, etc.).

[0473] Figure 16 This is a schematic block diagram of a first cloud 500 according to an embodiment of this application. The first cloud 500 may include:

[0474] The first encryption unit 511 is used to encrypt an access token of at least one level using the access key of the first device;

[0475] The first sending unit 521 is used to send an encrypted access token.

[0476] Optionally, the encrypted access token includes at least one of the following:

[0477] Encrypted account-level access keys;

[0478] Encrypted device-level access keys;

[0479] Encrypted service-level access tokens;

[0480] Encrypted attribute-level access tokens.

[0481] Optionally, the first sending unit 521 is used to send the encrypted access token to the configuration device, and the configuration device sends the encrypted access token to the first device.

[0482] Optionally, the first sending unit 521 is used to send an encrypted access token to the first device.

[0483] Optionally, such as Figure 17 As shown, the first cloud 500 also includes:

[0484] The first receiving unit 531 is used to receive information from the second device regarding at least one level of access token that needs to be shared, and information from the first device.

[0485] Optionally, the first encryption unit 511 is used to encrypt the access token of at least one level that needs to be shared based on the access key corresponding to the information of the first device.

[0486] Optionally, the first cloud 500 also includes:

[0487] The second receiving unit 532 is used to receive the first encrypted access token and the information of the first device from the second cloud. The first encrypted access token is obtained by the second cloud using a temporary key to encrypt the access token of at least one level that needs to be shared for the first time.

[0488] Optionally, the first encryption unit 511 is used to encrypt the first encrypted access token based on the access key corresponding to the information of the first device to obtain a second encrypted access token.

[0489] Optionally, the first sending unit 521 is used to send the second encrypted access token.

[0490] Optionally, the first sending unit 521 is used to send the second encrypted access token to the second device through the second cloud, and the second device sends the second encrypted access token to the first device.

[0491] Optionally, the first sending unit 521 is used to send the second encrypted access token to the first device.

[0492] Optionally, the first cloud 500 also includes:

[0493] The second sending unit 522 is used to send the access key to at least one of the first devices.

[0494] Optionally, the first cloud 500 also includes:

[0495] The third receiving unit 533 is used to receive a token issuance request from the configuration device for requesting an access token of at least one level.

[0496] Optionally, the token issuance request includes one of the following:

[0497] The list of controlled device identifiers; the token issuance request is used to request a device-level access token.

[0498] The controlled device identifier and service name list, the token issuance request is used to request a service-level access token;

[0499] The controlled device identifier, service name, and attribute-related information are used to request an attribute-level access token.

[0500] Optionally, the attribute-related information includes at least one of the following: a list of attribute names, a list of read, write, add, delete, or modify methods corresponding to the attribute, and a list of event names.

[0501] Optionally, the token issuance request may also include a list of master device identifiers.

[0502] Optionally, the first cloud 500 also includes:

[0503] The second encryption unit 512 is used to encrypt the information of the access token of at least one level that needs to be updated and the content that needs to be updated using the access key, so as to obtain an encrypted update message.

[0504] The third sending unit 523 is used to send the encrypted update message.

[0505] Optionally, the third sending unit 523 is used to send the encrypted update message to the configuration device, and the configuration device sends the encrypted update message to the first device.

[0506] Optionally, the third sending unit 523 is used to send the encrypted update message to the first device.

[0507] Optionally, the first cloud 500 also includes:

[0508] The third encryption unit 513 is used to encrypt the information of the access token of at least one level that needs to be deleted using the access key to obtain an encrypted deletion message;

[0509] The fourth sending unit 524 is used to send the encrypted deletion message.

[0510] Optionally, the fourth sending unit 524 is used to send the encrypted deletion message to the configuration device, and the configuration device sends the encrypted deletion message to the first device.

[0511] Optionally, the fourth sending unit 524 is used to send the encrypted deletion message to the first device.

[0512] The first cloud 500 in this application embodiment can realize the corresponding functions of the first cloud in the aforementioned method 50 embodiment. The processes, functions, implementation methods, and beneficial effects of each module (sub-module, unit, or component, etc.) in the first cloud 500 can be found in the corresponding descriptions in the above method embodiments, and will not be repeated here. It should be noted that the functions described for each module (sub-module, unit, or component, etc.) in the first cloud 500 of this application embodiment can be implemented by different modules (sub-modules, units, or components, etc.) or by the same module (sub-module, unit, or component, etc.).

[0513] Figure 18 This is a schematic block diagram of a second cloud 600 according to an embodiment of this application. The second cloud 600 may include:

[0514] The receiving unit 610 is configured to receive a token sharing request from the second device, the token sharing request including information about at least one level of access token that needs to be shared;

[0515] The encryption unit 620 is used to encrypt the access token corresponding to the information of the access token at least one level;

[0516] Sending unit 630 is used to send encrypted access tokens.

[0517] Optionally, the token sharing request may also include information about the first device, and the encryption unit is used to encrypt the access token corresponding to the information of the at least one level of access token based on the access key corresponding to the information of the first device.

[0518] Optionally, the encryption unit 620 is used to perform a first encryption of the access token corresponding to the information of the access token at least one level using a temporary key.

[0519] Optionally, the temporary key may be included in the token sharing request, or the temporary key may be generated in the second cloud.

[0520] Optionally, the sending unit 630 is used to send the first encrypted access token and information of the first device to the first cloud.

[0521] Optionally, the receiving unit 610 is further configured to receive a second encrypted access token from the first cloud, which is obtained by the first cloud using the access key corresponding to the information of the first device to encrypt the first encrypted access token a second time.

[0522] Optionally, the transmitting unit 630 is also used for at least one of the following:

[0523] The second encrypted access token is sent to the second device, and the second device sends the second encrypted access token and the temporary key to the first device.

[0524] Send the second encrypted access token and the temporary key to the first device.

[0525] The second cloud 600 in this embodiment can implement the corresponding functions of the second cloud in the aforementioned method 60 embodiment. The processes, functions, implementation methods, and beneficial effects of each module (sub-module, unit, or component, etc.) in the second cloud 600 can be found in the corresponding descriptions in the above method embodiments, and will not be repeated here. It should be noted that the functions described for each module (sub-module, unit, or component, etc.) in the second cloud 600 of this embodiment can be implemented by different modules (sub-modules, units, or components, etc.) or by the same module (sub-module, unit, or component, etc.).

[0526] Figure 19 This is a schematic block diagram of a second device 700 according to an embodiment of this application. The second device 700 may include:

[0527] The first sending unit 710 is used to send a token sharing request, which includes information about at least one level of access token to be shared and information about the first device.

[0528] The receiving unit 720 is used to receive an encrypted access token, which is obtained by encrypting an access token of at least one level that needs to be shared using an access key corresponding to the information of the first device.

[0529] The second sending unit 730 is used to send the encrypted access token.

[0530] Optionally, the first sending unit 710 is used to send a token sharing request to the first cloud.

[0531] Optionally, the receiving unit 720 is used to receive the encrypted access token from the first cloud, which is obtained by the first cloud encrypting the access token of at least one level that needs to be shared using the access key corresponding to the information of the first device.

[0532] Optionally, the second transmitting unit 730 is configured to perform at least one of the following:

[0533] Send the encrypted access token to the first device;

[0534] The encrypted access token is sent to the first device via the second cloud;

[0535] The encrypted access token is sent to the first device via the second cloud and the first cloud.

[0536] Optionally, the first sending unit 710 is used to send a token sharing request to the second cloud.

[0537] Optionally, the receiving unit 720 is used to receive a second encrypted access token from the second cloud, which is obtained by encrypting the access token of at least one level that needs to be shared using a temporary key and the access key corresponding to the information of the first device.

[0538] Optionally, the temporary key may be included in the token sharing request sent by the second device to the second cloud, or the temporary key may be generated in the second cloud.

[0539] Optionally, the second sending unit 730 is used to send the second encrypted access token and the temporary key.

[0540] Optionally, the second transmitting unit 730 is configured to perform at least one of the following:

[0541] Send the second encrypted access token and the temporary key to the first device;

[0542] The second encrypted access token and the temporary key are sent to the first device via the second cloud.

[0543] The second encrypted access token and the temporary key are sent to the first device through the second cloud and the first cloud.

[0544] The second device 700 in this application embodiment can implement the corresponding functions of the second device in the aforementioned method 70 embodiment. The processes, functions, implementation methods, and beneficial effects of each module (sub-module, unit, or component, etc.) in the second device 700 can be found in the corresponding descriptions in the above method embodiments, and will not be repeated here. It should be noted that the functions described for each module (sub-module, unit, or component, etc.) in the second device 700 of this application embodiment can be implemented by different modules (sub-modules, units, or components, etc.) or by the same module (sub-module, unit, or component, etc.).

[0545] Figure 20This is a schematic structural diagram of a communication device 800 according to an embodiment of this application. The communication device 800 includes a processor 810, which can call and run computer programs from memory to enable the communication device 800 to implement the methods in the embodiments of this application.

[0546] Optionally, the communication device 800 may further include a memory 820. The processor 810 can retrieve and run computer programs from the memory 820 to enable the communication device 800 to implement the methods described in the embodiments of this application.

[0547] The memory 820 can be a separate device independent of the processor 810, or it can be integrated into the processor 810.

[0548] Optionally, the communication device 800 may also include a transceiver 830, which the processor 810 can control to communicate with other devices. Specifically, it can send information or data to other devices or receive information or data sent by other devices.

[0549] The transceiver 830 may include a transmitter and a receiver. The transceiver 830 may further include an antenna, and the number of antennas may be one or more.

[0550] Optionally, the communication device 800 may be the first device in the embodiments of this application, and the communication device 800 may implement the corresponding processes implemented by the first device in the various methods of the embodiments of this application. For the sake of brevity, it will not be described in detail here.

[0551] Optionally, the communication device 800 may be a configuration device in the embodiments of this application, and the communication device 800 may implement the corresponding processes implemented by the configuration device in the various methods of the embodiments of this application. For the sake of brevity, it will not be described in detail here.

[0552] Optionally, the communication device 800 may be a second device in the embodiments of this application, and the communication device 800 may implement the corresponding processes implemented by the second device in the various methods of the embodiments of this application. For the sake of brevity, it will not be described in detail here.

[0553] Optionally, the communication device 800 may be the first cloud in the embodiments of this application, and the communication device 800 may implement the corresponding processes implemented by the first cloud in the various methods of the embodiments of this application. For the sake of brevity, it will not be described in detail here.

[0554] Optionally, the communication device 800 may be the second cloud in the embodiments of this application, and the communication device 800 may implement the corresponding processes implemented by the second cloud in the various methods of the embodiments of this application. For the sake of brevity, it will not be described in detail here.

[0555] Figure 21This is a schematic structural diagram of a chip 900 according to an embodiment of this application. The chip 900 includes a processor 910, which can call and run computer programs from memory to implement the methods in the embodiments of this application.

[0556] Optionally, the chip 900 may further include a memory 920. The processor 910 can retrieve and run computer programs from the memory 920 to implement the methods executed by the terminal device or network device in this embodiment.

[0557] The memory 920 can be a separate device independent of the processor 910, or it can be integrated into the processor 910.

[0558] Optionally, the chip 900 may also include an input interface 930. The processor 910 can control the input interface 930 to communicate with other devices or chips; specifically, it can acquire information or data sent by other devices or chips.

[0559] Optionally, the chip 900 may also include an output interface 940. The processor 910 can control the output interface 940 to communicate with other devices or chips, specifically, to output information or data to other devices or chips.

[0560] Optionally, the chip 900 can be applied to the first device in the embodiments of this application, and the chip can implement the corresponding processes implemented by the first device in the various methods of the embodiments of this application. For the sake of brevity, it will not be described in detail here.

[0561] Optionally, the chip 900 can be applied to the configuration device in the embodiments of this application, and the chip can implement the corresponding processes implemented by the configuration device in the various methods of the embodiments of this application. For the sake of brevity, it will not be described in detail here.

[0562] Optionally, the chip 900 can be applied to the first cloud in the embodiments of this application, and the chip can implement the corresponding processes implemented by the first cloud in the various methods of the embodiments of this application. For the sake of brevity, it will not be described in detail here.

[0563] Optionally, the chip 900 can be applied to the second cloud in the embodiments of this application, and the chip can implement the corresponding processes implemented by the second cloud in the various methods of the embodiments of this application. For the sake of brevity, it will not be described in detail here.

[0564] Optionally, the chip 900 can be applied to the second device in the embodiments of this application, and the chip can implement the corresponding processes implemented by the second device in the various methods of the embodiments of this application. For the sake of brevity, it will not be described in detail here.

[0565] The chips used in the first device, the configuration device, the first cloud, the second cloud, and the second device can be the same chip or different chips.

[0566] It should be understood that the chip mentioned in the embodiments of this application may also be referred to as a system-on-a-chip, system chip, chip system, or system-on-a-chip, etc.

[0567] The processors mentioned above can be general-purpose processors, digital signal processors (DSPs), field-programmable gate arrays (FPGAs), application-specific integrated circuits (ASICs), or other programmable logic devices, transistor logic devices, discrete hardware components, etc. Among them, the general-purpose processors mentioned above can be microprocessors or any conventional processor.

[0568] The aforementioned memory can be volatile memory or non-volatile memory, or a combination of both. Non-volatile memory can be read-only memory (ROM), programmable read-only memory (PROM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), or flash memory. Volatile memory can be random access memory (RAM).

[0569] It should be understood that the above-described memory is exemplary and not a limiting description. For example, the memory in the embodiments of this application may also be static random access memory (SRAM), dynamic random access memory (DRAM), synchronous dynamic random access memory (SDRAM), double data rate synchronous dynamic random access memory (DDR SDRAM), enhanced synchronous dynamic random access memory (ESDRAM), synchronous link dynamic random access memory (SLDRAM), and direct memory bus RAM (DR RAM), etc. That is to say, the memory in the embodiments of this application is intended to include, but is not limited to, these and any other suitable types of memory.

[0570] Figure 22 This is a schematic block diagram of a communication system 1000 according to an embodiment of this application. The communication system 1000 may include a first device 1010, a configuration device 1020, and a first cloud 1030.

[0571] A first device 1010 is configured to receive an encrypted access token, which is obtained by encrypting an access token of at least one level using an access key of the first device 1010; the first device 1010 uses the access key to decrypt the encrypted access token.

[0572] The configuration device 1020 is configured to receive an encrypted access token from the first cloud 1030, the encrypted access token being obtained by the first cloud 1030 using the access key of the first device 1010; the configuration device 1020 sends the encrypted access token to the first device 1010.

[0573] A first cloud 1030 is used to encrypt an access token at at least one level using the access key of a first device 1010; the first cloud 1030 sends the encrypted access token.

[0574] Optionally, the communication system 1000 further includes: a second cloud 1040, configured to receive a token sharing request from a second device 1050, the token sharing request including information on at least one level of access token to be shared; the second cloud 1040 encrypts the access token corresponding to the information on the at least one level of access token; and the second cloud 1040 sends the encrypted access token.

[0575] Optionally, the communication system 1000 further includes: a second device 1050, configured to send a token sharing request, the token sharing request including information of at least one level of access token to be shared and information of the first device 1010; the second device 1050 receives an encrypted access token, the encrypted access token being obtained by encrypting the at least one level of access token to be shared using an access key corresponding to the information of the first device 1010; and the second device 1050 sends the encrypted access token.

[0576] Specifically, the first device 1010 can be used to implement the corresponding functions implemented by the first device in the above method; the configuration device 1020 can be used to implement the corresponding functions implemented by the configuration device in the above method; the first cloud 1030 can be used to implement the corresponding functions implemented by the first cloud in the above method; the second cloud 1040 can be used to implement the corresponding functions implemented by the second cloud in the above method; and the second device 1050 can be used to implement the corresponding functions implemented by the second device in the above method. For simplicity, further details are omitted here.

[0577] In the above embodiments, implementation can be achieved, in whole or in part, through software, hardware, firmware, or any combination thereof. When implemented in software, it can be implemented, in whole or in part, as a computer program product. This computer program product includes one or more computer instructions. When these computer program instructions are loaded and executed on a computer, all or part of the processes or functions described in the embodiments of this application are generated. The computer can be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. The computer instructions can be stored in a computer-readable storage medium or transmitted from one computer-readable storage medium to another. For example, the computer instructions can be transmitted from one website, computer, server, or data center to another via wired (e.g., coaxial cable, fiber optic, Digital Subscriber Line (DSL)) or wireless (e.g., infrared, wireless, microwave, etc.) means. The computer-readable storage medium can be any available medium accessible to a computer or a data storage device such as a server or data center that integrates one or more available media. The available media can be magnetic media (e.g., floppy disks, hard disks, magnetic tapes), optical media (e.g., DVDs), or semiconductor media (e.g., solid-state drives (SSDs)).

[0578] It should be understood that in the various embodiments of this application, the order of the above-mentioned processes does not imply the order of execution. The execution order of each process should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of the embodiments of this application.

[0579] Those skilled in the art will understand that, for the sake of convenience and brevity, the specific working processes of the systems, devices, and units described above can be referred to the corresponding processes in the foregoing method embodiments, and will not be repeated here.

[0580] The above description is merely a specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

Claims

1. An access token processing method, comprising: The first device receives an encrypted access token, which is obtained by encrypting at least one level of access token using the first device's access key. Specifically, when the first device needs to access at least one of the unrestricted attributes, unrestricted methods, and unrestricted events of unrestricted services across all devices under the same account, it receives an encrypted account-level access key; when the first device needs to access at least one of the unrestricted attributes, unrestricted methods, and unrestricted events of all unrestricted services of the same device, it receives an encrypted device-level access key; when the first device needs to access at least one of the unrestricted attributes, unrestricted methods, and unrestricted events of at least one restricted service of the same device, or at least one of the unrestricted attributes, unrestricted methods, and unrestricted events of at least one restricted service of multiple devices, it receives an encrypted service-level access token; and when the first device needs to access at least one of the restricted attributes, restricted methods, and restricted events of the same service of the same device, or at least one of the restricted attributes, restricted methods, and restricted events of multiple services of the same device, or at least one of the restricted attributes, restricted methods, and restricted events of multiple services of multiple devices, it receives an encrypted attribute-level access token. The first device uses the access key to decrypt the encrypted access token.

2. The method according to claim 1, wherein, The first device receives an encrypted access token, including: The first device receives the encrypted access token from the configuration device, wherein the encrypted access token is received by the configuration device from the first cloud, and the encrypted access token is obtained by the first cloud encrypting an access token of at least one level using the access key.

3. The method according to claim 1, wherein, The first device receives an encrypted access token, including: The first device receives the encrypted access token from the first cloud, wherein the encrypted access token is obtained by the first cloud encrypting an access token of at least one level using the access key.

4. The method according to claim 1, wherein, The first device receives an encrypted access token, including: The first device receives the encrypted access token from the first cloud, wherein the encrypted access token is obtained by the first cloud encrypting at least one level of access token that the second device needs to share using the access key.

5. The method according to claim 1, wherein, The first device receives an encrypted access token, including: The first device receives the encrypted access token from the first cloud, wherein the encrypted access token is obtained by the first cloud using the access key to encrypt the first encrypted access token a second time, and the first encrypted access token is obtained by the second cloud using a temporary key to encrypt at least one level of access token that the second device needs to share.

6. The method according to any one of claims 1 to 5, wherein, The method further includes: The first device receives the access key from the first cloud.

7. The method according to claim 1, wherein, The method further includes: The first device receives an encrypted update message, which is obtained by encrypting information of at least one level of access token that needs to be updated and the content that needs to be updated using the access key; The first device uses the access key to decrypt the update message to obtain information about the access token of at least one level that needs to be updated and the content that needs to be updated; The first device updates the access token corresponding to the information of at least one level of access token that needs to be updated, based on the content that needs to be updated.

8. The method according to claim 7, wherein, The first device receives an encrypted update message, including: The first device receives the encrypted update message from the configuration device, the encrypted update message being received by the configuration device from the first cloud, and the encrypted update message being encrypted in the first cloud.

9. The method according to claim 7, wherein, The first device receives an encrypted update message, including: The first device receives the encrypted update message from the first cloud, the encrypted update message being encrypted in the first cloud.

10. The method according to claim 1, wherein, The method further includes: The first device receives an encrypted deletion message, which is obtained by encrypting information of at least one level of access token to be deleted using the access key; The first device uses the access key to decrypt the encrypted deletion message to obtain information about the access token of at least one level that needs to be deleted; The first device deletes the corresponding access token based on the information of the access token of at least one level that needs to be deleted.

11. The method according to claim 10, wherein, The first device receives an encrypted deletion message, including: The first device receives the encrypted deletion message from the configuration device, the encrypted deletion message being received by the configuration device from the first cloud, and the encrypted deletion message being encrypted in the first cloud.

12. The method according to claim 10, wherein, The first device receives an encrypted deletion message, including: The first device receives the encrypted deletion message from the first cloud, wherein the encrypted deletion message is encrypted in the first cloud.

13. An access token processing method, comprising: The configuration device receives an encrypted access token from a first cloud. This encrypted access token is obtained by the first cloud encrypting at least one level of access token using the first device's access key. Specifically, when the first device needs to access at least one of the unrestricted attributes, unrestricted methods, and unrestricted events of unrestricted services across all devices under the same account, it receives an encrypted account-level access key; when the first device needs to access at least one of the unrestricted attributes, unrestricted methods, and unrestricted events of all unrestricted services of the same device, it receives an encrypted device-level access key; when the first device needs to access at least one of the unrestricted attributes, unrestricted methods, and unrestricted events of at least one restricted service of the same device, or at least one of the unrestricted attributes, unrestricted methods, and unrestricted events of at least one restricted service of multiple devices, it receives an encrypted service-level access token; and when the first device needs to access at least one of the restricted attributes, restricted methods, and restricted events of the same service of the same device, or at least one of the restricted attributes, restricted methods, and restricted events of multiple services of the same device, or at least one of the restricted attributes, restricted methods, and restricted events of multiple services of multiple devices, it receives an encrypted attribute-level access token. The configuration device sends the encrypted access token to the first device.

14. The method according to claim 13, wherein, The method further includes: The configuration device sends a token issuance request to the first cloud to request an access token for at least one level.

15. The method according to claim 14, wherein, The token issuance request includes one of the following: A list of controlled device identifiers, wherein the token issuance request is used to request a device-level access token; The controlled device identifier and service name list, wherein the token issuance request is used to request a service-level access token; The controlled device identifier, service name, and attribute-related information are included. The token issuance request is used to request an attribute-level access token.

16. The method according to claim 15, wherein, The attribute-related information includes at least one of the following: a list of attribute names, a list of read, write, add, delete or modify methods corresponding to the attribute, and a list of event names.

17. The method of claim 14, wherein, The token issuance request also includes a list of master device identifiers.

18. The method according to claim 13, wherein, The method further includes: The configuration device receives an encrypted update message from the first cloud, wherein the encrypted update message is obtained by the first cloud using the access key to encrypt information of at least one level of access token that needs to be updated and the content that needs to be updated; The configuration device sends the encrypted update message to the first device.

19. The method according to claim 13, wherein, The method further includes: The configuration device receives an encrypted deletion message from the first cloud, wherein the encrypted deletion message is obtained by the first cloud encrypting information of at least one level of access tokens to be deleted using the access key; The configuration device sends the encrypted deletion message to the first device.

20. An access token processing method, comprising: The first cloud uses the access key of the first device to encrypt the access token at at least one level; The first cloud sends encrypted access tokens, wherein: when the first device needs to access at least one of the unrestricted attributes, unrestricted methods, and unrestricted events of unrestricted services of all devices under the same account, an encrypted account-level access key is sent; when the first device needs to access at least one of the unrestricted attributes, unrestricted methods, and unrestricted events of all unrestricted services of the same device, an encrypted device-level access key is sent; when the first device needs to access at least one of the unrestricted attributes, unrestricted methods, and unrestricted events of at least one restricted service of the same device, or at least one of the unrestricted attributes, unrestricted methods, and unrestricted events of at least one restricted service of multiple devices, an encrypted service-level access token is sent; when the first device needs to access at least one of the restricted attributes, restricted methods, and restricted events of the same service of the same device, or at least one of the restricted attributes, restricted methods, and restricted events of multiple services of the same device, or at least one of the restricted attributes, restricted methods, and restricted events of multiple services of multiple devices, an encrypted attribute-level access token is sent.

21. The method according to claim 20, wherein, The first cloud sends an encrypted access token, including: The first cloud sends the encrypted access token to the configuration device, and the configuration device then sends the encrypted access token to the first device.

22. The method according to claim 20, wherein, The first cloud sends an encrypted access token, including: The first cloud sends an encrypted access token to the first device.

23. The method according to any one of claims 20 to 22, wherein, The method further includes: The first cloud receives information from the second device regarding at least one level of access token that needs to be shared, as well as information from the first device.

24. The method according to claim 23, wherein, The first cloud uses the access key of the first device to encrypt access tokens at at least one level, including: The first cloud encrypts the access token of at least one level that needs to be shared based on the access key corresponding to the information of the first device.

25. The method according to any one of claims 20 to 22, wherein, The method further includes: The first cloud receives a first encrypted access token and information from the first device from the second cloud. The first encrypted access token is obtained by the second cloud using a temporary key to encrypt at least one level of access token that needs to be shared.

26. The method of claim 25, wherein, The first cloud uses the access key of the first device to encrypt access tokens at at least one level, including: The first cloud platform encrypts the first encrypted access token based on the access key corresponding to the information of the first device to obtain the second encrypted access token.

27. The method according to claim 26, wherein, The first cloud sends an encrypted access token, including: The first cloud sends the second encrypted access token.

28. The method according to claim 27, wherein, The first cloud sends the second encrypted access token, including: The first cloud sends the second encrypted access token to the second device through the second cloud, and the second device sends the second encrypted access token to the first device.

29. The method according to claim 27, wherein, The first cloud sends the second encrypted access token, including: The first cloud sends the second encrypted access token to the first device.

30. The method of claim 20, wherein, The method further includes: The first cloud sends the access key to at least one of the first devices.

31. The method according to claim 20, wherein, The method further includes: The first cloud receives a token issuance request from the configuration device for requesting an access token for at least one level.

32. The method according to claim 31, wherein, The token issuance request includes one of the following: A list of controlled device identifiers, wherein the token issuance request is used to request a device-level access token; The controlled device identifier and service name list, wherein the token issuance request is used to request a service-level access token; The controlled device identifier, service name, and attribute-related information are included. The token issuance request is used to request an attribute-level access token.

33. The method according to claim 32, wherein, The attribute-related information includes at least one of the following: a list of attribute names, a list of read, write, add, delete or modify methods corresponding to the attribute, and a list of event names.

34. The method according to any one of claims 31 to 33, wherein, The token issuance request also includes a list of master device identifiers.

35. The method according to claim 20, wherein, The method further includes: The first cloud uses the access key to encrypt the information of the access token at least one level that needs to be updated and the content that needs to be updated, to obtain an encrypted update message; The first cloud sends the encrypted update message.

36. The method according to claim 35, wherein, The first cloud sends the encrypted update message, including: The first cloud sends the encrypted update message to the configuration device, and the configuration device then sends the encrypted update message back to the first device.

37. The method of claim 35, wherein, The first cloud sends the encrypted update message, including: The first cloud sends the encrypted update message to the first device.

38. The method according to any one of claims 20 to 37, wherein, The method further includes: The first cloud platform uses the access key to encrypt information of at least one level of access tokens that need to be deleted to obtain an encrypted deletion message; The first cloud platform sends the encrypted deletion message.

39. The method according to claim 38, wherein, The first cloud platform sends the encrypted deletion message, including: The first cloud sends the encrypted deletion message to the configuration device, and the configuration device then sends the encrypted deletion message back to the first device.

40. The method of claim 38, wherein, The first cloud platform sends the encrypted deletion message, including: The first cloud sends the encrypted deletion message to the first device.

41. An access token processing method, comprising: The second cloud receives a token sharing request from the second device, the token sharing request including information about at least one level of access token to be shared and information about the first device; The second cloud encrypts the access token corresponding to the information of the at least one level of access token; The second cloud sends encrypted access tokens, wherein: when the first device needs to access at least one of the unrestricted attributes, unrestricted methods, and unrestricted events of unrestricted services of all devices under the same account, an encrypted account-level access key is sent; when the first device needs to access at least one of the unrestricted attributes, unrestricted methods, and unrestricted events of all unrestricted services of the same device, an encrypted device-level access key is sent; when the first device needs to access at least one of the unrestricted attributes, unrestricted methods, and unrestricted events of at least one restricted service of the same device, or at least one of the unrestricted attributes, unrestricted methods, and unrestricted events of at least one restricted service of multiple devices, an encrypted service-level access token is sent; when the first device needs to access at least one of the restricted attributes, restricted methods, and restricted events of the same service of the same device, or at least one of the restricted attributes, restricted methods, and restricted events of multiple services of the same device, or at least one of the restricted attributes, restricted methods, and restricted events of multiple services of multiple devices, an encrypted attribute-level access token is sent.

42. The method according to claim 41, wherein the second cloud encrypts the access token corresponding to the information of the at least one level of access token, comprising: The second cloud encrypts the access token corresponding to the information of the at least one level of access token based on the access key corresponding to the information of the first device.

43. The method according to claim 41, wherein, The second cloud encrypts the access token corresponding to the information of the at least one level of access token, including: The second cloud uses a temporary key to encrypt the access token corresponding to the information of the at least one level of access token for the first time.

44. The method according to claim 43, wherein, The temporary key is included in the token sharing request, or the temporary key is generated in the second cloud.

45. The method according to claim 43 or 44, wherein, The second cloud sends an encrypted access token, including: The second cloud sends the first encrypted access token and the information of the first device to the first cloud.

46. ​​The method according to claim 45, wherein, The method further includes: The second cloud receives a second encrypted access token from the first cloud. The second encrypted access token is obtained by the first cloud encrypting the first encrypted access token a second time using the access key corresponding to the information of the first device.

47. The method according to claim 46, wherein, The second cloud sends an encrypted access token, which also includes at least one of the following: The second cloud sends the second encrypted access token to the second device, and the second device sends the second encrypted access token and the temporary key to the first device; The second cloud sends the second encrypted access token and the temporary key to the first device.

48. An access token processing method, comprising: The second device sends a token sharing request, which includes information about at least one level of access token to be shared and information about the first device. The second device receives an encrypted access token, which is obtained by encrypting at least one level of access token to be shared using the access key corresponding to the information of the first device. Specifically, when the first device needs to access at least one of the unrestricted attributes, unrestricted methods, and unrestricted events of unrestricted services of all devices under the same account, it receives an encrypted account-level access key; when the first device needs to access at least one of the unrestricted attributes, unrestricted methods, and unrestricted events of all unrestricted services of the same device, it receives an encrypted device-level access key; when the first device needs to access at least one of the unrestricted attributes, unrestricted methods, and unrestricted events of at least one restricted service of the same device or at least one of the unrestricted attributes, unrestricted methods, and unrestricted events of at least one restricted service of multiple devices, it receives an encrypted service-level access token; and when the first device needs to access at least one of the restricted attributes, restricted methods, and restricted events of the same service of the same device or at least one of the restricted attributes, restricted methods, and restricted events of multiple services of the same device or at least one of the restricted attributes, restricted methods, and restricted events of multiple services of multiple devices, it receives an encrypted attribute-level access token. The second device sends the encrypted access token.

49. The method according to claim 48, wherein, The second device sends a token sharing request, including: The second device sends a token sharing request to the first cloud.

50. The method according to claim 49, wherein, The second device receives an encrypted access token, including: The second device receives the encrypted access token from the first cloud, which is obtained by the first cloud encrypting at least one level of access token that needs to be shared using the access key corresponding to the information of the first device.

51. The method according to any one of claims 48 to 50, wherein, The second device sends the encrypted access token, including at least one of the following: The second device sends the encrypted access token to the first device; The second device sends the encrypted access token to the first device via the second cloud; The second device sends the encrypted access token to the first device through the second cloud and the first cloud.

52. The method according to claim 48, wherein, The second device sends a token sharing request, including: The second device sends a token sharing request to the second cloud.

53. The method according to claim 52, wherein, The second device receives an encrypted access token, including: The second device receives a second encrypted access token from the second cloud. The second encrypted access token is obtained by encrypting the access token of at least one level that needs to be shared using a temporary key and the access key corresponding to the information of the first device.

54. The method according to claim 53, wherein, The temporary key is included in the token sharing request sent by the second device to the second cloud, or the temporary key is generated in the second cloud.

55. The method according to claim 54, wherein, The second device sends the encrypted access token, including: The second device sends the second encrypted access token and the temporary key.

56. The method according to claim 55, wherein, The second device sends the second encrypted access token and the temporary key, including at least one of the following: The second device sends the second encrypted access token and the temporary key to the first device; The second device sends the second encrypted access token and the temporary key to the first device via the second cloud; The second device sends the second encrypted access token and the temporary key to the first device through the second cloud and the first cloud.

57. A first device, comprising: A receiving unit is configured to receive an encrypted access token, wherein the encrypted access token is obtained by encrypting at least one level of access token using the access key of the first device. Specifically, when the first device needs to access at least one of the unrestricted attributes, unrestricted methods, and unrestricted events of unrestricted services of all devices under the same account, it receives an encrypted account-level access key; when the first device needs to access at least one of the unrestricted attributes, unrestricted methods, and unrestricted events of all unrestricted services of the same device, it receives an encrypted device-level access key; when the first device needs to access at least one of the unrestricted attributes, unrestricted methods, and unrestricted events of at least one restricted service of the same device, or at least one of the unrestricted attributes, unrestricted methods, and unrestricted events of at least one restricted service of multiple devices, it receives an encrypted service-level access token; and when the first device needs to access at least one of the restricted attributes, restricted methods, and restricted events of the same service of the same device, or at least one of the restricted attributes, restricted methods, and restricted events of multiple services of the same device, or at least one of the restricted attributes, restricted methods, and restricted events of multiple services of multiple devices, it receives an encrypted attribute-level access token. A decryption unit is used to decrypt the encrypted access token using the access key.

58. The first device according to claim 57, wherein, The receiving unit is used to receive the encrypted access token from the configuration device, wherein the encrypted access token is received by the configuration device from the first cloud, and the encrypted access token is obtained by the first cloud encrypting at least one level of access token using the access key.

59. The first device according to claim 57, wherein, The receiving unit is used to receive the encrypted access token from the first cloud, wherein the encrypted access token is obtained by the first cloud encrypting an access token of at least one level using the access key.

60. The first device according to claim 57, wherein, The receiving unit is used to receive the encrypted access token from the first cloud, wherein the encrypted access token is obtained by the first cloud encrypting at least one level of access token that the second device needs to share using the access key.

61. The first device according to claim 57, wherein, The receiving unit is used to receive the encrypted access token from the first cloud, wherein the encrypted access token is obtained by the first cloud using the access key to encrypt the first encrypted access token a second time, and the first encrypted access token is obtained by the second cloud receiving the first cloud using a temporary key to encrypt at least one level of access token that the second device needs to share.

62. The first device according to claim 57, wherein, The receiving unit is also used to receive the access key from the first cloud.

63. The first device according to claim 57, wherein, The receiving unit is also used to receive an encrypted update message, which is obtained by encrypting the information of the access token of at least one level that needs to be updated and the content that needs to be updated using the access key; The decryption unit is used to decrypt the update message using the access key to obtain information about the access token of at least one level that needs to be updated and the content that needs to be updated. The first device further includes an update unit, configured to update the access token corresponding to the information of at least one level of access token that needs to be updated, based on the content that needs to be updated.

64. The first device according to claim 63, wherein, The receiving unit is used to receive the encrypted update message from the configuration device, the encrypted update message being received by the configuration device from the first cloud, and the encrypted update message being encrypted in the first cloud.

65. The first device according to claim 63, wherein, The receiving unit is used to receive the encrypted update message from the first cloud, wherein the encrypted update message is encrypted in the first cloud.

66. The first device according to claim 57, wherein, The receiving unit is also used to receive an encrypted deletion message, which is obtained by encrypting information of at least one level of access token to be deleted using the access key; The decryption unit is used to decrypt the encrypted deletion message using the access key to obtain information about the access token of at least one level that needs to be deleted; The first device further includes a deletion unit, used to delete the corresponding access token based on information about the access token of at least one level that needs to be deleted.

67. The first device according to claim 66, wherein, The receiving unit is used to receive the encrypted deletion message from the configuration device. The encrypted deletion message is received by the configuration device from the first cloud, and the encrypted deletion message is encrypted in the first cloud.

68. The first device according to claim 66, wherein, The receiving unit is used to receive the encrypted deletion message from the first cloud, wherein the encrypted deletion message is encrypted in the first cloud.

69. A configuration device, comprising: A receiving unit is configured to receive an encrypted access token from a first cloud platform. The encrypted access token is obtained by the first cloud platform encrypting at least one level of access token using the access key of a first device. Specifically, when the first device needs to access at least one of the unrestricted attributes, unrestricted methods, and unrestricted events of unrestricted services across all devices under the same account, it receives an encrypted account-level access key; when the first device needs to access at least one of the unrestricted attributes, unrestricted methods, and unrestricted events of all unrestricted services of the same device, it receives an encrypted device-level access key; when the first device needs to access at least one of the unrestricted attributes, unrestricted methods, and unrestricted events of at least one restricted service of the same device, or at least one of the unrestricted attributes, unrestricted methods, and unrestricted events of at least one restricted service of multiple devices, it receives an encrypted service-level access token; and when the first device needs to access at least one of the restricted attributes, restricted methods, and restricted events of the same service of the same device, or at least one of the restricted attributes, restricted methods, and restricted events of multiple services of the same device, or at least one of the restricted attributes, restricted methods, and restricted events of multiple services of multiple devices, it receives an encrypted attribute-level access token. The sending unit is used to send the encrypted access token to the first device.

70. The configuration device according to claim 69, wherein, The sending unit is also used to send a token issuance request to the first cloud for requesting an access token of at least one level.

71. The configuration device according to claim 70, wherein, The token issuance request includes one of the following: A list of controlled device identifiers, wherein the token issuance request is used to request a device-level access token; The controlled device identifier and service name list, wherein the token issuance request is used to request a service-level access token; The controlled device identifier, service name, and attribute-related information are included. The token issuance request is used to request an attribute-level access token.

72. The configuration device according to claim 71, wherein, The attribute-related information includes at least one of the following: a list of attribute names, a list of read, write, add, delete or modify methods corresponding to the attribute, and a list of event names.

73. The configuration device according to any one of claims 70 to 72, wherein, The token issuance request also includes a list of master device identifiers.

74. The configuration device according to claim 69, wherein, The receiving unit is also configured to receive an encrypted update message from the first cloud, wherein the encrypted update message is obtained by the first cloud using the access key to encrypt information of at least one level of access token that needs to be updated and the content that needs to be updated; The sending unit is also used to send the encrypted update message to the first device.

75. The configuration device according to claim 69, wherein, The receiving unit is also configured to receive an encrypted deletion message from the first cloud, wherein the encrypted deletion message is obtained by the first cloud encrypting information of at least one level of access token to be deleted using the access key; The sending unit is also used to send the encrypted deletion message to the first device.

76. A first cloud, comprising: The first encryption unit is used to encrypt an access token of at least one level using the access key of the first device; The first sending unit is configured to send encrypted access tokens, wherein: when the first device needs to access at least one of the unrestricted attributes, unrestricted methods, and unrestricted events of unrestricted services of all devices under the same account, it sends an encrypted account-level access key; when the first device needs to access at least one of the unrestricted attributes, unrestricted methods, and unrestricted events of all unrestricted services of the same device, it sends an encrypted device-level access key; when the first device needs to access at least one of the unrestricted attributes, unrestricted methods, and unrestricted events of at least one restricted service of the same device, or at least one of the unrestricted attributes, unrestricted methods, and unrestricted events of at least one restricted service of multiple devices, it sends an encrypted service-level access token; and when the first device needs to access at least one of the restricted attributes, restricted methods, and restricted events of the same service of the same device, or at least one of the restricted attributes, restricted methods, and restricted events of multiple services of the same device, or at least one of the restricted attributes, restricted methods, and restricted events of multiple services of multiple devices, it sends an encrypted attribute-level access token.

77. The first cloud platform according to claim 76, wherein, The first sending unit is used to send the encrypted access token to the configuration device, and the configuration device sends the encrypted access token to the first device.

78. The first cloud platform according to claim 76, wherein, The first sending unit is used to send an encrypted access token to the first device.

79. The first cloud according to any one of claims 76 to 78, wherein, The first cloud also includes: The first receiving unit is used to receive information from the second device regarding at least one level of access token that needs to be shared, and information from the first device.

80. The first cloud platform according to claim 79, wherein, The first encryption unit is used to encrypt the access token of at least one level that needs to be shared based on the access key corresponding to the information of the first device.

81. The first cloud according to any one of claims 76 to 78, wherein, The first cloud also includes: The second receiving unit is used to receive the first encrypted access token and the information of the first device from the second cloud. The first encrypted access token is obtained by the second cloud using a temporary key to encrypt the access token of at least one level that needs to be shared for the first time.

82. The first cloud platform according to claim 81, wherein, The first encryption unit is used to encrypt the first encrypted access token based on the access key corresponding to the information of the first device to obtain the second encrypted access token.

83. The first cloud platform according to claim 82, wherein, The first sending unit is used to send the second encrypted access token.

84. The first cloud platform according to claim 83, wherein, The first sending unit is used to send the second encrypted access token to the second device through the second cloud, and the second device sends the second encrypted access token to the first device.

85. The first cloud platform according to claim 83, wherein, The first sending unit is used to send the second encrypted access token to the first device.

86. The first cloud platform according to claim 76, wherein, The first cloud also includes: The second sending unit is used to send the access key to at least one of the first devices.

87. The first cloud platform according to claim 76, wherein, The first cloud also includes: The third receiving unit is used to receive a token issuance request from the configuration device for requesting an access token of at least one level.

88. The first cloud platform according to claim 87, wherein, The token issuance request includes one of the following: A list of controlled device identifiers, wherein the token issuance request is used to request a device-level access token; The controlled device identifier and service name list, wherein the token issuance request is used to request a service-level access token; The controlled device identifier, service name, and attribute-related information are included. The token issuance request is used to request an attribute-level access token.

89. The first cloud platform according to claim 88, wherein, The attribute-related information includes at least one of the following: a list of attribute names, a list of read, write, add, delete or modify methods corresponding to the attribute, and a list of event names.

90. The first cloud platform according to any one of claims 87 to 89, wherein, The token issuance request also includes a list of master device identifiers.

91. The first cloud platform according to claim 76, wherein, The first cloud also includes: The second encryption unit is used to encrypt the information of the access token of at least one level that needs to be updated and the content that needs to be updated using the access key, so as to obtain an encrypted update message. The third sending unit is used to send the encrypted update message.

92. The first cloud platform according to claim 91, wherein, The third sending unit is used to send the encrypted update message to the configuration device, and the configuration device sends the encrypted update message to the first device.

93. The first cloud platform according to claim 91, wherein, The third sending unit is used to send the encrypted update message to the first device.

94. The first cloud platform according to claim 76, wherein, The first cloud also includes: The third encryption unit is used to encrypt the information of the access token of at least one level that needs to be deleted using the access key to obtain an encrypted deletion message; The fourth sending unit is used to send the encrypted deletion message.

95. The first cloud platform according to claim 94, wherein, The fourth sending unit is used to send the encrypted deletion message to the configuration device, and the configuration device sends the encrypted deletion message to the first device.

96. The first cloud platform according to claim 94, wherein, The fourth sending unit is used to send the encrypted deletion message to the first device.

97. A second cloud, comprising: A receiving unit is configured to receive a token sharing request from a second device, the token sharing request including information about at least one level of access token to be shared and information about the first device; An encryption unit is used to encrypt the access token corresponding to the information of the access token at the at least one level; The sending unit is configured to send encrypted access tokens, wherein: when the first device needs to access at least one of the unrestricted attributes, unrestricted methods, and unrestricted events of unrestricted services of all devices under the same account, it sends an encrypted account-level access key; when the first device needs to access at least one of the unrestricted attributes, unrestricted methods, and unrestricted events of all unrestricted services of the same device, it sends an encrypted device-level access key; when the first device needs to access at least one of the unrestricted attributes, unrestricted methods, and unrestricted events of at least one restricted service of the same device, or at least one of the unrestricted attributes, unrestricted methods, and unrestricted events of at least one restricted service of multiple devices, it sends an encrypted service-level access token; and when the first device needs to access at least one of the restricted attributes, restricted methods, and restricted events of the same service of the same device, or at least one of the restricted attributes, restricted methods, and restricted events of multiple services of the same device, or at least one of the restricted attributes, restricted methods, and restricted events of multiple services of multiple devices, it sends an encrypted attribute-level access token.

98. The second cloud according to claim 97, wherein the encryption unit is used to encrypt the access token corresponding to the information of the at least one level of access token based on the access key corresponding to the information of the first device.

99. The second cloud according to claim 97, wherein, The encryption unit is used to perform a first encryption on the access token corresponding to the information of the access token at the at least one level using a temporary key.

100. The second cloud according to claim 99, wherein, The temporary key is included in the token sharing request, or the temporary key is generated in the second cloud.

101. The second cloud according to claim 99 or 100, wherein, The sending unit is used to send the first encrypted access token and the information of the first device to the first cloud.

102. The second cloud according to claim 101, wherein, The receiving unit is also configured to receive a second encrypted access token from the first cloud, wherein the second encrypted access token is obtained by the first cloud using the access key corresponding to the information of the first device to encrypt the first encrypted access token a second time.

103. The second cloud according to claim 102, wherein, The transmitting unit is also used for at least one of the following: The second encrypted access token is sent to the second device, and the second device sends the second encrypted access token and the temporary key to the first device. Send the second encrypted access token and the temporary key to the first device.

104. A second device, comprising: The first sending unit is used to send a token sharing request, wherein the token sharing request includes information about at least one level of access token that needs to be shared and information about the first device; A receiving unit is configured to receive an encrypted access token, wherein the encrypted access token is obtained by encrypting at least one level of access token to be shared using an access key corresponding to the information of the first device. Specifically, when the first device needs to access at least one of the unrestricted attributes, unrestricted methods, and unrestricted events of unrestricted services of all devices under the same account, an encrypted account-level access key is received; when the first device needs to access at least one of the unrestricted attributes, unrestricted methods, and unrestricted events of all unrestricted services of the same device, an encrypted device-level access key is received; when the first device needs to access at least one of the unrestricted attributes, unrestricted methods, and unrestricted events of at least one restricted service of the same device or at least one of the unrestricted attributes, unrestricted methods, and unrestricted events of at least one restricted service of multiple devices, an encrypted service-level access token is received; and when the first device needs to access at least one of the restricted attributes, restricted methods, and restricted events of the same service of the same device or at least one of the restricted attributes, restricted methods, and restricted events of multiple services of the same device or at least one of the restricted attributes, restricted methods, and restricted events of multiple services of multiple devices, an encrypted attribute-level access token is received. The second sending unit is used to send the encrypted access token.

105. The second device according to claim 104, wherein, The first sending unit is used to send a token sharing request to the first cloud.

106. The second device according to claim 105, wherein, The receiving unit is used to receive the encrypted access token from the first cloud. The encrypted access token is obtained by the first cloud encrypting the access token of at least one level that needs to be shared using the access key corresponding to the information of the first device.

107. The second device according to any one of claims 104 to 106, wherein, The second sending unit is configured to perform at least one of the following: Send the encrypted access token to the first device; The encrypted access token is sent to the first device via the second cloud; The encrypted access token is sent to the first device via the second cloud and the first cloud.

108. The second device according to claim 104, wherein, The first sending unit is used to send a token sharing request to the second cloud.

109. The second device according to claim 108, wherein, The receiving unit is used to receive a second encrypted access token from the second cloud. The second encrypted access token is obtained by encrypting the access token of at least one level that needs to be shared using a temporary key and the access key corresponding to the information of the first device.

110. The second device according to claim 109, wherein, The temporary key is included in the token sharing request sent by the second device to the second cloud, or the temporary key is generated in the second cloud.

111. The second device according to claim 110, wherein, The second sending unit is used to send the second encrypted access token and the temporary key.

112. The second device according to claim 111, wherein, The second sending unit is configured to perform at least one of the following: Send the second encrypted access token and the temporary key to the first device; The second encrypted access token and the temporary key are sent to the first device via the second cloud. The second encrypted access token and the temporary key are sent to the first device through the second cloud and the first cloud.

113. A first device, comprising: A processor and a memory for storing a computer program, the processor for calling and running the computer program stored in the memory to cause the first device to perform the method as described in any one of claims 1 to 12.

114. A configuration device, comprising: A processor and a memory for storing a computer program, the processor for calling and running the computer program stored in the memory to cause the first device to perform the method as described in any one of claims 13 to 19.

115. A first cloud, comprising: A processor and a memory for storing a computer program, the processor for calling and running the computer program stored in the memory to cause the first device to perform the method as described in any one of claims 20 to 40.

116. A second cloud, comprising: A processor and a memory for storing a computer program, the processor for calling and running the computer program stored in the memory to cause the first device to perform the method as described in any one of claims 41 to 47.

117. A second device, comprising: A processor and a memory for storing a computer program, the processor for calling and running the computer program stored in the memory to cause the second device to perform the method as described in any one of claims 48 to 56.

118. A chip, comprising: A processor for retrieving and running a computer program from memory, causing a device on which the chip is mounted to perform the method as described in any one of claims 1 to 56.

119. A computer-readable storage medium for storing a computer program that, when run by a device, causes the device to perform the method as claimed in any one of claims 1 to 56.

120. A computer program product comprising computer program instructions that cause a computer to perform the method as described in any one of claims 1 to 56.

Images