Authentication method and device based on OpenHarmony equipment and electronic equipment

Abstract

The invention discloses an authentication method and device based on OpenHarmony equipment and electronic equipment, which are applied to SDK (Software Development Kit) components of the OpenHarmony equipment, the OpenHarmony equipment further comprises a bottom OS (Operating System) and a plurality of upper-layer application components, the OpenHarmony equipment comprises the plurality of SDK components, the authentication capabilities of at least two of the plurality of SDK components are different, and the upper-layer application components and the SDK components are designed in a distributed manner. The SDK component acquires the calling request of the upper-layer application component, acquires the authentication request according to the calling request, authenticates the authentication request by utilizing the acquired authentication capability and returns the authentication result, so that distributed authentication is realized, the SDK component is subjected to componentization design according to the authentication capability by utilizing the capability of OpenHarmony equipment, and the authentication efficiency is improved. Meanwhile, the upper application is subjected to modularization design, during authentication, the whole application program is not authenticated, the SDK component is utilized, and different SDK components are called for different authentication requests to perform independent authentication, so that the authentication efficiency is improved, and the overall security is improved.

Description

Technical Field

[0001] The present invention relates to the field of authentication technology, and in particular to an authentication method, device and electronic equipment based on OpenHarmony equipment. Background Art

[0002] In the computer field, upper-level applications need to call on specific capabilities of the underlying system to complete certain functions. During the calling process, the upper-level applications need to be authenticated.

[0003] However, in the related art, authentication of upper layer applications often fails, resulting in low authentication efficiency. Summary of the invention

[0004] The technical problem to be solved by the present invention is to provide an authentication method, device and electronic device based on OpenHarmony equipment, thereby improving the authentication efficiency.

[0005] In order to solve the above technical problems, a technical solution adopted by the present invention is: An authentication method based on an OpenHarmony device is applied to an SDK component of the OpenHarmony device, wherein the OpenHarmony device further includes an underlying OS and multiple upper-layer application components, the OpenHarmony device includes multiple SDK components, at least two of the multiple SDK components have different authentication capabilities, the upper-layer application components and the SDK components are designed in a distributed manner, and the method includes: Obtaining a call request of the upper layer application component; Obtaining an authentication request according to the call request; Acquiring authentication capability, and authenticating the authentication request using the authentication capability; Returns the authentication result.

[0006] In order to solve the above technical problems, another technical solution adopted by the present invention is: An authentication device based on OpenHarmony equipment includes a component calling module, a request obtaining module, an authentication module and a result returning module: The component calling module is used to obtain the calling request of the upper layer application component; The request acquisition module is used to obtain an authentication request according to the call request; The authentication module is used to obtain authentication capabilities and use the authentication capabilities to authenticate the authentication request; The result returning module is used to return the authentication result.

[0007] In order to solve the above technical problems, another technical solution adopted by the present invention is: An electronic device comprises a memory, a processor and a computer program stored in the memory and running on the processor, wherein the processor implements each step of the above-mentioned authentication method based on OpenHarmony device when executing the computer program.

[0008] The beneficial effects of the present invention are: the method of the present application is applied to the SDK component of the OpenHarmony device, the OpenHarmony device also includes an underlying OS and multiple upper-level application components, the OpenHarmony device includes multiple SDK components, at least two of the multiple SDK components have different authentication capabilities, and the upper-level application components and the SDK components are designed in a distributed manner. The SDK component of the present application obtains the call request of the upper-level application component, obtains the authentication request according to the call request, authenticates the authentication request by using the obtained authentication capability, and returns the authentication result. The distributed authentication is realized by the upper-level application component and SDK component with distributed design. The present application utilizes the capability of the OpenHarmony device, and componentizes the SDK component according to the authentication capability, and also componentizes the upper-level application. When performing authentication, the entire application is not authenticated. Instead, the SDK component is used to call different SDK components for independent authentication for different authentication requests, thereby avoiding the problem in the related technology that the entire application is authenticated and the failure of authentication of a certain module will cause the entire application to fail to run normally, thereby improving the authentication efficiency. Moreover, since each component is authenticated independently, even if one of the components is compromised, it will not affect the security of other components, thereby improving the overall security. BRIEF DESCRIPTION OF THE DRAWINGS

[0009] Figure 1 A flowchart of an authentication method based on an OpenHarmony device provided in an embodiment of the present invention; Figure 2 A framework diagram of an authentication method based on OpenHarmony devices provided in an embodiment of the present invention; Figure 3 An authentication flow chart of an authentication method based on OpenHarmony device provided in an embodiment of the present invention; Figure 4 An authentication schematic diagram of an authentication method based on an OpenHarmony device provided in an embodiment of the present invention; Figure 5 Another authentication schematic diagram of an authentication method based on an OpenHarmony device provided in an embodiment of the present invention; Figure 6A structural diagram of an authentication device based on OpenHarmony equipment provided in an embodiment of the present invention; Figure 7 A schematic diagram of the structure of an electronic device provided by an embodiment of the present invention. DETAILED DESCRIPTION

[0010] In order to make the technical problems, technical solutions and beneficial effects to be solved by the present application more clearly understood, the present application is further described in detail below in conjunction with the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are only used to explain the present application and are not used to limit the present application.

[0011] In the following description, specific details such as specific system structures, technologies, etc. are provided for the purpose of illustration rather than limitation, so as to provide a thorough understanding of the embodiments of the present application. However, it should be clear to those skilled in the art that the present application may also be implemented in other embodiments without these specific details. In other cases, detailed descriptions of well-known systems, devices, circuits, and methods are omitted to prevent unnecessary details from obstructing the description of the present application.

[0012] It should be understood that when used in the present specification and the appended claims, the term "comprising" indicates the presence of described features, wholes, steps, operations, elements and / or components, but does not exclude the presence or addition of one or more other features, wholes, steps, operations, elements, components and / or combinations thereof.

[0013] References to "one embodiment" or "some embodiments" etc. described in the specification of this application mean that one or more embodiments of the present application include specific features, structures or characteristics described in conjunction with the embodiment. Therefore, the statements "in one embodiment", "in some embodiments", "in some other embodiments", "in some other embodiments", etc. that appear in different places in this specification do not necessarily refer to the same embodiment, but mean "one or more but not all embodiments", unless otherwise specifically emphasized in other ways. The terms "including", "comprising", "having" and their variations all mean "including but not limited to", unless otherwise specifically emphasized in other ways.

[0014] In the related art, the entire application is authenticated as a whole. As long as one of the modules fails to be authenticated, the entire application cannot run normally. For example, there are components A and B in the application. When authenticating the application, if component A fails to be authenticated, the application authentication fails and the application cannot run normally. In addition, a main entrance centralized authentication method is adopted. All modules in the application are authenticated at the same entrance. As long as one module in the application is compromised, all modules are compromised at the same time. Moreover, the entire application is authorized during authorization. Only one copy of the authorization information exists in the application, and the authorization information is easy to obtain, and the overall security is low.

[0015] In order to solve the above problems, the present application provides an authentication method, apparatus and electronic device based on OpenHarmony devices. The following specifically introduces an authentication method based on OpenHarmony devices of the present application.

[0016] The authentication method based on OpenHarmony devices in this application can be used in the SDK component of the OpenHarmony device. The OpenHarmony device also includes an underlying OS and multiple upper-level application components. The OpenHarmony device includes multiple SDK components, and the upper-level application components and SDK components are designed in a distributed manner.

[0017] Please refer to Figure 2 The SDK component of this application is a bridge that provides interaction between the upper-layer application and the underlying OS. Its function is to provide the capabilities of the underlying OS to the upper-layer application and to authenticate the components called by the upper-layer application.

[0018] Among them, this application utilizes the componentization capability of the OpenHarmony device to design the SDK in a componentized manner, wherein the componentization design method is based on different authentication capabilities, and the different authentication capabilities can be determined based on the different capabilities of providing the underlying OS. For example, when the SDK needs to provide PINPAD capabilities for upper-layer applications to call, the corresponding SDK component can be a PINPAD component, and the PINPAD component can provide the PINPAD function of the underlying OS for upper-layer applications to call, and can authenticate the components called by the upper-layer applications. Therefore, the authentication capability of the PINPAD component is based on the authentication of the PINPAD function.

[0019] Also, please refer to Figure 2This application not only designs the SDK in a componentized way, but also designs the upper-layer application in a componentized way. The way this application designs the upper-layer application in a componentized way is based on the capabilities that the upper-layer application needs to call. For example, the upper-layer application initiates a payment and requires the PINPAD to enter a password. At this time, the upper-layer application will initiate a request to call the required PINPAD capabilities; and the upper-layer application also includes requests to call multiple other capabilities. For example, the upper-layer application simultaneously initiates a request for the IC card payment capability. Then for this upper-layer application, two upper-layer application components are included in this application, namely the PINPAD application component and the IC card application component.

[0020] Therefore, the present application can be based on the needs of practical applications, such as Figure 2 As shown, multiple SDK components include an IC card component, a PINPAD component, a magnetic card component, a contactless card component, and a face recognition component. These five components are independent of each other, and each module component independently manages its own authentication. Of course, the SDK components of this application are not limited to this, and also include other components. Similarly, the upper-level application of this application also includes multiple upper-level application components, such as an IC card application component, a PINPAD application component, a magnetic card application component, a contactless card application component, and a face recognition application component.

[0021] The present application can process authentication requests of multiple upper-layer application components at the same time. The specific method is to independently authenticate the authentication requests of the corresponding upper-layer application components through the corresponding SDK components, and it can be performed simultaneously, which is more efficient. At the same time, since each component is independently authenticated, the compromise of one component will not affect other components, greatly improving the overall security.

[0022] The following is a detailed description of the authentication method based on OpenHarmony devices in the present invention. Figure 1 , including steps S101 to S104.

[0023] Step S101: Obtain a call request from an upper-layer application component.

[0024] For example, obtain a request to invoke PINPAD capabilities.

[0025] Step S102: Obtain an authentication request according to the call request.

[0026] For example, an authentication request for a PINPAD application component is obtained according to a request to invoke a PINPAD capability.

[0027] Step S103: Acquire authentication capability, and use the authentication capability to authenticate the authentication request.

[0028] For example, if the upper-layer application component is a PINPAD component, the PINPAD authentication capability is obtained and the authentication request is authenticated using the PINPAD authentication capability. If the upper-layer application component is a face recognition component, the face recognition authentication capability is obtained and the authentication request is authenticated using the face recognition authentication capability.

[0029] Step S104: Return the authentication result.

[0030] In this way, the method of the present application is applied to the SDK component of the OpenHarmony device, which also includes an underlying OS and multiple upper-level application components. The OpenHarmony device includes multiple SDK components, and at least two of the multiple SDK components have different authentication capabilities. The upper-level application components and the SDK components are designed in a distributed manner. The SDK component of the present application obtains the call request of the upper-level application component, obtains the authentication request according to the call request, authenticates the authentication request by using the obtained authentication capability, and returns the authentication result. The distributed authentication is realized by the upper-level application component and SDK component with distributed design. The present application utilizes the capability of the OpenHarmony device, and componentizes the SDK component according to the authentication capability, and also componentizes the upper-level application. When performing authentication, the entire application is not authenticated. Instead, the SDK component is used to call different SDK components for independent authentication for different authentication requests, thereby avoiding the problem in the related technology that the entire application is authenticated and the failure of authentication of a certain module will cause the entire application to fail to run normally, thereby improving the authentication efficiency. Moreover, since each component is authenticated independently, even if one of the components is compromised, it will not affect the security of other components, thereby improving the overall security.

[0031] In one embodiment of the present application, step S101 includes: obtaining a call request of an upper-layer application component through an access interface.

[0032] In one embodiment of the present application, after step S104, it further includes: if the authentication result is successful, then the upper layer application component is allowed to be called. For example, the application calls the WeChat payment component, and the authentication result obtained after the WeChat payment authentication capability is used to authenticate the authentication request is successful, then the upper layer application is allowed to call the WeChat payment function of the underlying OS through the WeChat payment component.

[0033] In one embodiment of the present application, after step S104, it also includes: if the authentication result is a failure, determining the permission level of the upper-layer application component; obtaining the upper-layer application component after the authentication, and selecting an auxiliary authentication component from the upper-layer application component after the authentication, the permission level of the auxiliary authentication component is higher than or equal to the permission level of the upper-layer application component; using the auxiliary authentication component to perform auxiliary authentication on the authentication request to obtain an auxiliary authentication result.

[0034] In this way, when the traditional solution fails in authentication, the only way is to re-sign and authorize the APP. However, this application improves the success rate of authentication by assisting authentication with high-level components, and largely avoids the cumbersome process of re-signing and re-releasing the program due to authentication failure caused by signature reasons.

[0035] In one embodiment of the present application, an auxiliary authentication component is used to perform auxiliary authentication on an authentication request, and obtaining an auxiliary authentication result includes: using the auxiliary authentication component to obtain auxiliary authentication request information of an upper-layer application component; using the auxiliary authentication component to verify the upper-layer application component, and if the verification fails, no auxiliary authentication is performed on the upper-layer application component, and the authentication result is used as the auxiliary authentication result; if the verification passes, the upper-layer application component is authenticated according to the auxiliary authentication request information to obtain an auxiliary authentication result.

[0036] In one embodiment of the present application, the auxiliary authentication request information may include the application package name, the upper-layer application component name, the permission information that the upper-layer application component needs to apply for, and other business parameters.

[0037] In this way, when the upper-layer application component passes verification, the upper-layer application component is authenticated according to the auxiliary authentication request information, thereby ensuring the security of the auxiliary authentication.

[0038] In one embodiment of the present application, using the auxiliary authentication component to verify the upper-layer application component includes: using the auxiliary authentication component to determine whether the auxiliary authentication component and the upper-layer application component belong to the same application, and whether the permission level of the auxiliary authentication component is higher than or equal to the permission level of the upper-layer application component; if so, the verification passes; otherwise, the verification fails.

[0039] For example, the permission levels of upper-layer application component A, upper-layer application component B, upper-layer application component C, upper-layer application component D and upper-layer application component E are 1, 2, 3, 4 and 5 from high to low respectively. When upper-layer application component C fails to apply for permission on its own, upper-layer application component C can send auxiliary authentication request information to upper-layer application component A, and the auxiliary authentication request information includes the APP package name, the component name of upper-layer application component C, the permission information that upper-layer application component C needs to apply for from the SDK, and other business parameters; after receiving the request, the upper-layer application component A first determines whether the upper-layer application component C is in the same APP as the upper-layer application component A. If not in the same APP, the auxiliary authentication request is rejected. If they are in the same APP, it determines whether the permission level of the upper-layer application component C is equal to or less than the permission level of the upper-layer application component A. If so, the auxiliary authentication request is accepted, otherwise the auxiliary authentication request is rejected.

[0040] In this way, auxiliary authentication is allowed only when the auxiliary authentication component and the upper application component belong to the same application and the permission level of the auxiliary authentication component is higher than or equal to the permission level of the upper application component, thus ensuring the reliability of authentication.

[0041] In one embodiment of the present application, the method of the present application further includes: if the auxiliary authentication result is a failure, calling the upper-layer application component is not allowed; if the auxiliary authentication result is a success, calling the upper-layer application component is allowed.

[0042] For example, if the application is only for prepayment, it does not have the ability to call PINPAD for payment. If the application calls the PINPAD component, it will fail to pass the authentication.

[0043] In one embodiment of the present application, the authentication request includes signature information. The signature information may include the application package name, component name, module name, the type of permission applied for, the permission level applied for, and other business requirement information. In step S103, authenticating the authentication request using the authentication capability includes: authenticating the signature information using the authentication capability. In this way, each application component has its own signature information, and the signature information is authenticated using the authentication capability, which improves the efficiency and security of authentication.

[0044] In one embodiment of the present application, step S103 includes: obtaining multiple authentication capabilities, and using the multiple authentication capabilities to authenticate the authentication request at the same time. In this way, when multiple upper-layer application components need to be authenticated, multiple authentication capabilities can be used to authenticate at the same time. For example, if an application needs to call an Alipay payment component and a PINPAD component, the Alipay payment authentication capability can be used to authenticate the Alipay component, and the PINPAD authentication capability can be used to authenticate the PINPAD component, thereby achieving efficient authentication.

[0045] In one embodiment of the present application, it also includes: authorizing each upper-layer application component separately to obtain signature information; and storing the signature information in the corresponding upper-layer application component. In this way, after authorization, the signature information is stored in the corresponding upper-layer application component, which prevents the signature information from being easily obtained, improves flexibility and overall security, for example, there are components A, B, and C in the application, and components A, B, and C are authorized separately, and after authorization, each component stores its own signature information.

[0046] In one embodiment of the present application, it further includes: allocating a permission level to each upper layer application component. In this way, a permission level can be flexibly allocated to each upper layer application component as needed.

[0047] In one embodiment of the present application, assigning a permission level to each upper-layer application component includes: assigning a permission level to each upper-layer application component according to its importance. In this way, the more important the upper-layer application component is, the higher its permission level is, and the higher its security is. For example, there are 5 components in the application, and they are ranked from high to low in terms of importance as component A, component B, component C, component E, and component D. Then, according to the corresponding permission levels from high to low, they should be component A (level 1), component B (level 2), component C (level 3), component E (level 4), and component D (level 5), which effectively ensures the reliability of authentication.

[0048] In one embodiment of the present application, assigning a permission level to each upper-layer application component includes: determining the permission level of each upper-layer application component according to the sensitivity. In this way, the more sensitive information the upper-layer application component involves, the higher the permission level. For example, the PINPAD component involves the password part of the financial transaction, and the level is very high. The EMV component (the core component for smart card payment transaction processing) involves the card interaction of the financial transaction, and the level is also very high. Since there is basically no pure magnetic stripe card in bank cards, but there are many industry applications, the magnetic card component is relatively low in level. The printing component only prints tickets and does not involve sensitive information, and the relative level is also relatively low. The permission level of each upper-layer application component is determined by the sensitivity, which improves the overall security.

[0049] The following is a detailed description of the application examples of this application. This application can apply the above solution to scenarios where authentication is required. Please refer to Figure 3-Figure 5 .

[0050] In one embodiment of the present application, Figure 4 As shown, the following steps are included: (1) Obtain the call request from the upper-level APP component to access the SDK interface.

[0051] (2) Obtain an authentication request based on the call request.

[0052] (3) Obtain authentication capabilities, use the authentication capabilities to authenticate the authentication request, and return the authentication result.

[0053] (4) Determine whether the authentication result is passed. If passed, end the process and allow the upper-level APP component to access the SDK interface. If not, request a high-authority component to assist in authentication; (5) The high-authority component sends auxiliary authentication information to the SDK for auxiliary authentication.

[0054] In one embodiment of the present application, Figure 3 and Figure 5 As shown, the following steps are included: (1) Authorize each upper-layer application component separately and obtain signature information.

[0055] (2) Save the signature information in the corresponding upper-level application component.

[0056] (3) Assign permission levels to each upper-level application component.

[0057] (4) Obtain the call request of the upper-level application component.

[0058] (5) Obtain an authentication request based on the call request, which includes signature information.

[0059] (6) Obtain authentication capabilities and use the authentication capabilities to authenticate the signature information; (7) Return the authentication result.

[0060] (8) If the authentication result is successful, calling the upper-level application component is allowed.

[0061] (9) If the authentication result is a failure, the permission level of the upper-level application component is determined.

[0062] (10) Obtaining the upper-layer application component that has passed the authentication, and selecting an auxiliary authentication component from the upper-layer application component that has passed the authentication, wherein the permission level of the auxiliary authentication component is higher than or equal to the permission level of the upper-layer application component.

[0063] (11) Use the auxiliary authentication component to obtain the auxiliary authentication request information of the upper-level application component.

[0064] (12) Use the auxiliary authentication component to determine whether the auxiliary authentication component and the upper-layer application component belong to the same application, and whether the permission level of the auxiliary authentication component is higher than or equal to the permission level of the upper-layer application component. If both are true, authenticate the upper-layer application component according to the auxiliary authentication request information to obtain an auxiliary authentication result. Otherwise, do not perform auxiliary authentication on the upper-layer application component, and use the authentication result as the auxiliary authentication result.

[0065] (13) If the auxiliary authentication result is successful, calling the upper-level application component is allowed.

[0066] (14) If the auxiliary authentication result is a failure, calling the upper-level application component is not allowed.

[0067] The present invention also provides an authentication device based on OpenHarmony equipment. Figure 6 , including component calling module, request acquisition module, authentication module and result return module: The component calling module is used to obtain the calling request of the upper-layer application component; A request acquisition module is used to obtain an authentication request according to a call request; An authentication module is used to obtain authentication capabilities and use the authentication capabilities to authenticate authentication requests; The result return module is used to return the authentication result.

[0068] Please refer to Figure 7 The present invention also provides an electronic device 300, including a memory 301 and a processor 302, and a computer program stored in the memory 301 and running on the processor 302. When the processor 302 executes the computer program, the various steps in the authentication method based on the OpenHarmony device as described above are implemented.

[0069] The beneficial effects of the electronic device of the present invention are the same as those of the above method and will not be described in detail here.

[0070] To sum up, the present invention provides an authentication method, device and electronic device based on OpenHarmony device, which are applied to the SDK component of OpenHarmony device. The OpenHarmony device also includes an underlying OS and multiple upper-level application components. The OpenHarmony device includes multiple SDK components, at least two of the multiple SDK components have different authentication capabilities, and the upper-level application components and SDK components are designed in a distributed manner. The SDK component of this application obtains the call request of the upper-layer application component, obtains the authentication request according to the call request, authenticates the authentication request using the obtained authentication capability, and returns the authentication result. The distributed authentication is realized through the upper-layer application component and SDK component designed in a distributed manner. This application utilizes the capabilities of the OpenHarmony device, and componentizes the SDK component according to the authentication capability. At the same time, the upper-layer application is also componentized. When performing authentication, the entire application is not authenticated, but the SDK component is used to call different SDK components for independent authentication for different authentication requests, thereby avoiding the problem of authenticating the entire application in the related technology, and the failure of authentication of a certain module will cause the entire application to fail to run normally, thereby improving the authentication efficiency. Moreover, since each component is authenticated independently, even if one of the components is compromised, it will not affect the security of other components, thereby improving the overall security. At the same time, when multiple upper-layer application components need to be authenticated, multiple authentication capabilities can be used to authenticate simultaneously, thereby achieving efficient authentication. In addition, after the authentication fails, the authentication success rate is improved by assisting authentication with high-level components, which largely avoids the cumbersome process of re-signing and re-releasing the program due to authentication failure caused by signature reasons.

[0071] The above are only embodiments of the present invention, and are not intended to limit the patent scope of the present invention. Any equivalent transformations made using the contents of the specification and drawings of the present invention, or directly or indirectly applied in related technical fields, are also included in the patent protection scope of the present invention.

Claims

1. An authentication method based on OpenHarmony device, characterized in that: In an SDK component applied to an OpenHarmony device, the OpenHarmony device further includes an underlying OS and multiple upper-layer application components, the OpenHarmony device includes multiple SDK components, at least two of the multiple SDK components have different authentication capabilities, the upper-layer application component and the SDK component are designed in a distributed manner, and the method includes: Obtaining a call request of the upper layer application component; Obtaining an authentication request according to the calling request; Acquiring authentication capability, and authenticating the authentication request using the authentication capability; Returns the authentication result.

2. The authentication method based on OpenHarmony device according to claim 1, characterized in that: After the authentication result is returned, the method further includes: If the authentication result is a failure, determining the permission level of the upper layer application component; Acquire the upper layer application component after authentication, and select an auxiliary authentication component from the upper layer application component after authentication, wherein the authority level of the auxiliary authentication component is higher than or equal to the authority level of the upper layer application component; The auxiliary authentication component is used to perform auxiliary authentication on the authentication request to obtain an auxiliary authentication result.

3. The authentication method based on OpenHarmony device according to claim 1, characterized in that: The authentication request includes signature information; The using the authentication capability to authenticate the authentication request comprises: The signature information is authenticated using the authentication capability.

4. The authentication method based on OpenHarmony device according to claim 2, characterized in that: The using the auxiliary authentication component to perform auxiliary authentication on the authentication request to obtain an auxiliary authentication result includes: Using the auxiliary authentication component to obtain the auxiliary authentication request information of the upper layer application component; The auxiliary authentication component is used to verify the upper-layer application component. If the verification fails, the upper-layer application component is not auxiliary authenticated, and the authentication result is used as the auxiliary authentication result; if the verification passes, the upper-layer application component is authenticated according to the auxiliary authentication request information to obtain an auxiliary authentication result.

5. The authentication method based on OpenHarmony device according to claim 4, characterized in that: The verifying the upper layer application component by using the auxiliary authentication component includes: The auxiliary authentication component is used to determine whether the auxiliary authentication component and the upper-layer application component belong to the same application, and whether the permission level of the auxiliary authentication component is higher than or equal to the permission level of the upper-layer application component. If both are true, the verification passes, otherwise, the verification fails.

6. The authentication method based on OpenHarmony device according to claim 1, characterized in that: The acquiring of the authentication capability and authenticating the authentication request using the authentication capability includes: Acquire multiple authentication capabilities, and use the multiple authentication capabilities to authenticate the authentication request simultaneously.

7. The authentication method based on OpenHarmony device according to claim 1, characterized in that: Also includes: Authorizing each of the upper-layer application components separately to obtain signature information; The signature information is stored in the corresponding upper layer application component.

8. The authentication method based on OpenHarmony device according to claim 1, characterized in that: Also includes: A permission level is assigned to each of the upper layer application components.

9. An authentication device based on OpenHarmony equipment, characterized in that: Including component calling module, request acquisition module, authentication module and result return module: The component calling module is used to obtain the calling request of the upper layer application component; The request acquisition module is used to obtain an authentication request according to the call request; The authentication module is used to obtain authentication capabilities and use the authentication capabilities to authenticate the authentication request; The result returning module is used to return the authentication result.

10. An electronic device comprising a memory, a processor, and a computer program stored in the memory and running on the processor, wherein when the processor executes the computer program, each step of an authentication method based on an OpenHarmony device as described in any one of claims 1 to 8 is implemented.

Images