Control method for interface authentication, and electronic device, storage medium and chip system

Abstract

The embodiments of the present application relate to the technical field of terminals. Provided are a control method for interface authentication, and an electronic device, a storage medium and a chip system. The method comprises: when it is identified that an invocation permission of a certain application for a specific interface needs to be restricted or restored, a system application sending relevant information of the application and relevant information of the interface to an interface authorization management platform, and the interface authorization management platform sending the information to an electronic device, so as to instruct the electronic device to restrict or restore the invocation of the specific interface that is performed by the application. In this way, it is possible to quickly change an invocation permission of a certain application for an interface while a system application keeps an authentication interface unchanged, so as to realize the flexible control of interface authentication, thereby improving the efficiency of interface authentication.

Description

Interface authentication control methods, electronic devices, storage media and chip systems

[0001] This application claims priority to Chinese Patent Application No. 202510084490.6, filed on January 17, 2025, entitled "Control Method for Interface Authentication, Electronic Device, Storage Medium and Chip System", the entire contents of which are incorporated herein by reference. Technical Field

[0002] This application relates to the field of terminal technology, and in particular to a control method for interface authentication, electronic device, storage medium and chip system. Background Technology

[0003] System applications in electronic devices can implement certain functions and provide application programming interfaces (APIs) for other applications to use. For example, system applications can provide APIs for functions such as account management, network connectivity, and device control. Other applications can call the APIs provided by the system applications to achieve the relevant functions.

[0004] To ensure secure API calls, system applications can authenticate the applications calling the API. Some implementations may use local authentication or server authentication. However, local authentication may suffer from outdated authentication information, while server authentication is highly dependent on network conditions and the stability of cloud servers. Neither of these authentication methods offers flexible control over API authentication, resulting in low efficiency. Summary of the Invention

[0005] This application provides a control method, electronic device, storage medium, and chip system for interface authentication. When it is recognized that it is necessary to restrict or restore an application's access to a specific interface, the system application can send relevant information about the application and the interface to an interface authorization management platform, which then sends the information to the electronic device. This allows for flexible instruction to restrict or restore the application's access to a specific interface, improving the efficiency of interface authentication.

[0006] The first aspect provides a control method for interface authentication, the method including:

[0007] At a first moment, a first application of the electronic device calls the target interface of a second application of the electronic device and implements the target function based on the return result of the target interface. At a second moment, the electronic device receives first information, which indicates that the first application is prohibited from calling the target interface. At a third moment, the first application calls the target interface, and the electronic device, based on the first information, indicates that the target function cannot be implemented. The second moment is later than the first moment, and the third moment is later than the second moment. Between the first and third moments, neither the first nor the second application has updated its application version. Since neither the first nor the second application has updated its version, the electronic device can revoke the first application's permission to call the target interface based on the first information. This allows for the rapid revoke of the first application's permission to call the target interface while maintaining the same authentication interface for the system applications, achieving flexible control over target interface authentication and thus improving the efficiency of interface authentication.

[0008] In one possible implementation, at a fourth moment, the electronic device receives second information indicating permission for the first application to call the target interface; at a fifth moment, the first application calls the target interface and implements the target function based on the return result of the target interface; wherein the fourth moment is later than the third moment, and the fifth moment is later than the fourth moment, and neither the first nor the second application has updated its application version between the third and fifth moments. Even when neither the first nor the second application has updated its version, the electronic device, after disabling the first application's permission to call the target interface, can promptly restore the first application's permission to call the target interface based on the second information, thereby achieving flexible control over target interface authentication and improving the efficiency of interface authentication.

[0009] In one possible implementation, at a first moment, the electronic device includes target authorization information, which indicates that the first application has permission to call the target interface. At a third moment, the electronic device either does not contain target authorization information, or it does contain target authorization information, which indicates that the first application does not have permission to call the target interface. Based on the changes in the target authorization information, it is possible to quickly determine whether the first application has permission to call the target interface. It is understandable that using target authorization information to indicate whether the first application has permission to call the target interface achieves the purpose of message transmission more clearly and concisely, which is helpful for maintaining business logic and improving code execution efficiency.

[0010] In one possible implementation, the electronic device receives first information, including: the electronic device receiving first information from a server, wherein the server sends the first information to the electronic device based on first instruction information from a second application, the first instruction information including the identifier of the first application and information indicating that calling the target interface is prohibited; the electronic device receives second information, including: the electronic device receiving second information from the server, wherein the server sends the second information to the electronic device based on second instruction information from the second application, the second instruction information including the identifier of the first application and information indicating that calling the target interface is permitted. When it is recognized that the first application's calling permission to the target interface needs to be prohibited or restored, the second application can send relevant information of the first application and relevant information of the target interface to the server, and the server sends information to the electronic device, thereby instructing the first application to prohibit or restore its calling permission to the target interface. In this way, while keeping the target interface unchanged, the calling permission of the first application to the target interface can be quickly changed through server instruction, achieving flexible control of interface authentication.

[0011] In one possible implementation, the electronic device includes a first module and a second module. At a first moment, the first module stores target authorization information, which indicates that a first application has permission to call a target interface. After receiving the first information, the electronic device further includes: transmitting information from the second module to the first module indicating that the first application is prohibited from calling the target interface; updating the target authorization information based on the first module, whereby the first module either does not store the target authorization information or stores the target authorization information indicating that the first application does not have permission to call the target interface. After receiving the second information, the electronic device further includes: transmitting information from the second module to the first module indicating that the first application is allowed to call the target interface; updating the target authorization information based on the second module, whereby the first module stores the target authorization information indicating that the first application has permission to call the target interface. The first module can be used to update the authentication information for the first application calling the target interface, effectively improving the timeliness of interface authentication information updates. For revoked authentication information, this embodiment can also provide a recovery mechanism, enabling the first application to quickly restore its permission to call the target interface in scenarios such as accidental revocation, thereby reducing the impact of interface authentication on the application.

[0012] In one possible implementation, the electronic device further includes a third module. At a third moment, after the first application calls the target interface, the module further includes: the second application transmitting the identifier of the first application and a target identifier to the third module, the target identifier indicating the authorization identifier required to call the target interface; the third module transmitting the identifier of the first application to the first module; the first module returning third information to the third module based on the identifier of the first application; if the third information indicates that target authorization information is not stored, or that the target authorization information does not match the target identifier, the third module returning information to the second application indicating that the first application does not have permission to call the target interface; and the second application returning information to the first application indicating that the target interface call failed. If the interface authentication module obtains target authorization information indicating that the first application does not have the target interface, or if the target authorization information obtained by the interface authentication module does not match the target identifier, it indicates that the first application does not have permission to call the target interface, i.e., the interface authentication of the first application calling the target interface fails. The interface authentication module can instruct the second application to return information indicating that the target interface call failed to the first application. This prohibits the first application from calling the target interface, achieving interface access control.

[0013] In one possible implementation, at the fifth moment, after the first application calls the target interface, the process further includes: the second application passing the identifier of the first application and the target identifier to the third module; the third module passing the identifier of the first application to the first module; the first module returning target authorization information to the third module based on the identifier of the first application; if the target authorization information matches the target identifier, the third module returning information to the second application indicating that the first application has permission to call the target interface; and the second application returning the call result of the target interface to the first application. If the target authorization information of the first application matches the target identifier, it indicates that the first application has permission to call the target interface, meaning that the interface authentication of the first application calling the target interface is successful. The interface authentication module can then instruct the second application to return the call result of the target interface to the first application. This allows the first application to call the target interface, thus implementing interface access control.

[0014] In one possible implementation, the first and / or second instruction information also includes the version information of the first application. When the version of the first application changes, the second application can authenticate the target interface called by the first application to determine whether the changed version of the first application has permission to call the target interface. This allows for the revocation or restoration of the target interface for a specific version of the first application, thereby enabling separate management of interface authentication for different versions of the same application.

[0015] In one possible implementation, at the fifth moment, the first application is version one. The method further includes: at the sixth moment, the electronic device receives third information indicating that version one of the first application is prohibited from calling the target interface; the sixth moment is later than the fifth moment. At the seventh moment, the first application calls the target interface, and the electronic device indicates, based on the third information, that the target function cannot be achieved; the seventh moment is later than the sixth moment. At the eighth moment, the electronic device upgrades the first application from version one to version two; the eighth moment is later than the seventh moment. At the ninth moment, the upgraded first application calls the target interface and achieves the target function based on the return result of the target interface; the ninth moment is later than the eighth moment. The third information includes the version information of the first application. This allows for separate management of interface authentication for different versions of the same application, thereby achieving more refined interface authentication control and reducing the impact of revoking interface usage permissions on the application.

[0016] Secondly, embodiments of this application provide an interface authentication control device, which may be an electronic device, a chip or chip system within an electronic device. The device may include a processing unit. The processing unit is used to implement any processing-related method executed by the electronic device in the first aspect or any possible implementation of the first aspect. When the device is an electronic device, the processing unit may be a processor. The device may also include a storage unit, which may be a memory. The storage unit is used to store instructions, and the processing unit executes the instructions stored in the storage unit to cause the electronic device to implement the method described in the first aspect or any possible implementation of the first aspect. When the device is a chip or chip system within an electronic device, the processing unit may be a processor. The processing unit executes the instructions stored in the storage unit to cause the electronic device to implement the method described in the first aspect or any possible implementation of the first aspect. The storage unit may be a storage unit within the chip (e.g., a register, cache, etc.), or a storage unit located outside the chip within the electronic device (e.g., read-only memory, random access memory, etc.).

[0017] Thirdly, embodiments of this application provide an electronic device including one or more processors and a memory, the memory being coupled to one or more processors, the memory being used to store computer program code, the computer program code including computer instructions, and one or more processors being used to invoke the computer instructions to perform the method described in the first aspect or any possible implementation of the first aspect.

[0018] Fourthly, embodiments of this application provide a computer-readable storage medium storing a computer program or instructions that, when executed on a computer, cause the computer to perform the methods described in the first aspect or any possible implementation thereof.

[0019] Fifthly, embodiments of this application provide a computer program product including a computer program, which, when run on a computer, causes the computer to perform the methods described in the first aspect or any possible implementation of the first aspect.

[0020] Sixthly, this application provides a chip or chip system including at least one processor and a communication interface. The communication interface and the at least one processor are interconnected via a circuit. The at least one processor is used to run computer programs or instructions to perform the methods described in the first aspect or any possible implementation of the first aspect. The communication interface in the chip can be an input / output interface, pins, or circuits, etc.

[0021] In one possible implementation, the chip or chip system described above in this application further includes at least one memory storing instructions. The memory can be an internal storage unit of the chip, such as a register or cache, or it can be a storage unit of the chip itself (e.g., read-only memory, random access memory, etc.).

[0022] It should be understood that the second to sixth aspects of this application correspond to the technical solutions of the first aspect of this application, and the beneficial effects achieved by each aspect and the corresponding feasible implementation are similar, and will not be repeated here. Attached Figure Description

[0023] Figure 1 is a schematic diagram of a local interface authentication provided in an embodiment of this application;

[0024] Figure 2 is a schematic diagram of the hardware structure of an electronic device provided in an embodiment of this application;

[0025] Figure 3 is a schematic diagram of the software structure of an electronic device provided in an embodiment of this application;

[0026] Figure 4 is a flowchart illustrating an interface authentication control method provided in an embodiment of this application;

[0027] Figure 5 is a schematic diagram of an interface authentication control method provided in an embodiment of this application;

[0028] Figure 6 is a schematic diagram of the structure of a chip provided in an embodiment of this application. Detailed Implementation

[0029] To facilitate a clear description of the technical solutions in the embodiments of this application, some terms and technologies involved in the embodiments of this application will be briefly introduced below:

[0030] 1. Terminology

[0031] In the embodiments of this application, terms such as "first" and "second" are used to distinguish identical or similar items with substantially the same function and purpose. For example, "first chip" and "second chip" are used only to distinguish different chips and do not limit their order of execution. Those skilled in the art will understand that terms such as "first" and "second" do not limit the quantity or execution order, and that "first" and "second" do not necessarily imply that they are different.

[0032] It should be noted that, in the embodiments of this application, the terms "exemplary" or "for example" are used to indicate examples, illustrations, or descriptions. Any embodiment or design scheme described as "exemplary" or "for example" in this application should not be construed as being more preferred or advantageous than other embodiments or design schemes. Specifically, the use of terms such as "exemplary" or "for example" is intended to present the relevant concepts in a specific manner.

[0033] In this application embodiment, "at least one" refers to one or more, and "more than one" refers to two or more. "And / or" describes the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can represent: A alone, A and B simultaneously, or B alone, where A and B can be singular or plural. The character " / " generally indicates that the preceding and following related objects are in an "or" relationship. "At least one of the following" or similar expressions refer to any combination of these items, including any combination of single or plural items. For example, at least one of a, b, or c can represent: a, b, c, ab, ac, bc, or abc, where a, b, and c can be single or multiple.

[0034] System applications in electronic devices can implement certain functions and provide APIs for using these functions, which can then be called by other applications. For example, system applications can provide APIs for functions such as account management, network connection, and device control. Other applications can call the APIs provided by the system applications to implement related functions. These other applications can include any application installed on the electronic device; for example, other applications can be system applications or third-party applications, and this application embodiment does not impose any limitations.

[0035] To ensure secure API calls, system applications can authenticate the applications calling the API. In some implementations, API authentication can be either local or server-side. For ease of description, the following example illustrates local and server-side authentication in a scenario where a system application provides an account management API, and a third-party application calls this API for account management.

[0036] In some implementations, as shown in Figure 1, the system application can perform local authentication on the account interface called by the third-party application.

[0037] For example, before a third-party application calls the system application's account interface, the third-party application can apply for permission to use the account interface on the interface authorization management platform. The interface authorization management platform can manage the authorization of the interfaces called by the application; for example, it can enable or disable the application's permission to use the interface. In some scenarios, the interface authorization management platform may also be called an API authorization management platform, the system application may be called an interface provider or an interface provider application, and the third-party application may be called an interface caller or an interface caller application; this embodiment of the application does not impose such limitations.

[0038] After enabling third-party applications to use the account interface on the interface authorization management platform, the platform can return an authorization identifier to the third-party application. This identifier indicates that the third-party application has the permission to call the account interface. When the third-party application calls the system application's account interface, the system application can invoke the authentication module to check whether the third-party application has the permission to call the account interface. The authentication module provides interface authentication capabilities.

[0039] The authentication module can obtain authorization information from third-party applications and permission identifiers for account interfaces provided by the system application. The authorization information from third-party applications may include the authorization identifier for the account interface. The permission identifier for the account interface provided by the system application can also be understood as the permission identifier corresponding to the account interface expected by the system application. To clearly distinguish it from the authorization identifier of third-party applications, the permission identifier provided by the system application will be uniformly referred to as the expected authentication identifier.

[0040] The authentication module can compare the authorization identifier of the third-party application with the expected authentication identifier to determine whether the third-party application has the permission to call the account interface.

[0041] If the authorization identifier matches the expected authentication identifier, it indicates that the third-party application has the permission to call the account interface, meaning the third-party application's call to the account interface has been successfully authenticated. The authentication module can then return information to the system application indicating successful interface authentication. Furthermore, the system application can allow the third-party application to call the account interface. It is understood that matching the authorization identifier and the expected authentication identifier can include the authorization identifier and the expected authentication identifier being the same, or it can include a corresponding relationship between the authorization identifier and the expected authentication identifier, etc., and this embodiment does not limit the scope.

[0042] If the authorization identifier and the expected authentication identifier do not match, it means that the third-party application does not have permission to call the account interface, i.e., the third-party application's attempt to call the account interface fails. In this case, the authentication module can return information to the system application indicating the interface authentication failure. Consequently, the system application will not allow the third-party application to call the account interface. It is understood that a mismatch between the authorization identifier and the expected authentication identifier may include the authorization identifier and the expected authentication identifier being different, or it may include the authorization identifier and the expected authentication identifier not having a corresponding relationship, etc., and this application embodiment does not limit this.

[0043] In other implementations, the system application can perform server authentication on the account interfaces called by third-party applications.

[0044] Server authentication can employ various methods such as Open Authorization (OAuth), JSON Web Token (JWT), and Hash-based Message Authentication Code (HMAC). In some scenarios, cloud servers may also be referred to as authentication servers or authorization servers.

[0045] For example, when a third-party application calls the account interface, the electronic device is redirected to the authorization server and requests user authorization. After user authorization, the authorization server generates an authorization code and returns it to the third-party application. The third-party application then sends the authorization code, the device identifier (ID), and a key to the authorization server. The authorization server verifies the authorization code, device ID, and key, and issues an access token to the third-party application upon successful verification. The third-party application can then use the access token to request access to the system application's account interface. The device identifier and key are provided by the authorization server to the third-party application during its registration with the authorization server.

[0046] However, on the one hand, local authentication may suffer from outdated authentication information. If the authentication information changes, the system application and / or third-party applications need to release new versions, and users must upgrade to the new versions before the third-party applications can access the system application's interfaces normally. On the other hand, server authentication is highly dependent on the network environment and the stability of the cloud server. If the cloud server malfunctions, third-party applications cannot call the system application's interfaces. Furthermore, the authentication process between electronic devices and the cloud server is time-consuming, resulting in poor performance for server authentication.

[0047] In view of this, embodiments of this application provide a method for controlling interface authentication. When it is recognized that it is necessary to restrict or restore an application's access to a specific interface, the system application can send relevant information about the application and the interface to an interface authorization management platform. The interface authorization management platform then sends information to the electronic device, thereby instructing to restrict or restore the application's access to the specific interface. This allows for rapid changes to an application's access to an interface while keeping the authentication interface unchanged, achieving flexible control over interface authentication and improving its efficiency.

[0048] It is understood that the electronic device in the embodiments of this application can also be any form of terminal device. For example, the electronic device may include: mobile phone, tablet computer, handheld computer, laptop computer, mobile internet device (MID), wearable device, virtual reality (VR) device, augmented reality (AR) device, wireless terminal in industrial control, wireless terminal in self-driving, wireless terminal in remote medical surgery, wireless terminal in smart grid, wireless terminal in transportation safety, wireless terminal in smart city, wireless terminal in smart home, cellular phone, cordless phone, session initiation protocol (SIP) phone, wireless local loop (WLL) station, personal digital assistant (PDA), handheld device, computing device or other processing device connected to a wireless modem, vehicle-mounted device, electronic device in 5G network, or future evolved public land mobile communication network. The embodiments of this application do not limit the scope of electronic devices in a network (PLMN).

[0049] Furthermore, in this application embodiment, the electronic device can also be an electronic device in the Internet of Things (IoT) system. IoT is an important part of the future development of information technology. Its main technical feature is to connect objects to the network through communication technology, thereby realizing an intelligent network of human-machine interconnection and object-to-object interconnection.

[0050] The electronic equipment in the embodiments of this application may also be referred to as: user equipment (UE), mobile station (MS), mobile terminal (MT), access terminal, user unit, user station, mobile station, mobile station, remote station, remote terminal, mobile device, user terminal, terminal, wireless communication equipment, user agent, or user device, etc.

[0051] In this embodiment, the electronic device includes a hardware layer, an operating system layer running on top of the hardware layer, and an application layer running on the operating system layer. The hardware layer includes hardware such as a central processing unit (CPU), a memory management unit (MMU), and main memory. The operating system can be any one or more computer operating systems that implement business processing through processes, such as Linux, Unix, Android, iOS, or Windows. The application layer includes applications such as browsers, address books, word processing software, and instant messaging software.

[0052] For example, Figure 2 shows a schematic diagram of the hardware structure of an electronic device.

[0053] The electronic device may include a processor 210, an external memory interface 220, an internal memory 221, a universal serial bus (USB) interface 230, a charging management module 240, a power management module 241, a battery 242, an antenna 1, an antenna 2, a mobile communication module 250, a wireless communication module 260, an audio module 270, a speaker 270A, a receiver 270B, a microphone 270C, a headphone jack 270D, a sensor module 280, buttons 290, a motor 291, an indicator 292, a camera 293, a display screen 294, and a subscriber identification module (SIM) card interface 295, etc. The sensor module 280 may include a pressure sensor 280A, a gyroscope sensor 280B, a barometric pressure sensor 280C, a magnetic sensor 280D, an accelerometer sensor 280E, a distance sensor 280F, a proximity light sensor 280G, a fingerprint sensor 280H, a temperature sensor 280J, a touch sensor 280K, an ambient light sensor 280L, a bone conduction sensor 280M, etc.

[0054] It is understood that the structures illustrated in the embodiments of this application do not constitute a specific limitation on the electronic device. In other embodiments of this application, the electronic device may include more or fewer components than illustrated, or combine some components, or split some components, or have different component arrangements. The illustrated components may include hardware, software, or a combination of software and hardware.

[0055] Processor 210 may include one or more processing units. For example, processor 210 may include an application processor (AP), a modem processor, a graphics processing unit (GPU), an image signal processor (ISP), a controller, a video codec, a digital signal processor (DSP), a baseband processor, and / or a neural network processing unit (NPU). Different processing units may be independent devices or integrated into one or more processors. The controller can generate operation control signals based on instruction opcodes and timing signals to control instruction fetching and execution.

[0056] The processor 210 may also include a memory for storing instructions and data. In some embodiments, the memory in the processor 210 is a cache memory. This memory can store instructions or data that the processor 210 has just used or that are used repeatedly. If the processor 210 needs to use the instruction or data again, it can directly retrieve it from the aforementioned memory. This avoids repeated access, reduces the waiting time of the processor 210, and thus improves the efficiency of the system. For example, in the embodiments of this application, the processor 210 can be used for interface calls and interface authentication, and can also be used to update the authentication information of the interface, etc.

[0057] Internal memory 221 can be used to store executable program code, including instructions. Internal memory 221 may include a program storage area and a data storage area. The program storage area may store the operating system, at least one application program required for a function, etc. The data storage area may store data created during the use of the electronic device, etc. Furthermore, internal memory 221 may include high-speed random access memory, and may also include non-volatile memory, such as at least one disk storage device, flash memory device, universal flash storage (UFS), etc. Processor 210 executes various functional applications and data processing of the electronic device by running instructions stored in internal memory 221 and / or instructions stored in memory located in the processor. For example, in this embodiment, internal memory 221 may be used to store interface permission identifiers, application configuration files, and related code for application authentication information, etc.

[0058] Figure 3 is a schematic diagram of the software structure of an electronic device according to an embodiment of this application.

[0059] A layered architecture divides the software structure into several layers, each with a clear role and function. Layers communicate with each other through software interfaces. The following uses the HarmonyOS system as an example to illustrate the software structure of an electronic device related to the embodiments of this application. This software structure may include an application layer, a core framework, application services, and core services.

[0060] The application layer, also known as the application layer, can include a series of applications. These applications can include system applications and third-party applications.

[0061] The core framework provides the basic framework and functionality required for application development, such as account management and push notifications. It can include a mobile service framework (Kit Framework), which provides APIs, software development kits (SDKs), and services. The APIs provided by the mobile service framework can include public APIs and / or system APIs. Public APIs can be called by third-party applications and system applications within the electronic device, while system APIs can be called by system applications within the electronic device. For example, application-layer applications can call the APIs provided by the mobile service framework to implement functions, thereby providing users with various capabilities and services.

[0062] Application services can provide services such as push notifications and account services to support application development, management, and operation. An application service may include at least one application package (Kit harmonyOS ability package, Kit HAP). The application package can provide capabilities to the outside world through the mobile service framework for other applications to call. In some scenarios, the application package can also be understood as a system application. Optionally, some application packages that are not visible to users can reside in the application service; some application packages that are visible to users can reside in the application layer. Whether the specific application package resides in the application layer or the application service is not limited in this embodiment.

[0063] The core services provide the basic services required for application development, such as device management and security services, supporting application creation and optimization. For example, in this embodiment, the core services can be used for interface authentication management and application package management. The core services may include application system capabilities (Kit system ability, Kit SA), interface authentication modules, app gallery connect system capabilities (AGC SA), and application package management services (BMS), etc.

[0064] Application system capabilities can be used to provide certain system capabilities within core services to achieve modular and distributed management of system services. It can be understood that each application system capability can be viewed as an independent service unit, providing specific system functions or services, such as audio management, network connectivity, and device control. In this embodiment, application system capabilities can be used to provide capabilities related to account management. In some implementations, application system capabilities can be used in conjunction with a mobile service framework to implement certain functions. For example, the interfaces provided by application system capabilities can reside within the mobile service framework. In other words, application system capabilities can be used to implement specific functions, and the mobile service framework can be used to provide interfaces for these functions to be called by other applications.

[0065] An interface authentication module can be used to verify the identity of an application. For example, in this embodiment, the interface authentication module can be used for interface authentication management. After being authorized by the interface authentication module, the application can make interface calls. In some scenarios, the interface authentication module can also be called an API authentication module.

[0066] The application marketplace connection service system capabilities can also be referred to as application marketplace connection service system components. These capabilities can obtain information from the application marketplace connection service and provide support for the package management service. The application marketplace connection service can be a service deployed on a cloud server. It can manage application creation, service activation, and authorization management for API calls made by applications. For example, in this embodiment, the application marketplace connection service can be used for application profile requests and activation of APIs corresponding to application system capabilities.

[0067] Application package management service, also known as package management service or package manager, is responsible for managing application information, including managing application installation, updates, uninstallation, and permission management.

[0068] It should be noted that this application uses the HarmonyOS system as an example for illustration. In other operating systems (e.g., system, system, Any system (or similar system) can achieve the solution of this application as long as the functions implemented by each functional module are similar to those in the embodiments of this application.

[0069] For example, the application layer mentioned above can also correspond to the application layer in the Android system. The application package management service mentioned above can also correspond to the package manager service (PMS) in the Android system. The functions implemented by the core framework and core services can correspond to the relevant functions implemented by the application framework layer and / or system libraries in the Android system. In some implementations, the application market connection service can also be called the interface authorization management platform. That is to say, the module names involved in the embodiments of this application can all be defined as other names, as long as they can realize the function of each module, and no specific restrictions are placed on the module names.

[0070] For example, the interface authentication control method provided in the embodiments of this application is described below with reference to Figure 3.

[0071] Application packages or application system capabilities can provide interfaces for specific functions through the Mobile Services Framework, allowing other applications to call them. Taking an application package as an example, suppose a third-party application has granted permission to call the application package's interface on the application marketplace connection service. When the third-party application calls the interface provided by the Mobile Services Framework, the application package can authenticate the interface called by the third-party application through its interface authentication module. Optionally, if using application system capabilities as an example, the specific implementation method can refer to the implementation process of the application package, which will not be elaborated further.

[0072] When an application package identifies a third-party application as malicious, it can send the application's application identifier and interface authentication revocation information to the application marketplace connection service. The application identifier can be used to uniquely identify the third-party application. For example, the application identifier may include information such as application ID (AppId), user ID (UID), application package name, and / or application name, etc., which are not limited in this embodiment.

[0073] The application marketplace connection service can send information to the application marketplace connection service system capabilities in electronic devices, indicating that interface permissions are to be revoked. Upon receiving the revocation information, the application marketplace connection service system capabilities can instruct the package management service to refresh the interface permission information.

[0074] When a third-party application calls this interface, the application package can use the interface authentication module to verify the interface permissions called by the third-party application. The interface authentication module can query the package management service to obtain the updated interface permissions of the third-party application. Understandably, since the updated interface permissions of the third-party application have been revoked, the interface authentication module can return an authentication failure result to the application package. Furthermore, the application package can use the mobile service framework to return an interface call failure message to the third-party application.

[0075] Understandably, when it's necessary to restore the interface permissions of a revoked third-party application, the application package can similarly send the application's identifier and interface authentication restoration information to the application marketplace connection service. The application marketplace connection service can then send information indicating the interface permissions to be restored to its system capabilities. Upon receiving the restoration information, the application marketplace connection service system capabilities can instruct the package management service to refresh the interface permission information.

[0076] When a third-party application calls this interface, the application package can use the interface authentication module to verify the interface permissions called by the third-party application. The interface authentication module can query the package management service to obtain the updated interface permissions of the third-party application. Understandably, since the updated interface permissions of the third-party application have been restored, the interface authentication module can return a successful authentication result to the application package. Furthermore, the application package can return the interface call result to the third-party application through the mobile service framework.

[0077] The interface authentication control method provided in this application embodiment can quickly update the authentication information of application calls to interfaces, effectively improving the timeliness of interface authentication information updates. For revoked authentication information, this application embodiment can also provide a recovery mechanism, so that in scenarios such as accidental revocation, the application's permission to call interfaces can be quickly restored, thereby reducing the impact of interface authentication on the application.

[0078] The methods of this application will be described in detail below through specific embodiments. The following embodiments can be combined with each other or implemented independently, and the same or similar concepts or processes may not be described again in some embodiments.

[0079] For ease of description, the following example illustrates the implementation process of the interface authentication control method in this application embodiment, using the scenario where the application package (Kit HAP) provides the account management function corresponding to the account interface and a third-party application calls the account interface for account management.

[0080] Optionally, the account management function and the corresponding account interface can also be provided by the system application at the application layer or the application system capability (Kit SA) of the core service, which is not limited in this embodiment.

[0081] Optionally, the application that calls the account interface of the application package can be a third-party application or a system application; this application embodiment does not limit this.

[0082] It should be noted that the account interface provided by the application package may include one or more APIs related to account management. For secure calls to the account interface, the application package can perform authentication control on third-party applications. Of course, the application package may also provide interfaces for other functions; this embodiment only uses the account function as an example for illustration and does not limit the specific functions provided by the application package.

[0083] Figure 4 shows a flowchart of the interface authentication control method according to an embodiment of this application.

[0084] The interface authentication control method in this application involves the interaction between an electronic device and a cloud server. On the electronic device side, it involves modules such as an application (e.g., a third-party application), a mobile service framework, an application package, an interface authentication module, a package management service, and an application market connection service system. On the cloud server side, it involves an application market connection service. Detailed descriptions of the functions of each module can be found in the relevant descriptions in the corresponding embodiments of Figure 3, and will not be repeated here.

[0085] The interface authentication control method may include (1) an interface authentication activation and invocation process, (2) an interface authentication revocation process, and (3) an interface authentication recovery process. For example, the interface authentication activation and invocation process may include the following steps S401 to S412, the interface authentication revocation process may include the following steps S413 to S425, and the interface authentication recovery process may include the following steps S426 to S439.

[0086] It is understood that the processes or steps in the corresponding embodiment of Figure 4 do not necessarily have to be executed sequentially. This application does not limit the execution order of steps S401 to S439, as long as the interface authentication control method can be implemented. For example, the execution order of steps S416 and S417, and steps S429 to S430, is not strictly distinguished.

[0087] (1) Interface authentication activation and invocation process.

[0088] S401. The third-party application requests account interface permissions from the application market connection service and updates the profile file.

[0089] Before a third-party application calls the account interface of the application package, the third-party application can apply for permission to use the account interface through the application market connection service.

[0090] After the application market connection service enables third-party applications to use the account interface, step S402 can be executed.

[0091] S402. The application market connection service returns authorization information for the account interface to third-party applications.

[0092] The application marketplace connection service can return a profile file to third-party applications. This profile file can be understood as the third-party application's configuration file. It may include information related to the third-party application, such as permissions and signing certificates. For example, in this embodiment, the profile file may include an authorization identifier for the third-party application to use the account interface, which can be used to identify that the third-party application has permission to call the account interface.

[0093] Optionally, the data type of the authorization identifier can include integer, string, boolean, etc. Taking a boolean data type as an example, a value of true indicates that the third-party application has permission to call the account interface, while a value of false indicates that the third-party application does not have permission to call the account interface. Alternatively, taking an integer data type as an example, a value of 1 indicates that the third-party application has permission to call the account interface, while a value of 0 or -1 indicates that the third-party application does not have permission to call the account interface. Of course, the authorization identifier can also be of other data types and set to other values; this embodiment does not limit the specific value of the authorization identifier.

[0094] S403. Third-party applications call the account interface provided by the mobile service framework.

[0095] If a third-party application successfully requests permission to call the account interface, it can then call the account interface provided by the mobile service framework. The mobile service framework can then execute step S404.

[0096] S404, Mobile Services Framework calls the account interface of the application package.

[0097] S405. The application package transmits the expected authentication identifier corresponding to the account interface and the application identifier of the third-party application to the interface authentication module.

[0098] The application package can obtain the expected authentication identifier corresponding to the account interface, and can also obtain the application identifier of the third-party application through the mobile service framework. This application identifier can be used to uniquely identify the third-party application, and may include information such as AppId, UID, application package name, and / or application name.

[0099] After obtaining the expected authentication identifier and the application identifier of the third-party application, the application package can pass the expected authentication identifier and the application identifier of the third-party application to the interface authentication module, so that the interface authentication module can query whether the third-party application has the permission to call the account interface. The interface authentication module can then execute step S406.

[0100] S406. The interface authentication module obtains the authorization identifier of the third-party application's account interface from the package management service.

[0101] The interface authentication module can request the authorization identifier of the third-party application's account interface from the package management service based on the application identifier of the third-party application, so as to compare it with the expected authentication identifier later.

[0102] S407, Package Management Service queries the authorization identifier of the account interface of third-party applications.

[0103] It is understandable that during the installation of third-party applications onto electronic device systems, the package management service can parse and save the metadata in the corresponding software packages of the third-party applications, such as the application name, package name, version number, and signature information of the third-party applications. For example, in this embodiment, the package management service can save the interface permission information corresponding to the account interface used by the third-party applications, that is, the authorization identifier of the account interface used by the third-party applications.

[0104] When the package management service receives the request information from the interface authentication module, it can query the authorization identifier of the third-party application's account interface from the cache. If the package management service can find the authorization identifier of the third-party application's account interface, it can proceed to step S408.

[0105] S408. The package management service returns the authorization identifier of the third-party application's account interface to the interface authentication module.

[0106] S409. The interface authentication module determines whether the expected authentication identifier is consistent with the authorization identifier of the third-party application.

[0107] After obtaining the authorization identifier of the third-party application's account interface, the interface authentication module can compare it with the expected authentication identifier.

[0108] If the authorization identifier of the third-party application matches the expected authentication identifier, it means that the third-party application has the permission to call the account interface, that is, the interface authentication of the third-party application calling the account interface is successful, and the interface authentication module can execute step S410. The matching of the authorization identifier and the expected authentication identifier may include the authorization identifier and the expected authentication identifier being the same, or it may include the authorization identifier and the expected authentication identifier having a corresponding relationship. This embodiment of the application does not limit it.

[0109] If the authorization identifier of the third-party application does not match the expected authentication identifier, it means that the third-party application does not have the permission to call the account interface, that is, the third-party application fails to authenticate the account interface. In this case, the interface authentication module can return information to the application package to indicate that the account interface authentication has failed.

[0110] S410, The interface authentication module returns information to the application package indicating that the account interface authentication was successful.

[0111] If the interface authentication module determines that the third-party application has permission to call the account interface, the interface authentication module can return information to the application package to indicate that the account interface authentication was successful.

[0112] S411, The application package returns the account interface call result to the mobile service framework.

[0113] S412, The mobile service framework returns the account interface call result to the third-party application.

[0114] If the application package successfully authenticates the third-party application's call to the account interface, it can return the call result to the third-party application through the mobile service framework. The third-party application can then implement related functions based on this call result; for example, it can display the call result on the interface or apply it to other scenarios. This embodiment of the application does not impose any limitations on this.

[0115] (2) The process of revoking the interface authentication.

[0116] S413. The application package sends the account interface authentication revocation information of the third-party application to the application market connection service.

[0117] In a possible implementation, the electronic device or app store connection service can obtain the number of calls made by third-party applications to the account interface. For example, if the electronic device detects a surge in calls to the account interface from a third-party application—for instance, if the number of calls reaches the maximum threshold for the number of calls within a short period—the electronic device can pass this event to the application package. The application package can then identify the third-party application as malicious.

[0118] When an application package identifies a third-party application as malicious, it can send information to the application marketplace connection service indicating that the interface permissions should be revoked.

[0119] Optionally, the application package can indicate the information regarding the revocation of interface permissions by sending an application list. This application list may include revocation information for account interface authentication of third-party applications. It is understood that the application list may include revocation information for interface authentication of multiple applications, multiple interface authentication revocation information of a single application, or revocation information for interface authentication of different versions of a single application; this embodiment of the application does not impose such limitations. The revocation information may include the application identifier of the third-party application, the name of the account interface to be revoked, etc.

[0120] Optionally, the revocation information may also include the version information of the third-party application, thereby revoking the account interface for a specific version of the third-party application. In this way, the interface authentication control method of this application embodiment can achieve separate management of interface authentication for different versions of the same application, thereby achieving more refined interface authentication control and reducing the impact of revoking interface usage permissions on the application.

[0121] S414. The App Store Connection Service sends the revocation information to the App Store Connection Service system capability.

[0122] In one possible implementation, the application marketplace connection service can send the revocation information to the application marketplace connection service system capability via a push channel. This allows the application marketplace connection service to promptly send a push notification to the electronic device upon receiving the revocation information, facilitating timely data updates. Of course, the application marketplace connection service and the electronic device can also communicate through other methods, such as based on the WebSocket protocol, HTTP protocol, MQTT protocol, or by establishing a polling mechanism; this embodiment of the application does not limit the scope of such communication.

[0123] S415, The application marketplace connection service system's capability to transmit the revocation information to the package management service.

[0124] Optionally, the application marketplace connection service system can also transmit the revocation information to the interface authentication module. The interface authentication module can save the revocation information. When authentication of a third-party application's account interface is required, the interface authentication module can check whether the third-party application's interface revocation information is saved. If the third-party application's interface revocation information exists, it means that the third-party application does not have permission to call the account interface, i.e., the interface authentication for the third-party application to call the account interface fails, and the interface authentication module can then execute step S423.

[0125] S416. Package management service updates the authentication information of third-party application account interfaces.

[0126] When the package management service obtains information indicating the revocation of account interface authentication for a third-party application, it can locate the corresponding third-party application and remove the authorization identifier from the account interface. Removing the authorization identifier can include deleting it, modifying its value, or replacing it with another identifier. This other identifier can be used to indicate that the account interface is not authorized, meaning the third-party application does not have permission to call the account interface.

[0127] For example, taking the deletion of this authorization identifier as an example, when the third-party application's account interface has this authorization identifier, it indicates that the third-party application has the permission to call the account interface. When the third-party application's account interface does not have this authorization identifier, it indicates that the third-party application does not have the permission to call the account interface.

[0128] Taking the modification of the authorization identifier's value as an example, the package management service can change the authorization identifier from a first value to a second value, and the first and second values ​​are different. Specifically, when the authorization identifier is the first value, it indicates that the third-party application has permission to call the account interface. When the authorization identifier is the second value, it indicates that the third-party application does not have permission to call the account interface.

[0129] Taking the replacement of the authorization identifier with another identifier as an example, the package management service can replace the authorization identifier with an unauthorized identifier. When the third-party application's account interface has an authorization identifier, it indicates that the third-party application has permission to call the account interface. When the third-party application's account interface has an unauthorized identifier, it indicates that the third-party application does not have permission to call the account interface.

[0130] After the package management service updates the authentication information of the account interface of a third-party application, the package management service can save the updated authentication information of the account interface of the third-party application.

[0131] S417. Third-party applications call the account interface provided by the mobile service framework.

[0132] S418, Mobile Services Framework calls the account interface of the application package.

[0133] S419. The application package transmits the expected authentication identifier corresponding to the account interface and the application identifier of the third-party application to the interface authentication module.

[0134] S420, The interface authentication module obtains the authorization identifier of the third-party application's account interface from the package management service.

[0135] It is understandable that steps S417 to S420 are similar to the implementation process of steps S403 to S406 above. For details, please refer to the relevant descriptions in steps S403 to S406, which will not be repeated here.

[0136] S421. Package management service query does not find the authorization identifier of the account interface of a third-party application.

[0137] When the package management service receives the request information from the interface authentication module, it can query the authorization identifier of the third-party application's account interface from the cache. It's understandable that, since the package management service updates the authentication information of the third-party application's account interface from authorized to unauthorized during step S416, if the package management service finds no authorization identifier for the third-party application's account interface, it can proceed to step S422.

[0138] Optionally, if the package management service modifies or replaces the value of the authorization identifier during step S416—for example, changing the authorization identifier from a first value to a second value, or replacing the authorization identifier with an unauthorized identifier—then the package management service can query the authorization identifier or unauthorized identifier of the third-party application's account interface and return the authorization identifier or unauthorized identifier to the interface authentication module.

[0139] S422. The package management service returns information to the interface authentication module to indicate that the third-party application does not have an authorization identifier for the account interface.

[0140] Optionally, if the interface authentication module obtains information indicating that the third-party application does not have an authorization identifier for the account interface, or if the interface authentication module obtains an unauthorized identifier, it means that the third-party application does not have permission to call the account interface, i.e., the interface authentication of the third-party application calling the account interface fails, then the interface authentication module can execute step S423.

[0141] Optionally, if the interface authentication module obtains an authorization identifier (which is the second value at this time), the interface authentication module can compare the authorization identifier with the expected authentication identifier. Since the values ​​of the authorization identifier and the expected authentication identifier are different, it indicates that the third-party application does not have the permission to call the account interface, that is, the interface authentication of the third-party application calling the account interface fails, and the interface authentication module can execute step S423.

[0142] S423. The interface authentication module returns information to the application package indicating that the account interface authentication has failed.

[0143] S424. The application package returns information to the Mobile Services Framework indicating that the account interface call failed.

[0144] S425. The Mobile Services Framework returns information to third-party applications indicating that the account interface call failed.

[0145] If the application package detects that a third-party application lacks permission to call the account interface, the application package will not return the result of that account interface call. Optionally, the application package can return information indicating that account interface authentication failed to the third-party application through the mobile service framework. In this way, the third-party application cannot obtain results based on that account interface, thereby restricting the third-party application's access to the account interface.

[0146] Optionally, in possible scenarios, after the application package returns information indicating a failed account interface call, third-party applications may still frequently call the account interface. When the number of failed account interface authentication calls by a third-party application reaches a preset number, the application package can, without authenticating the third-party application's account interface, return information indicating the failed call to the third-party application through the mobile service framework. In other words, the application package can skip step S419 and not send information to the interface authentication module for authentication. This interception of account interface calls by third-party applications through the application package reduces resource waste caused by frequent interface authentication, minimizes unnecessary code execution, and improves the operating efficiency of electronic devices. It also reduces the likelihood of electronic devices malfunctioning due to malicious interface calls by third-party applications.

[0147] Optionally, since the interface authentication control method in this application embodiment can manage interface authentication separately for different versions of the same application, when a third-party application upgrades its version, the application package can re-authenticate the account interfaces called by the third-party application to determine whether the upgraded third-party application has the permission to call the account interfaces. Specifically, the application package can determine whether the third-party application has undergone a version upgrade by checking if the version number of the third-party application has changed.

[0148] Optionally, in this embodiment, the interface authentication module can also intercept the account interface called by the third-party application. Thus, after the number of failed authentication attempts by the third-party application to the account interface reaches a preset number, the interface authentication module can stop performing interface authentication and return information indicating the failure. Similarly, if the interface authentication module determines that the version of the third-party application has changed, it can re-authenticate the account interface called by the third-party application.

[0149] (3) Interface authentication recovery process.

[0150] S426. The application package sends the account interface authentication recovery information of the third-party application to the application market connection service.

[0151] When an application package determines that a third-party application is no longer malicious—for example, if the third-party application removes malicious logic from its code, or if the application package's identification is incorrect—the application package can send recovery information for the third-party application's account interface authentication to the application marketplace connection service. This recovery information may include the third-party application's application identifier and the name of the account interface to be restored.

[0152] Optionally, the recovery information may also include version information of the third-party application, thereby restoring the account interface for a specific version of the third-party application. In this way, the interface authentication control method of this application embodiment can achieve separate management of interface authentication for different versions of the same application, thus realizing more refined interface authentication control.

[0153] S427. The App Store Connection Service sends the recovery information to the App Store Connection Service system capabilities.

[0154] S428, The application marketplace connection service system capability transmits the recovery information to the package management service.

[0155] Optionally, the application marketplace connection service system can also transmit the recovery information to the interface authentication module. The interface authentication module can save the recovery information and delete the revocation information. When authentication of a third-party application's account interface is required, the interface authentication module can obtain that the third-party application's interface revocation information is not saved, indicating that the third-party application has the permission to call the account interface. That is, the third-party application's interface authentication for calling the account interface is successful, and the interface authentication module can then execute step S437.

[0156] S429. Package management service updates the authentication information of the account interface of third-party applications.

[0157] When the package management service obtains information indicating the restoration of account interface authentication for a third-party application, it can locate the corresponding third-party application and add an authorization identifier for the account interface. Adding an authorization identifier can include re-adding a deleted identifier, reverting an authorized identifier that has been modified to another value to its original value, or changing another identifier back to an authorized identifier. This other identifier can be used to indicate that the account interface is not authorized, meaning the third-party application does not have permission to call the account interface.

[0158] Corresponding to step S416 above, taking the re-addition of the deleted authorization identifier as an example, when the third-party application's account interface has the authorization identifier, it can be indicated that the third-party application has the permission to call the account interface.

[0159] Taking the example of changing an authorization identifier that has been modified to another value back to its original value, the package management service can change the authorization identifier from the second value to the first value, where the first and second values ​​are different. Specifically, when the authorization identifier is the first value, it indicates that the third-party application has permission to call the account interface. When the authorization identifier is the second value, it indicates that the third-party application does not have permission to call the account interface.

[0160] Taking changing other identifiers back to authorized identifiers as an example, the package management service can modify unauthorized identifiers to authorized identifiers. When a third-party application's account interface has an authorized identifier, it is used to indicate that the third-party application has permission to call the account interface.

[0161] After the package management service updates the authentication information of the account interface of a third-party application, the package management service can save the updated authentication information of the account interface of the third-party application.

[0162] S430, third-party applications call the account interface provided by the mobile service framework.

[0163] S431, The mobile service framework calls the account interface of the application package.

[0164] S432. The application package transmits the expected authentication identifier corresponding to the account interface and the application identifier of the third-party application to the interface authentication module.

[0165] S433, The interface authentication module obtains the authorization identifier of the third-party application's account interface from the package management service.

[0166] S434. Package management service queries the authorization identifier of the account interface of third-party applications.

[0167] S435. The package management service returns the authorization identifier of the third-party application's account interface to the interface authentication module.

[0168] S436. The interface authentication module determines whether the authorization identifier of the third-party application matches the expected authentication identifier.

[0169] S437. The interface authentication module returns information to the application package indicating that the account interface authentication was successful.

[0170] S438. The application package returns the account interface call result to the mobile service framework.

[0171] S439. The mobile service framework returns the account interface call result to the third-party application.

[0172] Understandably, since the third-party application has restored the authentication of the account interface, meaning it has the permission to call the account interface, steps S430 to S439 are similar to the implementation process of steps S403 to S412 described above. For details, please refer to the relevant descriptions in steps S403 to S412, which will not be repeated here. In this way, the third-party application can implement account-related functions based on the results of the account interface call.

[0173] In this embodiment, when the application package detects the need to restrict or restore a third-party application's access to the account interface, the application package can send the relevant information of the third-party application and the relevant information of the account interface to the application market connection service. The application market connection service then sends revocation or restoration information to the electronic device, thereby instructing the restriction or restoration of the third-party application's access to the account interface. This allows for rapid changes to the third-party application's access to the interface while keeping the authentication interface unchanged, achieving flexible control over interface authentication and improving its efficiency.

[0174] Figure 5 illustrates the interface authentication control method according to an embodiment of this application. The method includes:

[0175] S501. At the first moment, the first application of the electronic device calls the target interface of the second application of the electronic device and implements the target function based on the return result of the target interface.

[0176] In this embodiment, the first moment can be understood as the moment when the first application implements the target function based on the return result of the target interface. It is understood that, due to the fast execution speed of electronic devices, the time for the first application to call the target interface and implement the target function based on the return result of the target interface is usually very short. Therefore, calling the target interface and implementing the target function can be understood as being completed at the same moment or in a very short period of time, and this moment or period of time can be understood as the first moment.

[0177] The first application can include any application installed in the electronic device. For example, the first application can be a system application or a third-party application, and this application embodiment does not limit it. In some scenarios, the first application can also be referred to as the interface caller or the interface caller application.

[0178] The second application can include system applications within an electronic device. It is understood that the second application can implement certain functions and provide APIs for the first application to call. In some scenarios, the second application may also be referred to as an interface provider or an interface provider application.

[0179] A target interface can be understood as an interface provided by a second application to implement a specific function. For example, a target interface could include the account interface corresponding to the account management function mentioned above. It is understood that a target interface for a given function can include one or more APIs related to that function.

[0180] The target functionality can be understood as some functions implemented by the first application based on the return result of the target interface, or it can be understood as some functions related to the return result of the target interface. In other words, if the first application has permission to call the target interface, then the first application can obtain the return result of the target interface and implement the target functionality based on the return result.

[0181] S502, at the second moment, the electronic device receives first information, which is used to instruct the first application to prohibit calling the target interface.

[0182] The second moment can be understood as the moment when the electronic device receives the first information.

[0183] The first information can be understood as the revocation information in the embodiment corresponding to Figure 4. In possible implementations, the first information may include the application identifier of the first application, the target interface name, and / or the version information of the first application, etc.

[0184] Receiving first information by an electronic device may include the electronic device receiving first information from a server. The specific details of the electronic device receiving the first information can be found in the descriptions of steps S413 and S414 of the corresponding embodiment in Figure 4, and will not be repeated here.

[0185] S503. At the third moment, the first application calls the target interface, and the electronic device indicates that the target function cannot be achieved based on the first information; wherein, the second moment is later than the first moment, the third moment is later than the second moment, and neither the first application nor the second application has updated its application version between the first moment and the third moment.

[0186] The third moment can be understood as the moment when the first application cannot achieve the target function. The period from the second moment to the third moment can be understood as the process of revoking the interface authentication. For details, please refer to the relevant description of the interface authentication revocation process in embodiment (2) of Figure 4, which will not be repeated here.

[0187] The electronic device indicating that it cannot perform the target function based on the first information can also be understood as the electronic device indicating that the first application does not have permission to call the target interface based on the first information. In possible implementations, the electronic device indicating that it cannot perform the target function based on the first information can be referred to the relevant descriptions in steps S418 to S425 of the corresponding embodiment in Figure 4, which will not be repeated here.

[0188] In this embodiment, if neither the first application nor the second application has been updated, the electronic device can revoke the first application's permission to call the target interface based on the first information. This allows for the rapid revoke of the first application's permission to call the target interface while maintaining the same authentication interface for the system applications, enabling flexible control over target interface authentication and improving its efficiency.

[0189] Optionally, based on the embodiment corresponding to Figure 5, the method may further include: at a fourth moment, the electronic device receives second information, the second information being used to indicate that the first application is allowed to call the target interface; at a fifth moment, the first application calls the target interface and implements the target function based on the return result of the target interface; wherein the fourth moment is later than the third moment, the fifth moment is later than the fourth moment, and neither the first application nor the second application updates its application version between the third moment and the fifth moment.

[0190] The fourth moment can be understood as the moment when the electronic device receives the second information. The fifth moment can be understood as the moment when the first application achieves the target function based on the return result of the target interface. The period from the fourth moment to the fifth moment can be understood as the process of restoring interface authentication. For details, please refer to the relevant description of the interface authentication recovery process in embodiment (3) of Figure 4, which will not be repeated here.

[0191] It is understandable that, due to the fast execution speed of electronic devices, the time for the first application to call the target interface and implement the target function based on the return result of the target interface is usually very short. Therefore, calling the target interface and implementing the target function can be understood as being completed at the same time or in a very short period of time. This time or period of time can be understood as the fifth moment.

[0192] The second information can be understood as the recovery information in the embodiment corresponding to Figure 4. In possible implementations, the second information may include the application identifier of the first application, the target interface name, and / or the version information of the first application, etc.

[0193] Receiving the second information by the electronic device may include the electronic device receiving second information from the server. In possible implementations, the electronic device receiving the second information can be referred to the relevant descriptions of steps S426 and S427 in the corresponding embodiment of Figure 4, and will not be repeated here. The process of the first application calling the target interface and implementing the target function based on the return result of the target interface can be referred to the relevant descriptions of steps S430 and S439 in the corresponding embodiment of Figure 4, and will not be repeated here.

[0194] In this embodiment of the application, if neither the first application nor the second application has been updated, the electronic device can promptly restore the first application's permission to call the target interface based on the second information after prohibiting the first application from calling the target interface. This enables flexible control over the authentication of the target interface and improves the efficiency of interface authentication.

[0195] Optionally, based on the embodiment corresponding to Figure 5, at a first moment, the electronic device includes target authorization information, which is used to indicate that the first application has permission to call the target interface; at a third moment, the electronic device does not include target authorization information, or the electronic device includes target authorization information, which is used to indicate that the first application does not have permission to call the target interface.

[0196] The target authorization information can be understood as the authorization information for the first application to call the target interface, or it can be understood as the authorization identifier in the embodiment corresponding to Figure 4.

[0197] When the first application has permission to call the target interface, the electronic device may include target authorization information, which indicates that the first application has permission to call the target interface. When the first application does not have permission to call the target interface, the electronic device may delete or modify the target authorization information. Deleting or modifying the target authorization information can also be understood as the removal of the authorization identifier in step S416 of the embodiment corresponding to Figure 4, and will not be repeated here.

[0198] In this embodiment, based on changes in the target authorization information, it can be quickly determined whether the first application has permission to call the target interface. It is understood that using target authorization information to indicate whether the first application has permission to call the target interface achieves the purpose of message transmission more clearly and concisely, which is helpful for maintaining business logic and improving code execution efficiency.

[0199] Optionally, based on the embodiment corresponding to Figure 5, the electronic device receiving the first information may include: the electronic device receiving the first information from the server, wherein the server sends the first information to the electronic device based on the first indication information of the second application, and the first indication information includes the identifier of the first application and information for indicating that calling the target interface is prohibited; the electronic device receiving the second information may include: the electronic device receiving the second information from the server, wherein the server sends the second information to the electronic device based on the second indication information of the second application, and the second indication information includes the identifier of the first application and information for indicating that calling the target interface is allowed.

[0200] The server can be understood as the interface authorization management platform or application market connection service mentioned above.

[0201] The first instruction information can also be understood as the second application sending the revocation information of the target interface authentication of the first application to the server. For details, please refer to the relevant description in step S413 of the corresponding embodiment in Figure 4, which will not be repeated here. The first instruction information and the first information can be the same or different. The second instruction information can also be understood as the second application sending the restoration information of the target interface authentication of the first application to the server. For details, please refer to the relevant description in step S426 of the corresponding embodiment in Figure 4, which will not be repeated here. The second instruction information and the second information can be the same or different.

[0202] The process by which the server sends first information to the electronic device based on the first instruction information of the second application can be referred to the relevant descriptions of steps S413 and S414 in the corresponding embodiment of Figure 4, and will not be repeated here. The process by which the server sends second information to the electronic device based on the second instruction information of the second application can be referred to the relevant descriptions of steps S426 and S427 in the corresponding embodiment of Figure 4, and will not be repeated here.

[0203] The identifier of the first application can be used to uniquely identify the first application. For example, the identifier of the first application may include information such as AppId, UID, application package name, and / or application name, etc., which are not limited in the embodiments of this application.

[0204] In this embodiment, when it is recognized that the first application's access to the target interface needs to be prohibited or restored, the second application can send relevant information about the first application and the target interface to the server. The server then sends information to the electronic device, instructing the first application to prohibit or restore its access to the target interface. This allows for rapid modification of the first application's access to the target interface by instructing the server, while keeping the target interface unchanged in the second application. This flexible control of interface authentication improves its efficiency.

[0205] Optionally, based on the embodiment corresponding to Figure 5, the electronic device includes a first module and a second module. At a first moment, the first module stores target authorization information, which is used to indicate that the first application has permission to call the target interface. After receiving the first information, the electronic device may further include: transmitting information from the second module to the first module to indicate that the first application is prohibited from calling the target interface; updating the target authorization information based on the first module, whereby the first module does not store the target authorization information, or the first module stores the target authorization information, which is used to indicate that the first application does not have permission to call the target interface. After receiving the second information, the electronic device may further include: transmitting information from the second module to the first module to indicate that the first application is allowed to call the target interface; updating the target authorization information based on the second module, whereby the first module stores the target authorization information, which is used to indicate that the first application has permission to call the target interface.

[0206] In this embodiment, the first module can be understood as the Package Management Service (BMS) mentioned above. The second module can be understood as the Application Marketplace Connection Service System Capability (AGC SA) mentioned above. For details regarding the specific Package Management Service and Application Marketplace Connection Service System Capability, please refer to the relevant descriptions in the corresponding embodiments of Figure 3, which will not be repeated here.

[0207] The information transmitted from the second module to the first module to indicate that the first application is prohibited from calling the target interface can be referred to the relevant description of step S415 in the corresponding embodiment of Figure 4; the update of the target authorization information by the first module can be referred to the relevant description of step S416 in the corresponding embodiment of Figure 4, which will not be repeated here.

[0208] The information transmitted from the second module to the first module to indicate permission for the first application to call the target interface can be referred to the relevant description of step S428 in the corresponding embodiment of Figure 4; the update of the target authorization information from the first module can be referred to the relevant description of step S429 in the corresponding embodiment of Figure 4, which will not be repeated here.

[0209] The interface authentication control method of this application embodiment can be used in a first module to update the authentication information of the first application calling the target interface, effectively improving the timeliness of interface authentication information updates. For authentication information that has been revoked, this application embodiment can also provide a recovery mechanism, so that in scenarios such as accidental revocation, the permission of the first application to call the target interface can be quickly restored, thereby reducing the impact of interface authentication on the application.

[0210] Optionally, based on the embodiment corresponding to Figure 5, the electronic device further includes a third module. At the third moment, after the first application calls the target interface, the module may further include: the second application transmitting the identifier of the first application and the target identifier to the third module, the target identifier being used to indicate the authorization identifier required to call the target interface; the third module transmitting the identifier of the first application to the first module; the first module returning third information to the third module based on the identifier of the first application; if the third information indicates that no target authorization information is stored, or if the target authorization information does not match the target identifier, the third module returning information to the second application indicating that the first application does not have permission to call the target interface; and the second application returning information to the first application indicating that the target interface call failed.

[0211] In this embodiment, the third module can be understood as the interface authentication module mentioned above. The specific interface authentication module can be found in the relevant description in the corresponding embodiment of Figure 3, and will not be repeated here.

[0212] The target identifier can be understood as the expected authentication identifier in the embodiment corresponding to Figure 4. The expected authentication identifier can also be understood as the permission identifier corresponding to the target interface expected by the second application.

[0213] The second application transmits the identifier of the first application and the target identifier to the third module, as described in step S419 of the corresponding embodiment of FIG4; the third module transmits the identifier of the first application to the first module, as described in step S420 of the corresponding embodiment of FIG4; the first module returns third information to the third module based on the identifier of the first application, as described in steps S421 and S422 of the corresponding embodiment of FIG4, which will not be repeated here.

[0214] Understandably, if the interface authentication module obtains target authorization information indicating that the first application does not have the target interface, or if the target authorization information obtained by the interface authentication module does not match the target identifier, it means that the first application does not have permission to call the target interface, i.e., the interface authentication for the first application to call the target interface fails. The interface authentication module can instruct the second application to return information indicating that the target interface call has failed to the first application. This prohibits the first application from calling the target interface, thus achieving interface access control.

[0215] Optionally, based on the embodiment corresponding to Figure 5, at the fifth moment, after the first application calls the target interface, the process may further include: the second application transmitting the identifier of the first application and the target identifier to the third module; the third module transmitting the identifier of the first application to the first module; the first module returning target authorization information to the third module based on the identifier of the first application; if the target authorization information matches the target identifier, the third module returning information to the second application indicating that the first application has the permission to call the target interface; and the second application returning the call result of the target interface to the first application.

[0216] The second application transmits the identifier of the first application and the target identifier to the third module, as described in the relevant description of step S405 of the corresponding embodiment of FIG4; the third module transmits the identifier of the first application to the first module, as described in the relevant description of step S406 of the corresponding embodiment of FIG4; the first module returns third information to the third module based on the identifier of the first application, as described in the relevant descriptions of steps S407 and S408 of the corresponding embodiment of FIG4, which will not be repeated here.

[0217] In this embodiment, if the target authorization information of the first application matches the target identifier, it indicates that the first application has the permission to call the target interface, meaning the interface authentication of the first application calling the target interface is successful. The interface authentication module can then instruct the second application to return the call result of the target interface to the first application. This allows the first application to call the target interface, thus achieving interface access control. The matching of target authorization information and target identifier may include the target authorization information being the same as the target identifier, or it may include a corresponding relationship between the target authorization information and the target identifier; this embodiment does not impose such limitations.

[0218] Optionally, based on the embodiment corresponding to Figure 5, the first indication information and / or the second indication information may further include the version information of the first application.

[0219] In this embodiment, the first indication information and / or the second indication information include the version information of the first application. When the version of the first application changes, the second application can authenticate the target interface called by the first application to determine whether the first application, after the version change, has the permission to call the target interface. This allows for the revocation or restoration of the target interface for a specific version of the first application, thereby enabling separate management of interface authentication for different versions of the same application.

[0220] Optionally, based on the embodiment corresponding to Figure 5, at the fifth moment, the first application is the first version, and the method may further include: at the sixth moment, the electronic device receives third information, the third information being used to indicate that the first version of the first application is prohibited from calling the target interface, the sixth moment being later than the fifth moment; at the seventh moment, the first application calls the target interface, and the electronic device indicates that the target function cannot be achieved based on the third information, the seventh moment being later than the sixth moment; at the eighth moment, the electronic device upgrades the first application from the first version to the second version, the eighth moment being later than the seventh moment; at the ninth moment, the upgraded first application calls the target interface and achieves the target function based on the return result of the target interface, the ninth moment being later than the eighth moment.

[0221] In this embodiment, the third information can be understood as the revocation information in the embodiment corresponding to Figure 4. In possible implementations, the third information may include the application identifier of the first application, the target interface name, and the version information of the first application, etc.

[0222] When the first application upgrades its version, for example, from version 1 to version 2, the second application can re-authenticate the target interface called by the first application to determine whether the upgraded first application has the permission to call the target interface. Specifically, the second application can determine whether the first application has undergone a version upgrade by checking if the version number of the first application has changed.

[0223] It is understandable that the third piece of information includes the version information of the first application. This allows for separate management of interface authentication for different versions of the same application, enabling more granular interface authentication control and reducing the impact of revoking interface usage permissions on the application.

[0224] The above detailed embodiments have provided a comprehensive description of the purpose, technical solutions, and beneficial effects of the embodiments of this application. It should be understood that the above are merely specific implementation methods of the embodiments of this application and are not intended to limit the scope of protection of the embodiments of this application. Any modifications, equivalent substitutions, improvements, etc., made based on the technical solutions of the embodiments of this application should be included within the scope of protection of the embodiments of this application.

[0225] It should be noted that the user information (including but not limited to user device information, user personal information, etc.) and data (including but not limited to data used for analysis, data stored, data displayed, etc.) involved in this application are all information and data authorized by the user or fully authorized by all parties. Furthermore, the collection, use and processing of the relevant data must comply with the relevant laws, regulations and standards of the relevant countries and regions, and corresponding operation portals are provided for users to choose to authorize or refuse.

[0226] The foregoing mainly describes the technical solutions provided by the embodiments of this application from a methodological perspective. To achieve the above functions, it includes corresponding hardware structures and / or software modules for executing each function. Those skilled in the art should readily recognize that the method steps described in conjunction with the embodiments of this application can be implemented in hardware or a combination of hardware and software. Whether a function is executed in a hardware-driven or software-driven manner depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.

[0227] This application provides an electronic device that may include one or more processors and a memory. The memory is coupled to one or more processors. The memory may be used to store computer program code, which includes computer instructions. The one or more processors may invoke the computer instructions to cause the electronic device to execute the technical solutions described above.

[0228] This application provides a chip system. This chip system is applied to an electronic device and may include one or more processors. The one or more processors can be used to invoke instructions to cause the electronic device to execute the technical solutions described above.

[0229] Figure 6 is a schematic diagram of a chip system provided in an embodiment of this application. The chip system 600 includes one or more processors 601, communication lines 602, communication interfaces 603, and memory 604.

[0230] In some implementations, memory 604 stores elements such as executable modules or data structures, or subsets thereof, or extended sets thereof.

[0231] The methods described in the embodiments of this application can be applied to, or implemented by, processor 601. Processor 601 may be an integrated circuit chip with signal processing capabilities. During implementation, each step of the above methods can be completed by integrated logic circuits in the hardware of processor 601 or by instructions in software form. Processor 601 may be a general-purpose processor (e.g., a microprocessor or conventional processor), a DSP, an application-specific integrated circuit (ASIC), an off-the-shelf programmable gate array (OPG) or other programmable logic devices, discrete gates, transistor logic devices, or discrete hardware components. Processor 601 can implement or execute the processing-related methods, steps, and logic block diagrams in the embodiments of this application.

[0232] The method described in this application embodiment can be executed using a hardware decoding processor, or by a combination of hardware and software modules within the decoding processor. The software modules can be located in the memory 604, and the processor 601 can read information from the memory 604 and, in conjunction with its hardware, complete the steps of the above method. The processor 601, the memory 604, and the communication interface 603 can communicate via the communication line 602.

[0233] This application also provides a readable storage medium (also referred to as a computer-readable storage medium). The readable storage medium includes computer instructions. When these computer instructions are executed on an electronic device, they cause the electronic device to perform the technical solutions described in the above embodiments.

[0234] The methods described in the above embodiments can be implemented, in whole or in part, by software, hardware, firmware, or any combination thereof. If implemented in software, the functionality can be stored or transmitted on a readable medium as one or more instructions or programs. The readable medium can include storage media and communication media, and can also include any medium that can transfer a program from one place to another. The storage medium can be any accessible target medium.

[0235] In possible implementations, the readable medium may include random access memory, read-only memory, programmable read-only memory, electrically erasable programmable memory, optical disc read-only memory, or other optical disc storage. The readable medium may also include disk storage or other disk storage devices, or be directed to any other medium or store the required program in the form of instructions or data structures, and be accessible.

[0236] This application also provides a program product (also referred to as a computer program product). The program product includes computer program code. When the computer program code runs on an electronic device, it causes the electronic device to execute the technical solutions described in the above embodiments.

[0237] In the various embodiments of this application, unless otherwise specified or in case of logical conflict, the terminology and / or descriptions between the various embodiments are consistent and can be referenced by each other. Technical features in different embodiments can be combined to form new embodiments according to their inherent logical relationships.

[0238] 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 technical scope 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. A control method for interface authentication, characterized in that, The method includes: At the first moment, the first application of the electronic device calls the target interface of the second application of the electronic device, and implements the target function based on the return result of the target interface; At a second moment, the electronic device receives first information, which instructs the first application to be prohibited from calling the target interface; At the third moment, the first application calls the target interface, and the electronic device indicates that it cannot perform the target function based on the first information; The second time point is later than the first time point, and the third time point is later than the second time point. Between the first time point and the third time point, neither the first application nor the second application has updated its application version.

2. The method as described in claim 1, characterized in that, The method further includes: At the fourth moment, the electronic device receives second information, which instructs the first application to call the target interface. At the fifth moment, the first application calls the target interface and implements the target function based on the return result of the target interface; The fourth time point is later than the third time point, and the fifth time point is later than the fourth time point. Between the third time point and the fifth time point, neither the first application nor the second application has updated its application version.

3. The method as described in claim 1 or 2, characterized in that, At the first moment, the electronic device includes target authorization information, which is used to indicate that the first application has permission to call the target interface; At the third moment, the electronic device either does not contain the target authorization information, or the electronic device does contain the target authorization information, which is used to indicate that the first application does not have permission to call the target interface.

4. The method as described in claim 2 or 3, characterized in that, The electronic device receives first information, including: The electronic device receives the first information from the server, wherein the server sends the first information to the electronic device based on the first indication information of the second application, and the first indication information includes the identifier of the first application and information for indicating that calling the target interface is prohibited; The electronic device receives second information, including: The electronic device receives the second information from the server, wherein the server sends the second information to the electronic device based on the second indication information of the second application, the second indication information including the identifier of the first application and information for indicating permission to call the target interface.

5. The method as described in claim 3 or 4, characterized in that, The electronic device includes a first module and a second module. At the first moment, the first module stores the target authorization information, which indicates that the first application has permission to call the target interface. After receiving the first information, the electronic device further includes: The second module transmits information to the first module to instruct the first application to prohibit it from calling the target interface. The first module updates the target authorization information based on the first module. The first module does not save the target authorization information, or the first module saves the target authorization information. The target authorization information is used to indicate that the first application does not have permission to call the target interface. After receiving the second information, the electronic device further includes: The second module transmits information to the first module to indicate that the first application is allowed to call the target interface. The target authorization information is updated based on the second module. The first module stores the target authorization information, which is used to indicate that the first application has permission to call the target interface.

6. The method as described in claim 5, characterized in that, The electronic device further includes a third module, and at the third moment, after the first application calls the target interface, the module further includes: The second application passes the identifier of the first application and the target identifier to the third module. The target identifier is used to indicate the authorization identifier required to call the target interface. The third module transmits the identifier of the first application to the first module; The first module returns third information to the third module based on the identifier of the first application; If the third information indicates that the target authorization information is not stored, or if the target authorization information does not match the target identifier, the third module returns information to the second application indicating that the first application does not have permission to call the target interface; The second application returns information to the first application indicating that the target interface call failed.

7. The method as described in claim 6, characterized in that, At the fifth moment, after the first application calls the target interface, the method further includes: The second application transmits the identifier of the first application and the target identifier to the third module; The third module transmits the identifier of the first application to the first module; The first module returns the target authorization information to the third module based on the identifier of the first application; If the target authorization information matches the target identifier, the third module returns information to the second application indicating that the first application has permission to call the target interface; The second application returns the call result of the target interface to the first application.

8. The method as described in claim 4, characterized in that, The first indication information and / or the information may also include the version information of the first application.

9. The method according to any one of claims 2-8, characterized in that, At the fifth moment, the first application is a first version, and the method further includes: At a sixth moment, the electronic device receives third information, which is used to instruct the first version of the first application to prohibit calling the target interface. The sixth moment is later than the fifth moment. At the seventh moment, the first application calls the target interface, and the electronic device indicates that it cannot perform the target function based on the third information. The seventh moment is later than the sixth moment. At the eighth moment, the electronic device upgrades the first application from the first version to the second version, the eighth moment being later than the seventh moment; At the ninth moment, the upgraded first application calls the target interface and implements the target function based on the return result of the target interface. The ninth moment is later than the eighth moment.

10. An electronic device, characterized in that, The electronic device includes: one or more processors and memory; The memory is coupled to the one or more processors, the memory being used to store computer program code, the computer program code including computer instructions, the one or more processors invoking the computer instructions to cause the electronic device to perform the method as described in any one of claims 1-9.

11. A chip system, characterized in that, The chip system is applied to an electronic device, the chip system including one or more processors, the one or more processors being used to invoke computer instructions to cause the electronic device to perform the method as described in any one of claims 1-9.

12. A computer-readable storage medium, characterized in that, The computer-readable storage medium includes computer instructions that, when executed on an electronic device, cause the electronic device to perform the method as described in any one of claims 1-9.

13. A computer program product, characterized in that, The computer program product includes computer program code that, when run on an electronic device, causes the electronic device to perform the method as described in any one of claims 1-9.

Images