WO2017124960A1 - 应用程序对接口的访问方法、授权请求方法及装置 - Google Patents

应用程序对接口的访问方法、授权请求方法及装置 Download PDF

Info

Publication number
WO2017124960A1
WO2017124960A1 PCT/CN2017/070981 CN2017070981W WO2017124960A1 WO 2017124960 A1 WO2017124960 A1 WO 2017124960A1 CN 2017070981 W CN2017070981 W CN 2017070981W WO 2017124960 A1 WO2017124960 A1 WO 2017124960A1
Authority
WO
WIPO (PCT)
Prior art keywords
application
private
authorization
signature
interface
Prior art date
Application number
PCT/CN2017/070981
Other languages
English (en)
French (fr)
Inventor
裘绍翔
Original Assignee
阿里巴巴集团控股有限公司
裘绍翔
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 阿里巴巴集团控股有限公司, 裘绍翔 filed Critical 阿里巴巴集团控股有限公司
Publication of WO2017124960A1 publication Critical patent/WO2017124960A1/zh
Priority to US16/037,809 priority Critical patent/US10878066B2/en

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/10—Protecting distributed programs or content, e.g. vending or licensing of copyrighted material ; Digital rights management [DRM]
    • G06F21/12—Protecting executable software
    • G06F21/121—Restricting unauthorised execution of programs
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/60—Protecting data
    • G06F21/62—Protecting access to data via a platform, e.g. using keys or access control rules
    • G06F21/6218—Protecting access to data via a platform, e.g. using keys or access control rules to a system of files or objects, e.g. local or distributed file system or database
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/60—Protecting data
    • G06F21/62—Protecting access to data via a platform, e.g. using keys or access control rules
    • G06F21/629—Protecting access to data via a platform, e.g. using keys or access control rules to features or functions of an application
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F2221/00—Indexing scheme relating to security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F2221/21—Indexing scheme relating to G06F21/00 and subgroups addressing additional information or applications relating to security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F2221/2141—Access rights, e.g. capability lists, access control lists, access tables, access matrices

Definitions

  • the present application relates to an interface access method, and in particular, to an application access method and device for an interface.
  • the application relates to an application request method and device, an application authorization method and device, and an application permission acquisition method and device.
  • applications can encapsulate specific operations, such as operations on hardware resources, operations on internal data, operations on components, etc., in the form of interfaces for access by other applications.
  • specific operations such as operations on hardware resources, operations on internal data, operations on components, etc.
  • the system platform usually uses the permission mechanism to control the access of the interface.
  • the Android system has some permissions for performing access operations on a specific interface, and also allows the author of the application (ie, the developer) to declare permissions in the AndroidManifest.xml file with the ⁇ permission> element. Used to restrict access to its internal interface; on the other hand, for applications that need to access the rights-protected interface, you can declare the required permissions in the AndroidManifest.xml file, and use ⁇ use-permission> respectively. Element identification.
  • the system or the application that provides the interface usually determines the application based on the decisions made by the user (for example, when the application is installed, the requested permission is usually displayed on the device screen for the user to confirm) Whether to have access to the corresponding interface, and when enabled, allows the application to perform the appropriate interface access operations.
  • the application's access control to the interface is usually controlled by the device's holder (ie, the user), rather than by the interface provider (eg, the application author), unable to reflect the interface provider.
  • Authorization intent so in the actual application, there are developers who abuse the rights and hackers to obtain malicious permissions to perform malicious operations; and for the above reasons, the application author does not dare to open sensitive interfaces (for example: involving funds, use Interfaces for operations such as user privacy data, also known as private interfaces, can not promote effective interaction between applications, and are not conducive to building a good application ecosystem.
  • the embodiment of the present invention provides an application access method and device for an interface, to solve the security risk caused by the existing access control right being controlled by the user, and the problem that the effective interaction relationship cannot be constructed between the applications.
  • the embodiment of the present application further provides an application request method and device, an application authorization method and device, and an application permission acquisition method and device.
  • the application provides an application access method for an interface, including:
  • the first application is allowed to access the particular private interface.
  • the providing side of the specific private interface includes: a system publisher that provides the specific private interface, or a second application publisher that provides the specific private interface.
  • the determining whether the first application is authorized by the providing side of the specific private interface includes:
  • Determining whether the first application is authorized by the providing side of the specific private interface according to whether the signature file of the first application includes the signature file of the providing side of the specific private interface.
  • the content of the signature file in the signature file list includes: summary information, the digital signature generated by the summary information is encrypted by the private key of the signer, and the signer's public key certificate.
  • the signature file list includes: a publisher signature file of the first application publisher, or the publisher signature file and a signature file different from the private interface providing side of the first application publisher. .
  • the manner of generating the authorization signature file includes:
  • the first client sends an authorization request to the private interface providing side
  • the second client performs a signature operation on the to-be-signed file carried in the authorization request by using the private key provided by the private interface according to the received authorization request, and generates an authorization signature file of the private interface providing side and returns to the first a client;
  • the first client receives the authorization signature file and adds it to the signature file list of the first application.
  • the to-be-signed file includes: a signature file that is generated last time in the first application signature file list.
  • the installation process of the first application includes the following permission obtaining steps:
  • Parsing the configuration file of the first application extracting the private permission information of the private interface that it applies for accessing the system or other application;
  • determining whether the first application is authorized by the providing side of the specific private interface according to whether the signature file of the first application includes the signature file of the providing side of the specific private interface includes:
  • Determining whether the first application has obtained the private right to access the specific private interface and if so, determining that the first application is authorized by the providing side of the specific private interface, otherwise it is not authorized.
  • the public key certificate is extracted one by one from the signature file list of the first application, and added to the signature set, including:
  • the public key certificate is extracted from the verified signature file and added to the signature set.
  • the application further provides an application access device for an interface, including:
  • An access request receiving unit configured to receive an access request of the first application to a specific private interface
  • An authorization determining unit configured to determine whether the first application is authorized by the providing side of the specific private interface
  • the access permission unit is configured to allow the first application to access the specific private interface when the output of the authorization determination unit is YES.
  • the authorization determining unit is configured to determine, according to whether the signature file of the first interface of the first application includes the signature file of the providing side of the private interface, whether the first application is provided by the providing side of the private interface. Authorization.
  • the signature file in the signature file list used by the authorization determining unit includes: a publisher signature file of the first application publisher, or the publisher signature file and the first application different from the first application
  • the publisher's private interface provides the side's authorization signature file.
  • the authorized signature file in the signature file list used by the authorization determining unit is generated by the following unit:
  • An authorization request sending unit configured to send, by the first client, an authorization request to the private interface providing side;
  • the authorization signature file generating unit is configured to perform, by using the digital signature technology, the second client to perform a signature operation on the to-be-signed file carried in the authorization request by using the private key of the private interface to generate a private interface providing side according to the received authorization request.
  • the authorization signature file receiving unit is configured to receive the authorization signature file by the first client and add it to the signature file list of the first application.
  • the to-be-signed file carried in the authorization request sent by the authorization requesting unit includes: a signature file generated last time in the first application signature file list.
  • the device further includes: a rights obtaining unit, configured to acquire, by the first application, a private right for accessing the private interface during the installation process;
  • the authority obtaining unit includes:
  • a signature set generation subunit configured to extract a public key certificate one by one from a list of signature files of the first application, and add the signature to the signature set;
  • a private permission extraction sub-unit configured to parse a configuration file of the first application, and extract private permission information of a private interface that is applied for accessing a system or other application;
  • a private authority obtaining execution subunit configured to: for each private authority in the private authority information, perform an operation of: extracting a public key certificate corresponding to the private authority from the pre-generated private authority claim information; and in the signature set Finding the public key certificate, and if found, determining that the first application acquires the private authority;
  • the authorization determining unit is specifically configured to determine whether the first application has obtained the private permission to access the specific private interface, and if yes, determine that the first application is authorized by the providing side of the specific private interface, otherwise unauthorized.
  • the signature set generation subunit is specifically configured to verify, by using a digital signature verification technology, the signature file for each signature file in the signature file list, and extract the signature file from the verified signature file.
  • a public key certificate is added to the signature set.
  • the application also provides an authorization request method for an application, including:
  • the authorization request carries the to-be-signed file of the application
  • the authorization information includes: an authorization signature file generated by performing a signature operation on the to-be-signed file by using a private key of the private interface providing side by using a digital signature technology;
  • the adding the authorization information to the application comprises: adding the received authorization signature file to a list of signature files of the application.
  • the to-be-signed file carried in the authorization request includes: a signature file that is generated last time in the application signature file list.
  • the application further provides an authorization requesting device for an application, including:
  • An authorization request sending unit configured to send an authorization request to the private interface providing side, requesting permission for the application to access the private interface
  • An authorization information receiving unit configured to receive authorization information returned by the private interface providing side
  • An authorization information adding unit for adding the authorization information to the application.
  • the application also provides an authorization method for an application, including:
  • the generating the authorization information that the private interface providing side allows the to-be-authorized application to access the private interface includes:
  • the private key of the private interface providing side performs a signature operation on the to-be-signed file of the to-be-authorized application, and generates an authorization signature file, where the authorization signature file is the authorization information.
  • the determining the to-be-authorized application includes: determining an authorization request of the private interface according to the received request, and determining the to-be-authorized application;
  • the to-be-signed file includes: a file carried in the authorization request;
  • the method further includes:
  • the generated authorization signature file is returned to the sender of the authorization request.
  • the determining the to-be-authorized application includes: determining the to-be-authorized application from among the to-be-published applications operated by the system;
  • the to-be-signed file includes: a related file of the to-be-authorized application;
  • the method further includes:
  • the to-be-signed file is: the most recently generated signature file in the signature file list of the to-be-authorized application.
  • the application also provides an authorization device for an application, including:
  • an authorization information generating unit configured to generate authorization information that indicates that the private interface providing side allows the to-be-authorized application to access the private interface.
  • the application also provides a method for obtaining rights of an application, including:
  • the identity information is searched for in the set of licensor identity, and if found, the application is determined to obtain the private privilege.
  • the authorization information includes: a signature file list, where the information identifying the identity of the licensor includes: a public key certificate, where the licensor identity set includes: a signature set.
  • the signature file list includes: a publisher signature file of the application publisher, or the publisher signature file and an authorization signature file different from the private interface providing side of the application publisher.
  • the application further provides an apparatus for acquiring rights of an application, including:
  • An identity set generating unit configured to extract information identifying the identity of the grantor one by one from the set of authorization information of the application, and add the information to the authorized identity set;
  • a private authority extracting unit configured to parse the configuration file of the application, and extract private permission information of the application for accessing the private interface
  • a private authority obtaining unit configured to determine whether the application obtains the private authority in the private authority information
  • the private authority obtaining unit includes:
  • a loop control subunit configured to trigger an identity information extraction subunit and a search decision subunit in sequence for each private authority in the private authority information
  • An identity information extraction subunit configured to extract identity information corresponding to the currently processed private authority from the pre-generated private rights declaration information
  • a determining determining subunit configured to search for the identity information extracted by the identity information extracting subunit in the set of authorized identity, and if found, determine that the application obtains the private right.
  • the method for accessing an interface provided by the application receiving an access request of the first application to a specific private interface, determining whether the first application is authorized by the providing side of the specific private interface, and the first application has been In the case of authorization, it is allowed to access the specific private interface.
  • the above method provides the application publisher and the system publisher with the permission control function for the private interface, which can present the authorization intention of the private interface providing side, and eliminate the security risk caused by the abuse of the permission; and the promotion of the private interface can promote Effective interaction between applications and between applications and systems helps build a good service ecosystem.
  • the system publisher it is possible to make the system publisher actively participate in the authorization process of the application, and to facilitate the operation and maintenance of the system publisher.
  • FIG. 1 is a flowchart of an embodiment of an application access method of an interface provided by the present application
  • FIG. 2 is a flowchart of a process for obtaining a private right during an installation process according to an embodiment of the present application
  • FIG. 3 is a schematic diagram of an embodiment of an application-to-interface access device provided by the present application.
  • FIG. 4 is a flowchart of an embodiment of an authorization request method of an application provided by the present application.
  • FIG. 5 is a schematic diagram of an embodiment of an authorization requesting apparatus of an application provided by the present application.
  • FIG. 6 is a flowchart of an embodiment of an authorization method of an application provided by the present application.
  • FIG. 7 is a schematic diagram of an embodiment of an authorization device for an application provided by the present application.
  • FIG. 8 is a flowchart of an embodiment of a method for obtaining rights of an application provided by the present application.
  • FIG. 9 is a schematic diagram of an embodiment of an authority obtaining apparatus of an application provided by the present application.
  • an application access interface method and device an application authorization request method and device, an application authorization method and device, and an application permission acquisition method are provided respectively.
  • an application access interface method and device an application authorization request method and device, an application authorization method and device, and an application permission acquisition method are provided respectively.
  • the core of the method for accessing an interface provided by the application provided by the present application is that, when determining whether the application can access a specific private interface, whether the providing side of the specific private interface is authorized by the application is judged.
  • the standard that is, the application is allowed to access the particular private interface only if the provider side of the particular private interface has authorized the application. Therefore, the authorization intention of the private interface providing side can be reflected, the security risk caused by the abuse of the authority can be eliminated, and the effective interaction between the application and the application can be promoted through the opening of the private interface, which helps to construct a good one. Serve the ecological environment.
  • the private interface described in this application refers to an interface that needs to be authorized by the private interface providing side to access, and is usually an interface that performs sensitive operations, such as an interface involving operations such as funds and user privacy data.
  • the provider side of the private interface usually refers to the system publisher or application publisher that provides the private interface, or other individuals or groups that can provide a private interface.
  • the specific private interface refers to a specific private interface that is accessed when the method of the present application is implemented, and the providing side of the specific private interface generally refers to a system release that provides the specific private interface.
  • the application or the publisher of the application may also be other individuals or groups that are able to provide the particular private interface.
  • the specific private interface may belong to a certain system (implemented by a certain system) or may belong to an application (implemented by an application), and thus, the technical solution of the present application is a system sensitive interface and an application.
  • the program-sensitive interface provides a unified protection mechanism for application developers and system operation and maintenance personnel to implement.
  • the private interface is an interface in other applications published by the application publisher (ie, the private interface is provided by the publisher itself) And the publisher can generate authorization information for the application that needs to access the private interface and add to the application; if the private interface is not provided by the publisher itself, the publisher can provide the The private interface of the private interface provides a side sending authorization request, requesting the latter to grant corresponding access rights to the application, and the private interface providing side generates corresponding authorization information (for example, authorization if the application is allowed to access the private interface).
  • the information may include the identity information of the authorizer, the identifier of the application, and the like, and return the authorization information to the publisher of the application, and the publisher of the application may add the authorization information to the In the application, for example, added to its installation package.
  • the application publisher can request one or more private interface providers to authorize the application according to the private interface access requirements, and add the obtained authorization information to the application.
  • the accessed party an application or system that implements the private interface
  • the module responsible for the interface access control Can be carried according to the application Authorizing the information, using a preset verification algorithm or performing mutual authentication with the server providing the verification service, checking whether the application has obtained the authorization of the private interface providing side, and if so, allowing the application to access the The private interface, otherwise denied access.
  • the digital signature technology may be used to generate the authorization information, that is, the process of signing is the process of authorization.
  • the authorization process can generate a list of signature files.
  • the application accesses a private interface, it can determine whether the signature file of the private interface is included in the signature file list of the application. Allow access.
  • the publisher of the application in order to determine the uniqueness of the application and ensure that the source of the application is not tampered with, the publisher of the application usually generates a publisher signature file for the application signature (for example, an application signature mechanism adopted by the Android system).
  • the technical solution can implement the above preferred embodiment on the basis of the traditional publisher signature, and supports the multi-signature mechanism: before the application is published, the application publisher first signs the application and generates the publisher.
  • a signature file (equivalent to authorizing an application to access a private interface in other applications published by the same publisher), after which the application publisher can also request other private interface providers by sending an authorization request Sign the application and generate a private interface to provide the signature file on the side. That is, the application can not only have the signature of the publisher, but also have one or more signatures on the side of the private interface provided by the application publisher.
  • This multi-signature mechanism is not only convenient for verifying the authenticity of the authorization information. And easy to expand.
  • the following is an example of supporting a multi-signature mechanism based on the signature of a traditional publisher, and further describes the issue process between the publisher signature process and the publishers of different application publishers.
  • an authorized application will be required in this example.
  • the program is called application A, and application A needs to access the private interface in application B in order to implement its function, and the publishers of application A and application B are different.
  • the signing process may include the following steps: generating a summary information of the application A by using a preset digest algorithm, such as an MD5, SHA-0, or SHA-1 algorithm, and encrypting the digest information by using the private key of the application A publisher. (for example, RSA encryption algorithm can be used) Get the digital signature, and finally write the summary information, the digital signature, and the public key certificate of the application A publisher (usually including the publisher's public key, identity information, encryption algorithm used to generate the digital signature, etc.) into the signature file, for example The 1.xml file, which generates the publisher signature file, and adds the publisher signature file to Application A's signature file list.
  • a preset digest algorithm such as an MD5, SHA-0, or SHA-1 algorithm
  • the publisher of the application A sends the authorization request to the private interface providing side, that is, the publisher of the application B, by the first client, and the authorization request carries the file to be signed of the application A.
  • the publisher of the application B After receiving the authorization request by the second client, the publisher of the application B performs a signature operation on the to-be-signed file carried in the authorization request by using the private key to generate an authorization signature file.
  • the signing process may include the following steps: generating a summary information of the file to be signed by using a preset digest algorithm, such as MD5, SHA-0 or SHA-1 algorithm, and encrypting the digest information by using the private key of the application B publisher.
  • Signature and finally the generated summary information, digital signature, and application B publisher's public key certificate (usually containing the application B publisher's public key, identity information, encryption algorithm used to generate the digital signature, etc.) are written to the signature file.
  • Medium for example: 2.xml file, thereby generating an authorized signature file of the application B to the application A of the application B, and returning the file to the first client.
  • the authorization signature file is added to the signature file list of the application A, thereby completing the publisher of the application B to the application A. Authorization process.
  • the file to be signed carried by the application A in the authorization request is usually a file related to the application A, for example, it may be all files except the list of signature files in the installation package of the application A. .
  • the to-be-signed file may be the most recently generated signature file in the signature file list of the application A.
  • the publisher of application A signs the signature file 1.xml of application A and adds it to the signature file of application A.
  • the 1.xml file can be sent to the publisher of the application B, and the authorized signature file 2.xml returned by the publisher of the application B is also added to the signature file list, at this time, the application A
  • the signature file list includes the 1.xml file and the 2.xml file (the 2.xml file is the most recently generated signature file); after that, the publisher of the application A sends the 2.xml file to the application C.
  • the publisher adds the authorization signature file 3.xml returned by the publisher of application C to the signature file list.
  • the signature file list includes three signature files, and application A can not only access the publisher's published version.
  • the private interfaces in other applications are also authorized by the publishers of application B and application C.
  • the above preferred embodiment is adopted to facilitate verification of the integrity of the signature file.
  • the integrity of the 2.xml can be verified by using 3.xml, and the verification is performed by 2.xml. 1.xml integrity.
  • the above example describes the authorization process between different application publishers.
  • the system hosting application A can also open the private interface.
  • Application A can access the open private interface of the system according to its own needs.
  • the private interface providing side can be a system publisher.
  • the authorization process can be: the publisher of the application A sends an authorization request to the system publisher, and the system publisher treats the private key (also called the system private key) with the system.
  • the signature file performs a signature operation, generates an authorization signature file, and returns an authorization signature file to application A, which is also added to application A's signature file list.
  • the authorization mechanism provided by the technical solution enables the system publisher to actively participate in the authorization process of the application. For example, if an application is running in the system and the system publisher obtains the developed application, the system publisher can determine whether it needs to authorize the application according to the function implemented by the application to allow the application to access the system private interface. If necessary, generate the corresponding authorization information (for example: use the system private key to generate an authorized signature file), add it to the application, and then publish the application. In this way, it is convenient for the system publisher to authorize and manage the applications running in the system, which can promote the interaction between the application and the system in the operating environment, and facilitate the application to access the special services provided by the system for the operation of the entire system. Dimensions provide convenience.
  • the application can be judged for the access operation involving a specific private interface executed by the application during the running process. Whether the program has been authorized by the provider side of the particular private interface and allows the application to access the particular private interface on an authorized basis. The process is described in detail below.
  • FIG. 1 is a flowchart of an embodiment of an application access method of an interface according to the present application. The method includes the following steps:
  • Step 101 Receive an access request of a first application to a specific private interface.
  • the first application After the first application is installed, it can be started according to the needs of the user or the configuration of the system. If the application performs an access operation to a specific private interface during the running process, the corresponding access request is usually issued to the accessed party (for example, an application or system that implements the specific private interface or a module that is responsible for interface access control may receive a corresponding access request.
  • the access request may carry a first application identifier, and/or related description information of the specific private interface that is accessed, and the like.
  • Step 102 Determine whether the first application is authorized by the providing side of the specific private interface, and if yes, perform step 103.
  • the authorization information of the specific private interface providing side may be searched for in the authorization information of the first application.
  • the authorization information generally includes identity information of an authorized person who has performed an authorization operation for the first application, and the system usually records the identity information of the provided side of the specific private interface that is accessed by a process such as registration installation. Therefore, in this step, the identity information of the specific private interface providing side may be searched in the authorization information of the first application, and if found, the first application has obtained the authorization of the specific private interface providing side, and thus can be executed.
  • Step 103 allows it to access the particular private interface, otherwise it is not allowed access.
  • the foregoing authorization information may be encrypted by using an encryption algorithm, and the step is performed after performing the corresponding decryption operation, or the step may be performed in cooperation with the server providing the identity verification service.
  • the digital signature technology may be used to generate the authorization information, that is, the signature file.
  • whether the first application is authorized by the providing side of the specific private interface may be determined according to whether the signature file of the specific application interface is included in the signature file list of the first application.
  • this step may extract, from the system, the public key certificate of the providing side of the specific private interface stored in the second application installation process, and Each signature file in the signature file list of the first application determines whether the public key certificate included in the signature file is consistent with the public key certificate on the specific private interface providing side. If they are consistent, the signature file currently participating in the comparison is The specific private interface provides a signature file on the side, indicating that the first application has been authorized by the provider side of the particular private interface.
  • the present embodiment proposes the concept of private authority for the private interface, and divides the authorization judgment process of this step into two parts: installation An application obtains a private permission acquisition operation, and this step can directly obtain a result according to the private permission, and determine whether the first application is authorized by the provider side of the specific private interface.
  • the application or system can declare the corresponding private rights in its configuration file for its externally provided private interface, for example, adding a private description in the permission declaration statement, and the first application can apply for private permission in its configuration file. And perform the operation of obtaining private permissions during the installation process. This preferred embodiment will be described in detail below with reference to FIG.
  • Step 102-1 Extract the public key certificate one by one from the signature file list of the first application, and add it to the signature set.
  • This step may be performed for each signature file in the signature file list by using a digital signature verification technology to verify the signature file and extracting the public key certificate from the verified signature file into the signature set.
  • the verification process is mainly to verify the authenticity of the signature, and also to verify the integrity of the signed file.
  • this step may implement one-by-one verification of the integrity of the signed file.
  • the publisher signature file of the first application is 1.xml
  • the second application publisher generates the authorization signature file 2.xml after signing the 1.xml
  • the third application publisher generates the authorization signature after signing the 2.xml.
  • the file 3.xml is used as an example.
  • the public key certificate in the xml is generated by the signature of the signer; then the summary information of 2.xml is calculated, and the summary information obtained by the comparison is compared with the summary information obtained by performing the decryption operation, and if they are consistent, the description is 2.
  • the integrity of the xml file has not been compromised.
  • the public key certificate in the verified signature file may be added to the signature set to facilitate subsequent comparison of the signature information.
  • Step 102-2 Parse the configuration file of the first application, and extract the private permission information of the private interface that is applied for accessing the system or other application.
  • the first application needs to access the private interface of the system or other application (ie, the application other than the first application), it will indicate in the configuration file the private permission corresponding to the private interface that needs to be applied.
  • This step can extract the private permission information of the application by parsing the configuration file of the first application.
  • Step 102-3 Perform, for each private permission in the private permission information, an operation of extracting a public key certificate corresponding to the private authority from the pre-generated private rights claim information, and in the signature set Finding the public key certificate, and if found, determining that the first application obtains the private authority.
  • the private authority may be affirmed by the application or may be affirmed by the system; the private right
  • the limit declaration information records the correspondence between the private rights claimed by the system and the installed applications and the public key certificate of the claimant.
  • the private authority declaration information may be generated by the installer in the process of installing the system and each application by: parsing the installed application or the configuration file of the system, and obtaining the private permission for accessing the private interface. Extracting a public key certificate from the installed application or the publisher's signature file of the system; establishing a correspondence between the declared private authority and the public key certificate, and adding to the private authority declaration information.
  • This step may be performed for each private right in the private rights information extracted in step 102-2, by performing the following operations: extracting the corresponding public key certificate from the pre-generated private rights declaration information according to the currently processed private rights, and then The public key certificate is searched for in the signature set of the first application, and if found, the first application can be determined to obtain the private right, that is, the first application can access the private interface corresponding to the private right.
  • the above processing is performed for each private authority in the private permission information, and the private permission acquisition process of the first application is completed.
  • the step may determine, according to the permission obtaining result of the foregoing installation process, whether the first application has acquired the specific private interface.
  • the private authority if obtained, may determine that the first application is authorized by the providing side of the specific private interface, otherwise it is determined that the first application is not authorized.
  • Step 103 Allow the first application to access the specific private interface.
  • Executing this step indicating that the first application has been authorized by the providing side of the specific private interface, thus allowing the first application to access the specific private interface, for example, the first application can call a function corresponding to the specific private interface. , or perform various operations included in the specific private interface, and the like.
  • the method for accessing the interface provided by the application provided in this embodiment is described in detail in steps 101-103.
  • the application publisher and the system publisher are provided with the authority to control the private interface.
  • Ability to present the authorization intent of the private interface provider side eliminating the security risks caused by abuse of permissions; and enabling application authors and system publishers to dare to open private interfaces, thereby facilitating effective interaction between applications and between applications and systems To help build a good service ecosystem.
  • an application access method for an interface is provided.
  • the present application further provides an application access device for an interface.
  • FIG. 3 is a schematic diagram of an embodiment of an application access interface device according to the present application. Since the device embodiment is basically similar to the method embodiment, the description is relatively simple, and the relevant parts can be referred to the description of the method embodiment.
  • the device embodiments described below are merely illustrative.
  • the access device of the application to the interface of the embodiment includes: an access request receiving unit 301, configured to receive an access request of the first application to a specific private interface; and an authorization determining unit 302, configured to determine whether the first application is Provided by the providing side of the specific private interface; the access permitting unit 303 is configured to allow the first application to access the specific private interface when the output of the authorization determining unit is YES.
  • the authorization determining unit is configured to determine, according to whether the signature file of the first interface of the first application includes the signature file of the providing side of the private interface, whether the first application is provided by the providing side of the private interface. Authorization.
  • the signature file in the signature file list used by the authorization determining unit includes: a publisher signature file of the first application publisher, or the publisher signature file and the first application different from the first application
  • the publisher's private interface provides the side's authorization signature file.
  • the authorized signature file in the signature file list used by the authorization determining unit is generated by the following unit:
  • An authorization request sending unit configured to send, by the first client, an authorization request to the private interface providing side;
  • the authorization signature file generating unit is configured to perform, by using the digital signature technology, the second client to perform a signature operation on the to-be-signed file carried in the authorization request by using the private key of the private interface to generate a private interface providing side according to the received authorization request.
  • the authorization signature file receiving unit is configured to receive the authorization signature file by the first client and add it to the signature file list of the first application.
  • the to-be-signed file carried in the authorization request sent by the authorization requesting unit includes: a signature file generated last time in the first application signature file list.
  • the device further includes: a rights obtaining unit, configured to acquire, by the first application, a private right for accessing the private interface during the installation process;
  • the authority obtaining unit includes:
  • a signature set generation subunit configured to extract a public key certificate one by one from a list of signature files of the first application, and add the signature to the signature set;
  • a private permission extraction sub-unit configured to parse a configuration file of the first application, and extract private permission information of a private interface that is applied for accessing a system or other application;
  • a private authority obtaining execution subunit configured to: for each private authority in the private authority information, perform an operation of: extracting a public key certificate corresponding to the private authority from the pre-generated private authority claim information; and in the signature set Finding the public key certificate, and if found, determining that the first application acquires the private authority;
  • the authorization determining unit is specifically configured to determine whether the first application has obtained the private permission to access the specific private interface, and if yes, determine that the first application is authorized by the providing side of the specific private interface, otherwise unauthorized.
  • the signature set generation subunit is specifically configured to verify, by using a digital signature verification technology, the signature file for each signature file in the signature file list, and extract the signature file from the verified signature file.
  • a public key certificate is added to the signature set.
  • FIG. 4 is a flowchart of an embodiment of an authorization request method of an application provided by the present application.
  • the same parts of the embodiment are the same as those of the foregoing embodiment, and the differences are mainly described below.
  • An authorization request method for an application provided by the present application includes:
  • Step 401 Send an authorization request to the private interface providing side to request application access. The permissions of the private interface.
  • the authorization request may carry the to-be-signed file of the application, and the to-be-signed file may be the most recently generated signature file in the application signature file list.
  • Step 402 Receive authorization information returned by the private interface providing side.
  • the authorization information may include: an authorization signature file generated by performing a signature operation on the to-be-signed file carried in the authorization request by using the private key of the private interface providing side by using the digital signature technology.
  • Step 403 Add the authorization information to the application.
  • This step may add the received authorization information, for example, an authorization signature file, to the signature file list of the application.
  • an authorization signature file for example, an authorization signature file
  • the authorization side of the private interface may be requested to obtain authorization and obtain correspondingly.
  • Authorization information so that it can be determined during operation of the application that it has been authorized by the provider side of the private interface and further allowed to access the private interface.
  • an authorization request method for an application is provided.
  • the application further provides an authorization request device for the application.
  • FIG. 5 is a schematic diagram of an embodiment of an authorization requesting apparatus of an application of the present application. Since the device embodiment is basically similar to the method embodiment, the description is relatively simple, and the relevant parts can be referred to the description of the method embodiment.
  • the device embodiments described below are merely illustrative.
  • the authorization requesting device of the application of the embodiment includes: an authorization request sending unit 501, configured to send an authorization request to the private interface providing side, requesting permission for the application to access the private interface; and an authorization information receiving unit 502,
  • the authorization information adding unit 503 is configured to receive the authorization information returned by the private interface providing side, and is used to add the authorization information to the application.
  • the authorization request sent by the authorization request sending unit carries the to-be-signed file of the application
  • the authorization information received by the authorization information receiving unit includes: an authorization signature file generated by performing a signature operation on the to-be-signed file by using a private key of the private interface providing side by using a digital signature technology;
  • the authorization information adding unit is specifically configured to add the authorization signature file received by the authorization information receiving unit to the signature file list of the application.
  • FIG. 6 is a flowchart of an embodiment of an application authorization method provided by the present application. The same parts of the embodiment are the same as those of the foregoing embodiment, and the differences are described below.
  • An authorization method for an application provided by the present application includes:
  • Step 601 Determine an application to be authorized.
  • the authorization request of the private interface is granted according to the received request, and the authorized application is determined.
  • the authorization request may carry the name or identifier of the application to be authorized, and the like. You can carry the file to be signed.
  • this step may also determine the to-be-authorized application from the to-be-published application operated by the system.
  • the file to be signed may be the relevant file of the identified application to be authorized.
  • the most recently generated signature file in the signature file list of the to-be-authorized application may be used as the to-be-signed file.
  • Step 602 Generate authorization information indicating that the private interface providing side allows the to-be-authorized application to access the private interface.
  • the digital signature technology may be used to perform a signature operation on the to-be-signed file of the to-be-authorized application by using the private key of the private interface providing side to generate an authorization signature file, where the authorization signature file is the authorization information.
  • the generated authorization information such as an authorization signature file
  • the generated authorization information may also be returned to the sender of the authorization request after performing step 602;
  • the generated authorization information such as an authorization signature file, may be added to the signature file list of the application.
  • the private interface providing side can generate authorization information for the application that needs to access the private interface in advance, so that the application can be It is determined during operation that it has been authorized by the provider side of the private interface and allowed to access the private interface.
  • FIG. 7 is a schematic diagram of an embodiment of an authorization device for an application of the present application. Since the device embodiment is basically similar to the method embodiment, the description is relatively simple, and the relevant parts can be referred to the description of the method embodiment.
  • the device embodiments described below are merely illustrative.
  • the authorization device of the application program of the embodiment includes: an application to be authorized determining unit 701, configured to determine an application to be authorized; an authorization information generating unit 702, configured to generate a representation of the private interface providing side to allow the to-be-authorized application The program accesses the authorization information of the private interface.
  • the authorization information generating unit is configured to perform a signature operation on the to-be-signed file of the to-be-authorized application by using a private key of the private interface providing side by using a digital signature technology to generate an authorized signature file.
  • the authorization signature file is the authorization information.
  • the to-be-authorized application determining unit is specifically configured to determine, according to the received request, an authorization request for granting access rights of the private interface, to determine the to-be-authorized application;
  • the file to be signed used by the authorization information generating unit includes: a file carried in the authorization request;
  • the device further includes: an authorization signature file returning unit, configured to return the authorization signature file generated by the authorization information generating unit to the sender of the authorization request.
  • the to-be-authorized application determining unit is specifically configured to determine the to-be-authorized application from the to-be-published application that is operated by the system;
  • the file to be signed adopted by the authorization information generating unit includes: a related file of the application to be authorized;
  • the device further includes: an authorization signature file adding unit, configured to add the authorization signature file generated by the authorization information generating unit to the signature file list of the application.
  • FIG. 8 is a flowchart of an embodiment of a method for obtaining rights of an application provided by the present application.
  • the parts of the embodiment that are identical to the steps of the foregoing embodiment are not described again. The differences are mainly described below.
  • the method for obtaining permission of an application provided by the application includes:
  • Step 801 Extract information representing the identity of the grantor one by one from the authorization information of the application, and add the information to the authorized identity set.
  • the authorization information is information indicating that the private interface providing side allows the application to access its private interface, and the authorization information includes at least information that identifies the identity of the authorized person (for example, an ID number that uniquely identifies the identity of the authorized person), and may also include Information such as the identification of the application. In this step, information identifying the identity of the grantor is extracted one by one from the authorization information of the application, and added to the authorized identity set.
  • the authorization information is a signature file list
  • the information identifying the identity of the licensor is a public key certificate
  • the licensor identity set is a signature set.
  • the signature file list may include: a publisher signature file of the application publisher, or the publisher signature file and an authorization signature file different from the private interface providing side of the application publisher.
  • Step 802 Parse the configuration file of the application, and extract private permission information of the application for accessing the private interface.
  • Step 803 Perform, for each private permission in the private rights information, the following operations: extracting identity information corresponding to the private rights from the pre-generated private rights claim information, and searching in the authorized identity set The identity information, if found, determines that the application obtains the private authority.
  • the private authority declaration information may be generated in the process of installing the system and each application, and the corresponding relationship between each private right declared by the system and the installed application and the identity information of the affirmative party is recorded.
  • the method can determine the private authority of the application according to the authorization information of the application and the private authority applied by the application, so as to facilitate determining whether the application is provided by the private interface.
  • implementing the above steps in the process of installing an application can simplify the process of judging the authorization status during the running of the application, and improve the execution efficiency.
  • FIG. 9 is a schematic diagram of an embodiment of an authority obtaining apparatus of an application according to the present application. Since the device embodiment is basically similar to the method embodiment, the description is relatively simple, and the relevant parts can be referred to the description of the method embodiment. The device embodiments described below are merely illustrative.
  • the privilege obtaining apparatus of the application program of the embodiment includes: an identity set generating unit 901, configured to extract information identifying the licensor identity one by one from the authorization information set of the application, and add the information to the licensor identity set;
  • the privilege extracting unit 902 is configured to parse the configuration file of the application, and extract the private privilege information of the application for accessing the private interface.
  • the privilege obtaining unit 903 is configured to determine whether the application obtains the private privilege information. Private authority in ;
  • the private authority obtaining unit includes:
  • a loop control subunit configured to trigger an identity information extraction subunit and a search decision subunit in sequence for each private authority in the private authority information
  • An identity information extraction subunit configured to extract identity information corresponding to the currently processed private authority from the pre-generated private rights declaration information
  • a determining determining subunit configured to search for the identity information extracted by the identity information extracting subunit in the set of authorized identity, and if found, determine that the application obtains the private right.
  • a computing device includes one or more processors (CPUs), input/output interfaces, network interfaces, and memory.
  • processors CPUs
  • input/output interfaces network interfaces
  • memory volatile and non-volatile memory
  • the memory may include non-persistent memory, random access memory (RAM), and/or non-volatile memory in a computer readable medium, such as read only memory (ROM) or flash memory.
  • RAM random access memory
  • ROM read only memory
  • Memory is an example of a computer readable medium.
  • Computer readable media including both permanent and non-persistent, removable and non-removable media may be implemented by any method or technology.
  • the information can be computer readable instructions, data structures, modules of programs, or other data.
  • Examples of computer storage media include, but are not limited to, phase change memory (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), other types of random access memory (RAM), read only memory. (ROM), electrically erasable programmable read only memory (EEPROM), flash memory or other memory technology, compact disk read only memory (CD-ROM), digital versatile disk (DVD) or other optical storage, Magnetic tape cartridges, magnetic tape storage or other magnetic storage devices or any other non-transportable media can be used to store information that can be accessed by a computing device.
  • computer readable media does not include non-transitory computer readable media, such as modulated data signals and carrier waves.
  • embodiments of the present application can be provided as a method, system, or computer program product.
  • the present application can take the form of an entirely hardware embodiment, an entirely software embodiment or an embodiment in combination of software and hardware.
  • the application can take the form of a computer program product embodied on one or more computer-usable storage media (including but not limited to disk storage, CD-ROM, optical storage, etc.) including computer usable program code.

Landscapes

  • Engineering & Computer Science (AREA)
  • Software Systems (AREA)
  • Theoretical Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Physics & Mathematics (AREA)
  • Computer Hardware Design (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Technology Law (AREA)
  • Multimedia (AREA)
  • Health & Medical Sciences (AREA)
  • Bioethics (AREA)
  • General Health & Medical Sciences (AREA)
  • Databases & Information Systems (AREA)
  • Storage Device Security (AREA)

Abstract

一种应用程序对接口的访问方法及装置，一种应用程序的授权请求方法及装置，一种应用程序的授权方法及装置，以及一种应用程序的权限获取方法及装置。其中，所述应用程序对接口的访问方法，包括：接收第一应用程序对特定私有接口的访问请求(101)；判断第一应用程序是否由所述特定私有接口的提供侧授权(102)；若是，允许第一应用程序访问所述特定私有接口(103)。采用上述方法，为应用程序发布者以及系统发布者提供了对私有接口的权限控制能力，能够呈现私有接口提供侧的授权意图，消除滥用权限导致的安全隐患；而且通过私有接口的开放，能够促进应用程序之间、以及应用程序与系统之间的有效交互，有助于构建良好的服务生态环境。

Description

应用程序对接口的访问方法、授权请求方法及装置 技术领域
本申请涉及接口访问方法，具体涉及一种应用程序对接口的访问方法及装置。本申请同时涉及一种应用程序的授权请求方法及装置，一种应用程序的授权方法及装置，以及一种应用程序的权限获取方法及装置。
背景技术
为了促进应用程序之间的交互，应用程序可以将一些特定操作，例如：对硬件资源的操作、对内部数据的操作、对组件的操作等，封装成接口的形式，供其他应用程序访问。在促进应用程序之间交互的基础上，为了提供安全性保障，系统平台通常采用权限机制对接口的访问进行必要的控制。
以Android系统为例，一方面，其自带一些用于对特定接口执行访问操作的权限，同时也允许应用程序的作者(即开发者)在AndroidManifest.xml文件用<permission>元素来声明权限，用于限制对其内部接口的访问操作；另一方面，对于需要访问受权限保护的接口的应用程序，则可以在AndroidManifest.xml文件中申明所需获取的权限，并分别用<use-permission>元素标识。
当应用程序访问受权限保护的接口时，系统或者提供接口的应用程序通常根据用户做出的决定(例如在安装应用程序时，被请求权限通常会显示在设备屏幕上待用户确认)确定应用程序是否具有访问相应接口的权限，并在具有时允许应用程序执行相应的接口访问操作。
通过上面的描述可以看出，应用程序对接口的访问控制权通常由设备的持有者(即用户)掌控，而不是由接口的提供者(例如：应用程序作者)掌控，无法体现接口提供者的授权意图，因此在实际应用中存在开发者滥用权限、以及黑客通过获取权限来执行恶意操作的安全隐患；而且由于上述原因，导致应用程序作者不敢轻易开放敏感接口(例如：涉及资金、用 户隐私数据等操作的接口，也称私有接口)，从而无法促进应用程序之间的有效交互，不利于构建良好的应用程序生态环境。
发明内容
本申请实施例提供一种应用程序对接口的访问方法和装置，以解决现有访问控制权由用户掌控而导致的安全隐患、以及应用程序之间无法构建有效交互关系的问题。本申请实施例还提供一种应用程序的授权请求方法和装置，一种应用程序的授权方法和装置，以及一种应用程序的权限获取方法及装置。
本申请提供一种应用程序对接口的访问方法，包括：
接收第一应用程序对特定私有接口的访问请求；
判断第一应用程序是否由所述特定私有接口的提供侧授权；
若是，允许第一应用程序访问所述特定私有接口。
可选的，所述特定私有接口的提供侧包括：提供所述特定私有接口的系统发布者、或者提供所述特定私有接口的第二应用程序发布者。
可选的，所述判断第一应用程序是否由所述特定私有接口的提供侧授权，包括：
根据第一应用程序的签名文件列表中是否包含所述特定私有接口的提供侧的签名文件，判断第一应用程序是否由所述特定私有接口的提供侧授权。
可选的，所述签名文件列表中的签名文件的内容包括：摘要信息，用签名者的私钥加密所述摘要信息生成的数字签名，以及签名者的公钥证书。
可选的，所述签名文件列表包括：第一应用程序发布者的发布者签名文件，或者，所述发布者签名文件以及不同于所述第一应用程序发布者的私有接口提供侧的签名文件。
可选的，当所述签名文件列表中包含私有接口提供侧的授权签名文件时，生成所述授权签名文件的方式包括：
第一客户端向私有接口提供侧发送授权请求；
第二客户端根据接收到的授权请求，利用数字签名技术，采用私有接口提供侧的私钥对授权请求中携带的待签名文件执行签名操作，生成私有接口提供侧的授权签名文件并返回给第一客户端；
第一客户端接收所述授权签名文件，并将其添加到第一应用程序的签名文件列表中。
可选的，所述待签名文件包括：第一应用程序签名文件列表中的、最近一次生成的签名文件。
可选的，所述第一应用程序的安装过程包括下述权限获取步骤：
从第一应用程序的签名文件列表中逐一提取公钥证书，并添加到签名集合中；
解析第一应用程序的配置文件，提取其申请的、用于访问系统或者其他应用程序的私有接口的私有权限信息；
针对所述私有权限信息中的每个私有权限，执行下述操作：
从预先生成的私有权限申明信息中提取所述私有权限对应的公钥证书；
在所述签名集合中查找所述公钥证书，若找到，则判定第一应用程序获取所述私有权限；
相应的，所述根据第一应用程序的签名文件列表中是否包含所述特定私有接口的提供侧的签名文件，判断第一应用程序是否由所述特定私有接口的提供侧授权，包括：
判断第一应用程序是否已获取访问所述特定私有接口的私有权限，若是，则判定第一应用程序由所述特定私有接口的提供侧授权，否则未授权。
可选的，所述从第一应用程序的签名文件列表中逐一提取公钥证书，并添加到签名集合中，包括：
针对所述签名文件列表中的每个签名文件，执行以下操作：
通过数字签名验证技术，对所述签名文件进行验证；
从通过验证的签名文件中提取公钥证书、并添加到所述签名集合中。
相应的，本申请还提供一种应用程序对接口的访问装置，包括：
访问请求接收单元，用于接收第一应用程序对特定私有接口的访问请求；
授权判断单元，用于判断第一应用程序是否由所述特定私有接口的提供侧授权；
访问允许单元，用于当所述授权判断单元的输出为是时，允许第一应用程序访问所述特定私有接口。
可选的，所述授权判断单元，具体用于根据第一应用程序的签名文件列表中是否包含所述私有接口的提供侧的签名文件，判断第一应用程序是否由所述私有接口的提供侧授权。
可选的，所述授权判断单元所采用的签名文件列表中的签名文件包括：第一应用程序发布者的发布者签名文件，或者，所述发布者签名文件以及不同于所述第一应用程序发布者的私有接口提供侧的授权签名文件。
可选的，所述授权判断单元所采用的签名文件列表中的授权签名文件是由以下单元生成的：
授权请求发送单元，用于第一客户端向私有接口提供侧发送授权请求；
授权签名文件生成单元，用于第二客户端根据接收到的授权请求，利用数字签名技术，采用私有接口提供侧的私钥对授权请求中携带的待签名文件执行签名操作，生成私有接口提供侧的授权签名文件并返回给第一客户端；
授权签名文件接收单元，用于第一客户端接收所述授权签名文件，并将其添加到第一应用程序的签名文件列表中。
可选的，所述授权请求单元所发送的授权请求中携带的待签名文件包括：第一应用程序签名文件列表中的、最近一次生成的签名文件。
可选的，所述装置还包括：权限获取单元，用于第一应用程序在安装过程中获取用于访问私有接口的私有权限；
所述权限获取单元包括：
签名集合生成子单元，用于从第一应用程序的签名文件列表中逐一提取公钥证书，并添加到签名集合中；
私有权限提取子单元，用于解析第一应用程序的配置文件，提取其申请的、用于访问系统或者其他应用程序的私有接口的私有权限信息；
私有权限获取执行子单元，用于针对所述私有权限信息中的每个私有权限，执行下述操作：从预先生成的私有权限申明信息中提取私有权限对应的公钥证书；在所述签名集合中查找所述公钥证书，若找到，则判定第一应用程序获取所述私有权限；
相应的，所述授权判断单元，具体用于判断第一应用程序是否已获取访问所述特定私有接口的私有权限，若是，则判定第一应用程序由所述特定私有接口的提供侧授权，否则未授权。
可选的，所述签名集合生成子单元，具体用于针对所述签名文件列表中的每个签名文件，通过数字签名验证技术对所述签名文件进行验证，并从通过验证的签名文件中提取公钥证书添加到所述签名集合中。
此外，本申请还提供一种应用程序的授权请求方法，包括：
向私有接口提供侧发送授权请求，请求授予应用程序访问所述私有接口的权限；
接收所述私有接口提供侧返回的授权信息；
并将所述授权信息添加到所述应用程序中。
可选的，所述授权请求中携带所述应用程序的待签名文件；
所述授权信息包括：利用数字签名技术，采用所述私有接口提供侧的私钥对所述待签名文件执行签名操作后生成的授权签名文件；
所述将所述授权信息添加到所述应用程序中，包括：将接收到的授权签名文件添加到所述应用程序的签名文件列表中。
可选的，所述授权请求中携带的待签名文件包括：所述应用程序签名文件列表中的、最近一次生成的签名文件。
相应的，本申请还提供一种应用程序的授权请求装置，包括：
授权请求发送单元，用于向私有接口提供侧发送授权请求，请求授予应用程序访问所述私有接口的权限；
授权信息接收单元，用于接收所述私有接口提供侧返回的授权信息；
授权信息添加单元，用于将所述授权信息添加到所述应用程序中。
此外，本申请还提供一种应用程序的授权方法，包括：
确定待授权应用程序；
生成表征私有接口提供侧允许所述待授权应用程序访问私有接口的授权信息。
可选的，所述生成表征私有接口提供侧允许所述待授权应用程序访问私有接口的授权信息，包括：
利用数字签名技术，采用所述私有接口提供侧的私钥对所述待授权应用程序的待签名文件执行签名操作，生成授权签名文件，所述授权签名文件即为所述授权信息。
可选的，所述确定待授权应用程序，包括：根据接收到的请求授予私有接口访问权限的授权请求，确定所述待授权应用程序；
所述待签名文件包括：所述授权请求中携带的文件；
所述方法还包括：
将生成的授权签名文件返回给所述授权请求的发送方。
可选的，所述确定待授权应用程序，包括：从系统运营的待发布应用程序中确定所述待授权应用程序；
所述待签名文件包括：所述待授权应用程序的相关文件；
所述方法还包括：
将生成的授权签名文件添加到所述应用程序的签名文件列表中。
可选的，所述待签名文件为：所述待授权应用程序的签名文件列表中的、最近一次生成的签名文件。
相应的，本申请还提供一种应用程序的授权装置，包括：
待授权应用程序确定单元，用于确定待授权应用程序；
授权信息生成单元，用于生成表征私有接口提供侧允许所述待授权应用程序访问私有接口的授权信息。
此外，本申请还提供一种应用程序的权限获取方法，包括：
从应用程序的授权信息中逐一提取表征授权者身份的信息，并添加到授权者身份集合中；
解析所述应用程序的配置文件，提取其申请的用于访问私有接口的私有权限信息；
针对所述私有权限信息中的每个私有权限，执行下述操作：
从预先生成的私有权限申明信息中提取所述私有权限对应的身份信息；
在所述授权者身份集合中查找所述身份信息，若找到，则判定所述应用程序获取所述私有权限。
可选的，所述授权信息包括：签名文件列表，所述表征授权者身份的信息包括：公钥证书，所述授权者身份集合包括：签名集合。
可选的，所述签名文件列表包括：所述应用程序发布者的发布者签名文件，或者，所述发布者签名文件以及不同于所述应用程序发布者的私有接口提供侧的授权签名文件。
相应的，本申请还提供一种应用程序的权限获取装置，包括：
身份集合生成单元，用于从应用程序的授权信息集合中逐一提取表征授权者身份的信息，并添加到授权者身份集合中；
私有权限提取单元，用于解析所述应用程序的配置文件，提取其申请的用于访问私有接口的私有权限信息；
私有权限获取单元，用于判定所述应用程序是否获取所述私有权限信息中的私有权限；
所述私有权限获取单元，包括：
循环控制子单元，用于针对私有权限信息中的每个私有权限，依次触发身份信息提取子单元、以及查找判定子单元工作；
身份信息提取子单元，用于从预先生成的私有权限申明信息中提取对应于当前处理的私有权限的身份信息；
查找判定子单元，用于在所述授权者身份集合中查找所述身份信息提取子单元所提取的身份信息，若找到，则判定所述应用程序获取所述私有权限。
与现有技术相比，本申请具有以下优点：
本申请提供的应用程序对接口的访问方法，接收第一应用程序对特定私有接口的访问请求，判断第一应用程序是否由所述特定私有接口的提供侧授权，并在第一应用程序已被授权的情况下，允许其访问所述特定私有接口。采用上述方法，为应用程序发布者以及系统发布者提供了对私有接口的权限控制能力，能够呈现私有接口提供侧的授权意图，消除滥用权限导致的安全隐患；而且通过私有接口的开放，能够促进应用程序之间、以及应用程序与系统之间的有效交互，有助于构建良好的服务生态环境。此外，采用本申请提供的上述方法，使系统发布者主动参与到应用程序的授权过程成为可能，为系统发布者的运维提供便利。
附图说明
图1是本申请提供的一种应用程序对接口的访问方法的实施例的流程图；
图2是本申请实施例提供的在安装过程中获取私有权限的处理流程图；
图3是本申请提供的一种应用程序对接口的访问装置的实施例的示意图；
图4是本申请提供的一种应用程序的授权请求方法的实施例的流程图；
图5是本申请提供的一种应用程序的授权请求装置的实施例的示意图；
图6是本申请提供的一种应用程序的授权方法的实施例的流程图；
图7是本申请提供的一种应用程序的授权装置的实施例的示意图；
图8是本申请提供的一种应用程序的权限获取方法的实施例的流程图；
图9是本申请提供的一种应用程序的权限获取装置的实施例的示意图。
具体实施方式
在下面的描述中阐述了很多具体细节以便于充分理解本申请。但是，本申请能够以很多不同于在此描述的其它方式来实施，本领域技术人员可以在不违背本申请内涵的情况下做类似推广，因此，本申请不受下面公开的具体实施的限制。
在本申请中，分别提供了一种应用程序对接口的访问方法及装置，一种应用程序的授权请求方法及装置，一种应用程序的授权方法及装置，以及一种应用程序的权限获取方法及装置，在下面的实施例中逐一进行详细说明。
现有技术中，应用程序对系统或者其他应用程序提供的接口的访问控制权通常由设备的持有者(即用户)掌控，而不是由接口的提供者掌控，无法体现接口提供者的授权意图，因此在实际应用中存在开发者滥用权限、以及黑客通过获取权限来执行恶意操作的安全隐患；而且由于上述原因，导致应用程序作者不敢轻易开放敏感接口，从而无法促进应用程序之间的有效交互，不利于构建良好的应用程序生态环境。
针对上述问题，本申请提供的应用程序对接口的访问方法，其核心在于，在判断应用程序能否访问特定私有接口时，是以所述特定私有接口的提供侧是否已为应用程序授权为判断标准，也即只有当所述特定私有接口的提供侧已对应用程序授权的情况下，才允许应用程序访问所述特定私有接口。从而可以体现私有接口提供侧的授权意图，消除滥用权限导致的安全隐患，而且通过私有接口的开放，能够促进应用程序之间、以及应用程序与系统之间的有效交互，有助于构建良好的服务生态环境。
本申请所述的私有接口是指，需要得到私有接口提供侧的授权之后才能进行访问的接口，通常是一些执行敏感操作的接口，例如：涉及资金、用户隐私数据等操作的接口。私有接口的提供侧，通常是指提供私有接口的系统发布者或者应用程序发布者，也可以是其他能够提供私有接口的个人或团体。
所述特定私有接口，则是指在实施本申请的方法时所针对的某个被访问的具体的私有接口，所述特定私有接口的提供侧，通常是指提供所述特定私有接口的系统发布者或者应用程序发布者，也可以是其他能够提供所述特定私有接口的个人或团体。
所述特定私有接口可以属于某个系统(由某个系统实现)、也可以属于某个应用程序(由某个应用程序实现)，由此可见，本申请的技术方案为系统敏感接口、以及应用程序敏感接口，提供了统一的保护机制，便于应用程序开发人员以及系统运维人员实施。
在发布应用程序之前，对于需要访问私有接口的应用程序，如果所述私有接口是所述应用程序发布者发布的其他应用程序中的接口(即，所述私有接口是由发布者自己提供的)，那么该发布者可以为需要访问私有接口的应用程序生成授权信息、并添加到所述应用程序中；如果所述私有接口不是由该发布者自己提供的，那么该发布者可以向提供所述私有接口的私有接口提供侧发送授权请求，请求后者授予所述应用程序相应的访问权限，私有接口提供侧如果同意所述应用程序访问所述私有接口，则生成相应的授权信息(例如，授权信息中可以包括授权者的身份信息、以及所述应用程序的标识等)，并将该授权信息返回给所述应用程序的发布者，所述应用程序的发布者则可以将授权信息添加到所述应用程序中，例如添加到其安装包中。在具体应用中，应用程序发布者可以根据私有接口访问需求，请求一个或者一个以上私有接口提供侧为应用程序授权，并将得到的授权信息都添加到应用程序中。
当应用程序在个人电脑或者移动通讯设备等电子设备上被安装使用后，如果提出对某一私有接口的访问请求，被访问方(实现私有接口的应用程序或者系统)或者负责接口访问控制的模块，可以根据所述应用程携带的 授权信息，采用预设的验证算法或者与提供验证服务的服务端交互验证的方式，检查所述应用程序是否已得到所述私有接口提供侧的授权，若得到，则允许所述应用程序访问所述私有接口，否则拒绝访问。
优选地，为了避免授权信息被伪造，保证授权信息的真实性，可以采用数字签名技术生成授权信息，即：签名的过程就是授权的过程。采用这种方式，通过授权过程可以生成签名文件列表，当应用程序访问某一私有接口时，则可以根据该应用程序的签名文件列表中是否包含所述私有接口的提供侧的签名文件，决定是否允许访问。
在具体应用中，为了确定应用程序的唯一性，保障应用程序的来源不被篡改，通常会由应用程序的发布者为应用程序签名生成发布者签名文件(例如：Android系统采用的应用签名机制)，本技术方案可以在此基础上实施上述优选实施方式，即在传统的发布者签名的基础上，支持多签名机制：在发布应用程序之前，应用程序发布者首先对应用程序签名、生成发布者签名文件(相当于为应用程序进行了授权，使其可以访问同一发布者发布的其他应用程序中的私有接口)，此后，应用程序发布者还可以通过发送授权请求的方式请求其他私有接口提供侧为应用程序签名，生成私有接口提供侧的签名文件。也即，应用程序不仅可以拥有发布者的签名，还可以拥有一个或者一个以上不同于应用程序发布者的私有接口提供侧的签名，采用这种多签名机制，不仅便于验证授权信息的真实性，而且易于扩展。
下面以在传统发布者签名的基础上支持多签名机制为例，对发布者签名过程及不同应用程序发布者间的授权过程作进一步说明，为了便于描述，在本例中将需要获得授权的应用程序称为应用程序A，应用程序A为了实现其功能需要访问应用程序B中的私有接口，并且应用程序A和应用程序B的发布者不同。
首先，应用程序A的发布者用其私钥对应用程序A签名，生成发布者签名文件。所述签名过程可以包括以下操作：采用预先设定的摘要算法，例如：MD5、SHA-0或者SHA-1算法生成应用程序A的摘要信息，利用应用程序A发布者的私钥对摘要信息加密(例如可以采用RSA加密算法) 得到数字签名，最后将摘要信息、数字签名、以及应用程序A发布者的公钥证书(通常包含发布者的公钥、身份信息、生成数字签名采用的加密算法等)写入签名文件中，例如：1.xml文件，从而生成了发布者签名文件，并将发布者签名文件添加到应用程序A的签名文件列表中。
其次，应用程序A的发布者通过第一客户端向私有接口提供侧，即应用程序B的发布者，发送授权请求，授权请求中携带应用程序A的待签名文件。
应用程序B的发布者通过第二客户端接收授权请求后，采用其私钥对授权请求中携带的待签名文件执行签名操作，生成授权签名文件。签名过程可以包括以下操作：采用预先设定的摘要算法，例如：MD5、SHA-0或者SHA-1算法生成待签名文件的摘要信息，利用应用程序B发布者的私钥对摘要信息加密得到数字签名，最后将生成的摘要信息、数字签名、以及应用程序B发布者的公钥证书(通常包含应用程序B发布者的公钥、身份信息、生成数字签名采用的加密算法等)写入签名文件中，例如：2.xml文件，从而生成了应用程序B的发布者对应用程序A的授权签名文件，并将该文件返回给第一客户端。
最后，应用程序A的发布者通过第一客户端接收上述授权签名文件后，将该授权签名文件添加到应用程序A的签名文件列表中，从而完成了应用程序B的发布者向应用程序A的授权过程。
在上面描述的授权过程中，应用程序A在授权请求中携带的待签名文件，通常是应用程序A的相关文件，例如，可以是应用程序A的安装包中除去签名文件列表之外的所有文件。
优选地，为了减少对网络带宽的占用、以及提供对被签名文件完整性的逐一验证机制，所述待签名文件可以是应用程序A的签名文件列表中的、最近一次生成的签名文件。
例如：应用程序A需要访问应用程序B和应用程序C中的私有接口，那么应用程序A的发布者在对应用程序A签名生成发布者签名文件1.xml、并添加到应用程序A的签名文件列表后(此时1.xml文件是最近一次生成 的签名文件)，可以将1.xml文件发送给应用程序B的发布者，并将应用程序B的发布者返回的授权签名文件2.xml也添加到签名文件列表中，此时应用程序A的签名文件列表中包括1.xml文件和2.xml文件(此时2.xml文件是最近一次生成的签名文件)；此后，应用程序A的发布者再将2.xml文件发送给应用程序C的发布者，并将应用程序C的发布者返回的授权签名文件3.xml添加到签名文件列表中，此时该签名文件列表中包括3个签名文件，应用程序A不仅可以访问其发布者发布的其他应用程序中的私有接口，也相应得到了应用程序B和应用程序C的发布者的授权。
采用上述优选实施方式，便于对签名文件的完整性进行验证，例如：在安装应用程序A的过程中进行签名文件验证时，可以用3.xml验证2.xml的完整性，用2.xml验证1.xml的完整性。
上面的例子描述了不同应用程序发布者之间的授权过程，在实际应用中，承载应用程序A的系统也可以对外开放私有接口，应用程序A可以根据自己的需求访问系统开放的私有接口，在这种情况下，私有接口提供侧可以为系统发布者，上述授权过程可以为：应用程序A的发布者向系统发布者发送授权请求，系统发布者利用其私钥(也称系统私钥)对待签名文件执行签名操作，生成授权签名文件，并向应用程序A返回授权签名文件，该文件同样被添加到应用程序A的签名文件列表中。
此外，采用本技术方案提供的授权机制，使系统发布者主动参与到应用程序的授权过程成为可能。例如，某应用程序在系统中运营，系统发布者获取开发完毕的应用程序后，系统发布者可以根据应用程序实现的功能，判断是否需要向应用程序授权、以允许应用程序访问系统私有接口，如果需要则生成相应的授权信息(例如：利用系统私钥生成授权签名文件)，并添加到应用程序中，随后再将应用程序上架发布。采用这种方式，便于系统发布者对在本系统内运营的应用程序进行授权管理，可以促进运营环境中应用程序与系统间的交互，便于应用程序访问系统提供的特殊服务，为整个系统的运维提供便利。
以上对应用程序的授权过程进行了描述，在此基础上，就可以针对应用程序在运行过程中执行的涉及某一特定私有接口的访问操作，判断应用 程序是否已经得到了所述特定私有接口的提供侧的授权，并在得到授权的基础上允许应用程序访问所述特定私有接口。下面对该过程作详细说明。
请参考图1，其为本申请的一种应用程序对接口的访问方法的实施例的流程图。所述方法包括如下步骤：
步骤101、接收第一应用程序对特定私有接口的访问请求。
第一应用程序在安装后，可以根据使用者的需求或者系统的配置启动运行，如果应用程序在运行过程中执行对某特定私有接口的访问操作，通常会发出相应的访问请求，被访问方(例如实现所述特定私有接口的应用程序或者系统)或者负责接口访问控制的模块，则可以接收到相应的访问请求。所述访问请求中可以携带第一应用程序标识，和/或被访问的所述特定私有接口的相关描述信息等。
步骤102、判断第一应用程序是否由所述特定私有接口的提供侧授权，若是，则执行步骤103。
本步骤可以在第一应用程序的授权信息中，查找所述特定私有接口提供侧的授权信息。例如：所述授权信息通常包括已针对第一应用程序执行授权操作的授权者的身份信息，而系统通常通过注册安装等过程，记录了被访问的所述特定私有接口的提供侧的身份信息，因此本步骤可以在第一应用程序的授权信息中，查找所述特定私有接口提供侧的身份信息，若找到则说明第一应用程序已得到了所述特定私有接口提供侧的授权，因此可以执行步骤103允许其访问所述特定私有接口，否则不允许其访问。在具体实施时，上述授权信息可以采用加密算法加密、本步骤则在执行相应的解密操作后进行判断，或者本步骤可以与提供身份验证服务的服务端协同执行，都是可以的。
优选地，如前面所述，为了避免授权信息被伪造，保证授权信息的真实性，可以采用数字签名技术生成授权信息，即：签名文件。相应的，本步骤则可以根据第一应用程序的签名文件列表中是否包含所述特定私有接口提供侧的签名文件，判断第一应用程序是否由所述特定私有接口的提供侧授权。
以第一应用程序访问第二应用程序的所述特定私有接口为例，本步骤可以从系统提取在第二应用程序安装过程中存储的所述特定私有接口的提供侧的公钥证书，并针对第一应用程序的签名文件列表中的每个签名文件，判断其中包含的公钥证书是否与所述特定私有接口提供侧的公钥证书一致，若一致，则当前参与比对的签名文件即为所述特定私有接口提供侧的签名文件，那么说明第一应用程序已由所述特定私有接口的提供侧授权。
优选地，为了简化本步骤的处理过程，提高执行效率，同时也为了便于进行权限管理，本实施例针对私有接口提出私有权限的概念，并将本步骤的授权判断过程分为两部分：安装第一应用程序时执行私有权限的获取操作，而本步骤则可以直接根据私有权限获取结果，判断第一应用程序是否被所述特定私有接口的提供侧授权。
应用程序或者系统可以在其配置文件中针对其对外提供的私有接口申明相应的私有权限，例如在权限申明语句中添加Private描述信息，而第一应用程序则可以在其配置文件中申请私有权限，并在安装的过程中执行获取私有权限的操作。下面结合图2对这种优选实施方式作详细说明。
在第一应用程序的安装过程中时，执行下述步骤102-1至步骤102-3：
步骤102-1、从第一应用程序的签名文件列表中逐一提取公钥证书，并添加到签名集合中。
本步骤可以针对签名文件列表中的每个签名文件，执行以下操作：通过数字签名验证技术，对所述签名文件进行验证，并从通过验证的签名文件中提取公钥证书添加到签名集合中。
验证的过程主要是验证签名的真实性，同时也可以验证被签名文件的完整性。优选地，如果在签名授权的过程中，私有接口提供侧对第一应用程序签名文件列表中的、最近一次生成的签名文件执行签名操作，那么本步骤可以实现对被签名文件完整性的逐一验证。以第一应用程序的发布者签名文件为1.xml，第二应用程序发布者对1.xml签名后生成授权签名文件2.xml，第三应用程序发布者对2.xml签名后生成授权签名文件3.xml为例，本步骤采用数字签名验证技术对每个签名文件进行验证的过程如下所示：
a)用3.xml中的公钥证书所包含的公钥对3.xml中的数字签名进行解密，如果得到的摘要信息与3.xml中的摘要信息一致，则说明，该签名文件确实是3.xml中的公钥证书所述签名者签名生成的；随后计算2.xml的摘要信息，比对计算得到的摘要信息与执行解密操作得到的摘要信息是否一致，若一致，则说明2.xml文件的完整性没有遭到破坏。
b)用2.xml中的公钥证书所包含的公钥对2.xml中的数字签名进行解密，如果得到的摘要信息与2.xml中的摘要信息一致，则说明，该签名文件确实是2.xml中的公钥证书所述签名者签名生成的；随后计算1.xml的摘要信息，比对计算得到的摘要信息与执行解密操作得到的摘要信息是否一致，若一致，则说明1.xml文件的完整性没有遭到破坏。
c)用1.xml中的公钥证书所包含的公钥对1.xml中的数字签名进行解密，如果得到的摘要信息与1.xml中的摘要信息一致，则说明，该签名文件确实是1.xml中的公钥证书所述签名者签名生成的；随后计算第一应用程序的摘要信息，比对计算得到的摘要信息与执行解密操作得到的摘要信息是否一致，若一致，则说明第一应用程序的完整性没有遭到破坏。
在上述验证的过程中，可以将通过验证的签名文件中的公钥证书添加到签名集合中，以便于后续步骤进行签名信息的比对。
步骤102-2、解析第一应用程序的配置文件，提取其申请的、用于访问系统或者其他应用程序的私有接口的私有权限信息。
第一应用程序如果需要访问系统或者其他应用程序(即：除第一应用程序之外的应用程序)的私有接口，则会在其配置文件中注明需要申请的与私有接口相对应的私有权限，本步骤可以通过解析第一应用程序的配置文件，提取其申请的私有权限信息。
步骤102-3、针对所述私有权限信息中的每个私有权限，执行下述操作：从预先生成的私有权限申明信息中提取所述私有权限对应的公钥证书，并在所述签名集合中查找所述公钥证书，若找到，则判定第一应用程序获取所述私有权限。
所述私有权限可以由应用程序申明，也可以由系统申明；所述私有权 限申明信息则记录了系统以及已安装的各应用程序所申明的各个私有权限与其申明方的公钥证书的对应关系。
所述私有权限申明信息可以由安装程序在安装系统以及各应用程序的过程中通过以下过程生成：解析被安装的应用程序或者系统的配置文件，获取其申明的、用于访问私有接口的私有权限；从被安装的应用程序或者系统的发布者签名文件中提取公钥证书；建立被申明的私有权限与所述公钥证书的对应关系，并添加到所述私有权限申明信息中。
本步骤则可以针对步骤102-2提取的私有权限信息中的每个私有权限，执行下述操作：根据当前处理的私有权限，从预先生成的私有权限申明信息中提取对应的公钥证书，然后在第一应用程序的签名集合中查找所述公钥证书，若找到，则可以判定第一应用程序获取所述私有权限，即：第一应用程序可以访问对应于所述私有权限的私有接口。针对私有权限信息中的每个私有权限都进行上述处理，则完成了第一应用程序的私有权限获取过程。
在第一应用程序的安装过程中执行上述步骤102-1至步骤102-3后，第一应用程序拥有哪些私有权限就已经确定下来了。那么当第一应用程序在运行过程中访问步骤101所述的特定私有接口时，本步骤就可以根据上述安装过程的权限获取结果，判断第一应用程序是否已获取了对应于所述特定私有接口的私有权限，若已获取则可以判定第一应用程序由所述特定私有接口的提供侧授权，否则判定第一应用程序未被授权。
步骤103、允许第一应用程序访问所述特定私有接口。
执行到本步骤，说明第一应用程序已由所述特定私有接口的提供侧授权，因此允许第一应用程序访问所述特定私有接口，例如，第一应用程序可以调用该特定私有接口对应的函数，或者执行所述特定私有接口中包含的各项操作等。
至此，通过步骤101-103对本实施例提供的应用程序对接口的访问方法进行了详细说明。通过上述描述可以看出，采用本实施例提供的上述方法，为应用程序发布者以及系统发布者提供了对私有接口的权限控制能力， 能够呈现私有接口提供侧的授权意图，消除滥用权限导致的安全隐患；而且使得应用程序作者以及系统发布者敢于开放私有接口，从而能够促进应用程序之间、以及应用程序与系统之间的有效交互，有助于构建良好的服务生态环境。此外，采用本申请提供的上述方法，使系统发布者主动参与到应用程序的授权过程成为可能，为系统发布者的运维提供便利。
在上述的实施例中，提供了一种应用程序对接口的访问方法，与之相对应的，本申请还提供一种应用程序对接口的访问装置。请参看图3，其为本申请的一种应用程序对接口的访问装置的实施例示意图。由于装置实施例基本相似于方法实施例，所以描述得比较简单，相关之处参见方法实施例的部分说明即可。下述描述的装置实施例仅仅是示意性的。
本实施例的一种应用程序对接口的访问装置，包括：访问请求接收单元301，用于接收第一应用程序对特定私有接口的访问请求；授权判断单元302，用于判断第一应用程序是否由所述特定私有接口的提供侧授权；访问允许单元303，用于当所述授权判断单元的输出为是时，允许第一应用程序访问所述特定私有接口。
可选的，所述授权判断单元，具体用于根据第一应用程序的签名文件列表中是否包含所述私有接口的提供侧的签名文件，判断第一应用程序是否由所述私有接口的提供侧授权。
可选的，所述授权判断单元所采用的签名文件列表中的签名文件包括：第一应用程序发布者的发布者签名文件，或者，所述发布者签名文件以及不同于所述第一应用程序发布者的私有接口提供侧的授权签名文件。
可选的，所述授权判断单元所采用的签名文件列表中的授权签名文件是由以下单元生成的：
授权请求发送单元，用于第一客户端向私有接口提供侧发送授权请求；
授权签名文件生成单元，用于第二客户端根据接收到的授权请求，利用数字签名技术，采用私有接口提供侧的私钥对授权请求中携带的待签名文件执行签名操作，生成私有接口提供侧的授权签名文件并返回给第一客户端；
授权签名文件接收单元，用于第一客户端接收所述授权签名文件，并将其添加到第一应用程序的签名文件列表中。
可选的，所述授权请求单元所发送的授权请求中携带的待签名文件包括：第一应用程序签名文件列表中的、最近一次生成的签名文件。
可选的，所述装置还包括：权限获取单元，用于第一应用程序在安装过程中获取用于访问私有接口的私有权限；
所述权限获取单元包括：
签名集合生成子单元，用于从第一应用程序的签名文件列表中逐一提取公钥证书，并添加到签名集合中；
私有权限提取子单元，用于解析第一应用程序的配置文件，提取其申请的、用于访问系统或者其他应用程序的私有接口的私有权限信息；
私有权限获取执行子单元，用于针对所述私有权限信息中的每个私有权限，执行下述操作：从预先生成的私有权限申明信息中提取私有权限对应的公钥证书；在所述签名集合中查找所述公钥证书，若找到，则判定第一应用程序获取所述私有权限；
相应的，所述授权判断单元，具体用于判断第一应用程序是否已获取访问所述特定私有接口的私有权限，若是，则判定第一应用程序由所述特定私有接口的提供侧授权，否则未授权。
可选的，所述签名集合生成子单元，具体用于针对所述签名文件列表中的每个签名文件，通过数字签名验证技术对所述签名文件进行验证，并从通过验证的签名文件中提取公钥证书添加到所述签名集合中。
此外，本申请还提供一种应用程序的授权请求方法。请参考图4，其为本申请提供的一种应用程序的授权请求方法的实施例的流程图，本实施例与上述实施例步骤相同的部分不再赘述，下面重点描述不同之处。本申请提供的一种应用程序的授权请求方法包括：
步骤401、向私有接口提供侧发送授权请求，请求授予应用程序访问 所述私有接口的权限。
所述授权请求中可以携带所述应用程序的待签名文件，所述待签名文件可以为，所述应用程序签名文件列表中的、最近一次生成的签名文件。
步骤402、接收所述私有接口提供侧返回的授权信息。
所述授权信息可以包括：利用数字签名技术，采用所述私有接口提供侧的私钥对授权请求中携带的待签名文件执行签名操作后生成的授权签名文件。
步骤403、将所述授权信息添加到所述应用程序中。
本步骤可以将接收到的授权信息，例如，授权签名文件，添加到所述应用程序的签名文件列表中。
通过步骤401-403的描述可以看出，采用本实施例提供的应用程序的授权请求方法，对于需要访问某私有接口的应用程序，可以预先向所述私有接口的提供侧请求授权、并获取相应的授权信息，从而可以在应用程序的运行过程中判定其已由所述私有接口的提供侧授权、并进一步允许其访问所述私有接口。
在上述的实施例中，提供了一种应用程序的授权请求方法，与之相对应的，本申请还提供一种应用程序的授权请求装置。请参看图5，其为本申请的一种应用程序的授权请求装置的实施例示意图。由于装置实施例基本相似于方法实施例，所以描述得比较简单，相关之处参见方法实施例的部分说明即可。下述描述的装置实施例仅仅是示意性的。
本实施例的一种应用程序的授权请求装置，包括：授权请求发送单元501，用于向私有接口提供侧发送授权请求，请求授予应用程序访问所述私有接口的权限；授权信息接收单元502，用于接收所述私有接口提供侧返回的授权信息；授权信息添加单元503，用于将所述授权信息添加到所述应用程序中。
可选的，所述授权请求发送单元所发送的授权请求中携带所述应用程序的待签名文件；
所述授权信息接收单元接收到的授权信息包括：利用数字签名技术，采用所述私有接口提供侧的私钥对所述待签名文件执行签名操作后生成的授权签名文件；
所述授权信息添加单元，具体用于将授权信息接收单元接收到的授权签名文件添加到所述应用程序的签名文件列表中。
此外，本申请还提供一种应用程序的授权方法。请参考图6，其为本申请提供的一种应用程序的授权方法的实施例的流程图，本实施例与上述实施例步骤相同的部分不再赘述，下面重点描述不同之处。本申请提供的一种应用程序的授权方法包括：
步骤601、确定待授权应用程序。
本步骤可以根据接收到的请求授予私有接口访问权限的授权请求，确定所述待授权应用程序，例如，所述授权请求中可以携带待授权应用程序的名称或者标识等；所述授权请求中还可以携带待签名文件。
为了便于系统发布者运营、使系统发布者主动参与到应用程序的授权过程，本步骤也可以从系统运营的待发布应用程序中确定所述待授权应用程序。在这种情况下，待签名文件可以是，已确定的待授权应用程序的相关文件。
在具体实施中，可以将所述待授权应用程序的签名文件列表中的、最近一次生成的签名文件，作为所述待签名文件。
步骤602、生成表征私有接口提供侧允许所述待授权应用程序访问私有接口的授权信息。
本步骤可以利用数字签名技术，采用所述私有接口提供侧的私钥对所述待授权应用程序的待签名文件执行签名操作，生成授权签名文件，所述授权签名文件即为所述授权信息。
对于在步骤601中接收到授权请求的情况，在执行步骤602之后还可以将生成的授权信息，例如授权签名文件，返回给所述授权请求的发送方； 对于在步骤601中由系统发布者确定待授权应用程序的情况，在执行步骤602之后，则可以将生成的授权信息，例如授权签名文件，添加到所述应用程序的签名文件列表中。
通过步骤601-603的描述可以看出，采用本实施例提供的应用程序的授权方法，私有接口提供侧可以预先为需要访问其私有接口的应用程序生成授权信息，从而可以在所述应用程序的运行过程中判定其已由所述私有接口的提供侧授权，并允许其访问所述私有接口。
在上述的实施例中，提供了一种应用程序的授权方法，与之相对应的，本申请还提供一种应用程序的授权装置。请参看图7，其为本申请的一种应用程序的授权装置的实施例示意图。由于装置实施例基本相似于方法实施例，所以描述得比较简单，相关之处参见方法实施例的部分说明即可。下述描述的装置实施例仅仅是示意性的。
本实施例的一种应用程序的授权装置，包括：待授权应用程序确定单元701，用于确定待授权应用程序；授权信息生成单元702，用于生成表征私有接口提供侧允许所述待授权应用程序访问私有接口的授权信息。
可选的，所述授权信息生成单元，具体用于利用数字签名技术，采用所述私有接口提供侧的私钥对所述待授权应用程序的待签名文件执行签名操作，生成授权签名文件，所述授权签名文件即为所述授权信息。
可选的，所述待授权应用程序确定单元，具体用于根据接收到的请求授予私有接口访问权限的授权请求，确定所述待授权应用程序；
所述授权信息生成单元所采用的待签名文件包括：所述授权请求中携带的文件；
所述装置还包括：授权签名文件返回单元，用于将所述授权信息生成单元生成的授权签名文件返回给所述授权请求的发送方。
可选的，所述待授权应用程序确定单元，具体用于从系统运营的待发布应用程序中确定所述待授权应用程序；
所述授权信息生成单元所采用的待签名文件包括：所述待授权应用程序的相关文件；
所述装置还包括：授权签名文件添加单元，用于将所述授权信息生成单元生成的授权签名文件添加到所述应用程序的签名文件列表中。
此外，本申请还提供一种应用程序的权限获取方法。请参考图8，其为本申请提供的一种应用程序的权限获取方法的实施例的流程图，本实施例与上述实施例步骤相同的部分不再赘述，下面重点描述不同之处。本申请提供的一种应用程序的权限获取方法包括：
步骤801、从应用程序的授权信息中逐一提取表征授权者身份的信息，并添加到授权者身份集合中。
所述授权信息，是表征私有接口提供侧允许所述应用程序访问其私有接口的信息，授权信息中至少包括表征授权者身份的信息(例如：唯一标识授权者身份的ID号码)，还可以包括所述应用程的标识等信息。本步骤从所述应用程序的授权信息中逐一提取表征授权者身份的信息，并添加到授权者身份集合中。
优选地，所述授权信息为签名文件列表，所述表征授权者身份的信息为公钥证书，所述授权者身份集合为签名集合。所述签名文件列表可以包括：所述应用程序发布者的发布者签名文件，或者，所述发布者签名文件以及不同于所述应用程序发布者的私有接口提供侧的授权签名文件。
步骤802、解析所述应用程序的配置文件，提取其申请的用于访问私有接口的私有权限信息。
步骤803、针对所述私有权限信息中的每个私有权限，执行下述操作：从预先生成的私有权限申明信息中提取所述私有权限对应的身份信息，并在所述授权者身份集合中查找所述身份信息，若找到，则判定所述应用程序获取所述私有权限。
其中，所述私有权限申明信息可以在安装系统以及各应用程序的过程中生成，其中记录了系统以及已安装的各应用程序所申明的各个私有权限与其申明方的身份信息的对应关系。
通过步骤801-803可以看出，采用本实施例提供的应用程序的权限获 取方法，可以根据应用程序的授权信息以及应用程序申请的私有权限，确定所述应用程序所具有的私有权限，从而便于对所述应用程是否由私有接口提供侧授权做出判断。特别是，在安装应用程序的过程中实施上述步骤，能够简化应用程序运行过程中对授权状况的判断过程，提高执行效率。
在上述的实施例中，提供了一种应用程序的权限获取方法，与之相对应的，本申请还提供一种应用程序的权限获取装置。请参看图9，其为本申请的一种应用程序的权限获取装置的实施例示意图。由于装置实施例基本相似于方法实施例，所以描述得比较简单，相关之处参见方法实施例的部分说明即可。下述描述的装置实施例仅仅是示意性的。
本实施例的一种应用程序的权限获取装置，包括：身份集合生成单元901，用于从应用程序的授权信息集合中逐一提取表征授权者身份的信息，并添加到授权者身份集合中；私有权限提取单元902，用于解析所述应用程序的配置文件，提取其申请的用于访问私有接口的私有权限信息；私有权限获取单元903，用于判定所述应用程序是否获取所述私有权限信息中的私有权限；
所述私有权限获取单元，包括：
循环控制子单元，用于针对私有权限信息中的每个私有权限，依次触发身份信息提取子单元、以及查找判定子单元工作；
身份信息提取子单元，用于从预先生成的私有权限申明信息中提取对应于当前处理的私有权限的身份信息；
查找判定子单元，用于在所述授权者身份集合中查找所述身份信息提取子单元所提取的身份信息，若找到，则判定所述应用程序获取所述私有权限。
本申请虽然以较佳实施例公开如上，但其并不是用来限定本申请，任何本领域技术人员在不脱离本申请的精神和范围内，都可以做出可能的变动和修改，因此本申请的保护范围应当以本申请权利要求所界定的范围为准。
在一个典型的配置中，计算设备包括一个或多个处理器(CPU)、输入/输出接口、网络接口和内存。
内存可能包括计算机可读介质中的非永久性存储器，随机存取存储器(RAM)和/或非易失性内存等形式，如只读存储器(ROM)或闪存(flash RAM)。内存是计算机可读介质的示例。
1、计算机可读介质包括永久性和非永久性、可移动和非可移动媒体可以由任何方法或技术来实现信息存储。信息可以是计算机可读指令、数据结构、程序的模块或其他数据。计算机的存储介质的例子包括，但不限于相变内存(PRAM)、静态随机存取存储器(SRAM)、动态随机存取存储器(DRAM)、其他类型的随机存取存储器(RAM)、只读存储器(ROM)、电可擦除可编程只读存储器(EEPROM)、快闪记忆体或其他内存技术、只读光盘只读存储器(CD-ROM)、数字多功能光盘(DVD)或其他光学存储、磁盒式磁带，磁带磁磁盘存储或其他磁性存储设备或任何其他非传输介质，可用于存储可以被计算设备访问的信息。按照本文中的界定，计算机可读介质不包括非暂存电脑可读媒体(transitory media)，如调制的数据信号和载波。
2、本领域技术人员应明白，本申请的实施例可提供为方法、系统或计算机程序产品。因此，本申请可采用完全硬件实施例、完全软件实施例或结合软件和硬件方面的实施例的形式。而且，本申请可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、CD-ROM、光学存储器等)上实施的计算机程序产品的形式。

Claims (30)

  1. 一种应用程序对接口的访问方法，其特征在于，包括：
    接收第一应用程序对特定私有接口的访问请求；
    判断第一应用程序是否由所述特定私有接口的提供侧授权；
    若是，允许第一应用程序访问所述特定私有接口。
  2. 根据权利要求1所述的应用程序对接口的访问方法，其特征在于，所述特定私有接口的提供侧包括：提供所述特定私有接口的系统发布者、或者提供所述特定私有接口的第二应用程序发布者。
  3. 根据权利要求1所述的应用程序对接口的访问方法，其特征在于，所述判断第一应用程序是否由所述特定私有接口的提供侧授权，包括：
    根据第一应用程序的签名文件列表中是否包含所述特定私有接口的提供侧的签名文件，判断第一应用程序是否由所述特定私有接口的提供侧授权。
  4. 根据权利要求3所述的应用程序对接口的访问方法，其特征在于，所述签名文件列表中的签名文件的内容包括：摘要信息，用签名者的私钥加密所述摘要信息生成的数字签名，以及签名者的公钥证书。
  5. 根据权利要求3所述的应用程序对接口的访问方法，其特征在于，所述签名文件列表包括：第一应用程序发布者的发布者签名文件，或者，所述发布者签名文件以及不同于所述第一应用程序发布者的私有接口提供侧的签名文件。
  6. 根据权利要求5所述的应用程序对接口的访问方法，其特征在于，当所述签名文件列表中包含私有接口提供侧的授权签名文件时，生成所述授权签名文件的方式包括：
    第一客户端向私有接口提供侧发送授权请求；
    第二客户端根据接收到的授权请求，利用数字签名技术，采用私有接口提供侧的私钥对授权请求中携带的待签名文件执行签名操作，生成私有 接口提供侧的授权签名文件并返回给第一客户端；
    第一客户端接收所述授权签名文件，并将其添加到第一应用程序的签名文件列表中。
  7. 根据权利要求6所述的应用程序对接口的访问方法，其特征在于，所述待签名文件包括：第一应用程序签名文件列表中的、最近一次生成的签名文件。
  8. 根据权利要求4所述的应用程序对接口的访问方法，其特征在于，所述第一应用程序的安装过程包括下述权限获取步骤：
    从第一应用程序的签名文件列表中逐一提取公钥证书，并添加到签名集合中；
    解析第一应用程序的配置文件，提取其申请的、用于访问系统或者其他应用程序的私有接口的私有权限信息；
    针对所述私有权限信息中的每个私有权限，执行下述操作：
    从预先生成的私有权限申明信息中提取所述私有权限对应的公钥证书；
    在所述签名集合中查找所述公钥证书，若找到，则判定第一应用程序获取所述私有权限；
    相应的，所述根据第一应用程序的签名文件列表中是否包含所述特定私有接口的提供侧的签名文件，判断第一应用程序是否由所述特定私有接口的提供侧授权，包括：
    判断第一应用程序是否已获取访问所述特定私有接口的私有权限，若是，则判定第一应用程序由所述特定私有接口的提供侧授权，否则未授权。
  9. 根据权利要求8所述的应用程序对接口的访问方法，其特征在于，所述从第一应用程序的签名文件列表中逐一提取公钥证书，并添加到签名集合中，包括：
    针对所述签名文件列表中的每个签名文件，执行以下操作：
    通过数字签名验证技术，对所述签名文件进行验证；
    从通过验证的签名文件中提取公钥证书、并添加到所述签名集合中。
  10. 一种应用程序对接口的访问装置，其特征在于，包括：
    访问请求接收单元，用于接收第一应用程序对特定私有接口的访问请求；
    授权判断单元，用于判断第一应用程序是否由所述特定私有接口的提供侧授权；
    访问允许单元，用于当所述授权判断单元的输出为是时，允许第一应用程序访问所述特定私有接口。
  11. 根据权利要求10所述的应用程序对接口的访问装置，其特征在于，所述授权判断单元，具体用于根据第一应用程序的签名文件列表中是否包含所述私有接口的提供侧的签名文件，判断第一应用程序是否由所述私有接口的提供侧授权。
  12. 根据权利要求11所述的应用程序对接口的访问装置，其特征在于，所述授权判断单元所采用的签名文件列表中的签名文件包括：第一应用程序发布者的发布者签名文件，或者，所述发布者签名文件以及不同于所述第一应用程序发布者的私有接口提供侧的授权签名文件。
  13. 根据权利要求12所述的应用程序对接口的访问装置，其特征在于，所述授权判断单元所采用的签名文件列表中的授权签名文件是由以下单元生成的：
    授权请求发送单元，用于第一客户端向私有接口提供侧发送授权请求；
    授权签名文件生成单元，用于第二客户端根据接收到的授权请求，利用数字签名技术，采用私有接口提供侧的私钥对授权请求中携带的待签名文件执行签名操作，生成私有接口提供侧的授权签名文件并返回给第一客户端；
    授权签名文件接收单元，用于第一客户端接收所述授权签名文件，并将其添加到第一应用程序的签名文件列表中。
  14. 根据权利要求13所述的应用程序对接口的访问装置，其特征在于，所述授权请求单元所发送的授权请求中携带的待签名文件包括：第一应用 程序签名文件列表中的、最近一次生成的签名文件。
  15. 根据权利要求11所述的应用程序对接口的访问装置，其特征在于，所述装置还包括：权限获取单元，用于第一应用程序在安装过程中获取用于访问私有接口的私有权限；
    所述权限获取单元包括：
    签名集合生成子单元，用于从第一应用程序的签名文件列表中逐一提取公钥证书，并添加到签名集合中；
    私有权限提取子单元，用于解析第一应用程序的配置文件，提取其申请的、用于访问系统或者其他应用程序的私有接口的私有权限信息；
    私有权限获取执行子单元，用于针对所述私有权限信息中的每个私有权限，执行下述操作：从预先生成的私有权限申明信息中提取私有权限对应的公钥证书；在所述签名集合中查找所述公钥证书，若找到，则判定第一应用程序获取所述私有权限；
    相应的，所述授权判断单元，具体用于判断第一应用程序是否已获取访问所述特定私有接口的私有权限，若是，则判定第一应用程序由所述特定私有接口的提供侧授权，否则未授权。
  16. 根据权利要求15所述的应用程序对接口的访问装置，其特征在于，所述签名集合生成子单元，具体用于针对所述签名文件列表中的每个签名文件，通过数字签名验证技术对所述签名文件进行验证，并从通过验证的签名文件中提取公钥证书添加到所述签名集合中。
  17. 一种应用程序的授权请求方法，其特征在于，包括：
    向私有接口提供侧发送授权请求，请求授予应用程序访问所述私有接口的权限；
    接收所述私有接口提供侧返回的授权信息；
    并将所述授权信息添加到所述应用程序中。
  18. 根据权利要求17所述的应用程序的授权请求方法，其特征在于，所述授权请求中携带所述应用程序的待签名文件；
    所述授权信息包括：利用数字签名技术，采用所述私有接口提供侧的私钥对所述待签名文件执行签名操作后生成的授权签名文件；
    所述将所述授权信息添加到所述应用程序中，包括：将接收到的授权签名文件添加到所述应用程序的签名文件列表中。
  19. 根据权利要求18所述的应用程序的授权请求方法，其特征在于，所述授权请求中携带的待签名文件包括：所述应用程序签名文件列表中的、最近一次生成的签名文件。
  20. 一种应用程序的授权请求装置，其特征在于，包括：
    授权请求发送单元，用于向私有接口提供侧发送授权请求，请求授予应用程序访问所述私有接口的权限；
    授权信息接收单元，用于接收所述私有接口提供侧返回的授权信息；
    授权信息添加单元，用于将所述授权信息添加到所述应用程序中。
  21. 一种应用程序的授权方法，其特征在于，包括：
    确定待授权应用程序；
    生成表征私有接口提供侧允许所述待授权应用程序访问私有接口的授权信息。
  22. 根据权利要求21所述的应用程序的授权方法，其特征在于，所述生成表征私有接口提供侧允许所述待授权应用程序访问私有接口的授权信息，包括：
    利用数字签名技术，采用所述私有接口提供侧的私钥对所述待授权应用程序的待签名文件执行签名操作，生成授权签名文件，所述授权签名文件即为所述授权信息。
  23. 根据权利要求22所述的应用程序的授权方法，其特征在于，所述确定待授权应用程序，包括：根据接收到的请求授予私有接口访问权限的授权请求，确定所述待授权应用程序；
    所述待签名文件包括：所述授权请求中携带的文件；
    所述方法还包括：
    将生成的授权签名文件返回给所述授权请求的发送方。
  24. 根据权利要求22所述的应用程序的授权方法，其特征在于，所述确定待授权应用程序，包括：从系统运营的待发布应用程序中确定所述待授权应用程序；
    所述待签名文件包括：所述待授权应用程序的相关文件；
    所述方法还包括：
    将生成的授权签名文件添加到所述应用程序的签名文件列表中。
  25. 根据权利要求23或24所述的应用程序的授权方法，其特征在于，所述待签名文件为：所述待授权应用程序的签名文件列表中的、最近一次生成的签名文件。
  26. 一种应用程序的授权装置，其特征在于，包括：
    待授权应用程序确定单元，用于确定待授权应用程序；
    授权信息生成单元，用于生成表征私有接口提供侧允许所述待授权应用程序访问私有接口的授权信息。
  27. 一种应用程序的权限获取方法，其特征在于，包括：
    从应用程序的授权信息中逐一提取表征授权者身份的信息，并添加到授权者身份集合中；
    解析所述应用程序的配置文件，提取其申请的用于访问私有接口的私有权限信息；
    针对所述私有权限信息中的每个私有权限，执行下述操作：
    从预先生成的私有权限申明信息中提取所述私有权限对应的身份信息；
    在所述授权者身份集合中查找所述身份信息，若找到，则判定所述应用程序获取所述私有权限。
  28. 根据权利要求27所述的应用程序的权限获取方法，其特征在于，所述授权信息包括：签名文件列表，所述表征授权者身份的信息包括：公钥证书，所述授权者身份集合包括：签名集合。
  29. 根据权利要求28所述的应用程序的权限获取方法，其特征在于，所述签名文件列表包括：所述应用程序发布者的发布者签名文件，或者，所述发布者签名文件以及不同于所述应用程序发布者的私有接口提供侧的授权签名文件。
  30. 一种应用程序的权限获取装置，其特征在于，包括：
    身份集合生成单元，用于从应用程序的授权信息集合中逐一提取表征授权者身份的信息，并添加到授权者身份集合中；
    私有权限提取单元，用于解析所述应用程序的配置文件，提取其申请的用于访问私有接口的私有权限信息；
    私有权限获取单元，用于判定所述应用程序是否获取所述私有权限信息中的私有权限；
    所述私有权限获取单元，包括：
    循环控制子单元，用于针对私有权限信息中的每个私有权限，依次触发身份信息提取子单元、以及查找判定子单元工作；
    身份信息提取子单元，用于从预先生成的私有权限申明信息中提取对应于当前处理的私有权限的身份信息；
    查找判定子单元，用于在所述授权者身份集合中查找所述身份信息提取子单元所提取的身份信息，若找到，则判定所述应用程序获取所述私有权限。
PCT/CN2017/070981 2016-01-21 2017-01-12 应用程序对接口的访问方法、授权请求方法及装置 WO2017124960A1 (zh)

Priority Applications (1)

Application Number Priority Date Filing Date Title
US16/037,809 US10878066B2 (en) 2016-01-21 2018-07-17 System and method for controlled access to application programming interfaces

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
CN201610039246.9 2016-01-21
CN201610039246.9A CN106991298B (zh) 2016-01-21 2016-01-21 应用程序对接口的访问方法、授权请求方法及装置

Related Child Applications (1)

Application Number Title Priority Date Filing Date
US16/037,809 Continuation-In-Part US10878066B2 (en) 2016-01-21 2018-07-17 System and method for controlled access to application programming interfaces

Publications (1)

Publication Number Publication Date
WO2017124960A1 true WO2017124960A1 (zh) 2017-07-27

Family

ID=59361330

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2017/070981 WO2017124960A1 (zh) 2016-01-21 2017-01-12 应用程序对接口的访问方法、授权请求方法及装置

Country Status (3)

Country Link
US (1) US10878066B2 (zh)
CN (1) CN106991298B (zh)
WO (1) WO2017124960A1 (zh)

Families Citing this family (14)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US10910089B2 (en) 2015-03-20 2021-02-02 Universal Patient Key, Inc. Methods and systems providing centralized encryption key management for sharing data across diverse entities
US11537748B2 (en) 2018-01-26 2022-12-27 Datavant, Inc. Self-contained system for de-identifying unstructured data in healthcare records
US11120144B1 (en) * 2018-04-12 2021-09-14 Datavant, Inc. Methods and systems providing central management of distributed de-identification and tokenization software for sharing data
US11494479B2 (en) * 2018-08-31 2022-11-08 Harman International Industries, Incorporated Authenticated component permissions framework
CN109656809A (zh) * 2018-11-07 2019-04-19 北京奇艺世纪科技有限公司 一种应用程序接口检测方法、装置及计算机可读存储介质
US11539533B1 (en) 2019-07-11 2022-12-27 Workday, Inc. Access control using a circle of trust
CN111026435A (zh) * 2019-11-29 2020-04-17 北京奇艺世纪科技有限公司 检测应用程序私有接口的方法、装置、设备及存储介质
CN113805978A (zh) * 2020-06-12 2021-12-17 北京小米移动软件有限公司 权限显示方法、装置及存储介质
CN112182620B (zh) * 2020-09-30 2024-04-05 Oppo广东移动通信有限公司 一种授权方法、终端、web服务器及计算机存储介质
US11755779B1 (en) 2020-09-30 2023-09-12 Datavant, Inc. Linking of tokenized trial data to other tokenized data
CN112800436B (zh) * 2021-04-07 2021-06-29 支付宝(杭州)信息技术有限公司 数据授权方法、装置及电子设备
US20230015697A1 (en) * 2021-07-13 2023-01-19 Citrix Systems, Inc. Application programming interface (api) authorization
CN114826946B (zh) * 2022-06-29 2022-09-13 深圳红途科技有限公司 未授权访问接口的检测方法、装置、设备及存储介质
US11687675B1 (en) * 2022-09-08 2023-06-27 Pezo Tech Llc Method and system for improving coupling and cohesion of at least one educational program

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101866404A (zh) * 2010-06-13 2010-10-20 用友软件股份有限公司 软件系统模块独立授权控制方法和装置
CN102663320A (zh) * 2012-04-12 2012-09-12 福建联迪商用设备有限公司 终端识别开发者及划分不同权限开发者的方法
CN102915416A (zh) * 2012-09-18 2013-02-06 北京深思洛克软件技术股份有限公司 一种实现应用程序间虚拟物品安全共享的系统
CN103001936A (zh) * 2011-09-16 2013-03-27 北京新媒传信科技有限公司 一种第三方应用接口授权方法和系统

Family Cites Families (19)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6279043B1 (en) 1998-05-01 2001-08-21 Apple Computer, Inc. Method and system for script access to API functionality
CN101005699A (zh) * 2006-01-22 2007-07-25 华为技术有限公司 管理终端开放平台权限信息的方法和系统
US20080092057A1 (en) * 2006-10-05 2008-04-17 Instrinsyc Software International, Inc Framework for creation of user interfaces for electronic devices
US8606656B1 (en) 2008-03-28 2013-12-10 Amazon Technologies, Inc. Facilitating access to restricted functionality
CN101686129A (zh) * 2008-09-24 2010-03-31 北京创原天地科技有限公司 一种新型的强安全服务和用户资源经营方法
US10769412B2 (en) * 2009-05-18 2020-09-08 Mark Thompson Mug shot acquisition system
CN101571900B (zh) * 2009-06-01 2011-01-19 薛明 一种软件版权保护方法、设备和系统
CN101908109A (zh) * 2010-07-02 2010-12-08 中国船舶重工集团公司第七○九研究所 一种可控的构件发布与使用保护方法
US20120324225A1 (en) * 2011-06-20 2012-12-20 Jason Chambers Certificate-based mutual authentication for data security
CN103312675B (zh) * 2012-03-13 2016-05-18 中国科学院软件研究所 一种面向属性保护的数字身份服务方法及其系统
CN103701761B (zh) * 2012-09-28 2017-07-18 中国电信股份有限公司 开放接口调用的认证方法与系统
CN102916965A (zh) * 2012-10-29 2013-02-06 广州杰赛科技股份有限公司 一种云服务接口的安全认证机制及其认证系统
US10063380B2 (en) * 2013-01-22 2018-08-28 Amazon Technologies, Inc. Secure interface for invoking privileged operations
CN103095731A (zh) * 2013-02-22 2013-05-08 浪潮电子信息产业股份有限公司 一种基于签名机制的rest安全系统
US9223950B2 (en) * 2013-03-05 2015-12-29 Intel Corporation Security challenge assisted password proxy
ES2626552T3 (es) * 2013-08-23 2017-07-25 Huawei Device Co., Ltd. Método y aparato de gestión de permisos y terminal
CN104580195B (zh) * 2014-12-31 2018-07-17 上海格尔软件股份有限公司 一种基于软件数字证书安全的权限发布获取控制方法
CN106951795B (zh) * 2016-01-07 2020-07-21 阿里巴巴集团控股有限公司 一种应用程序数据访问隔离方法及装置
US10789058B2 (en) * 2018-05-30 2020-09-29 Microsoft Technology Licensing, Llc Extensibility of unified platform

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101866404A (zh) * 2010-06-13 2010-10-20 用友软件股份有限公司 软件系统模块独立授权控制方法和装置
CN103001936A (zh) * 2011-09-16 2013-03-27 北京新媒传信科技有限公司 一种第三方应用接口授权方法和系统
CN102663320A (zh) * 2012-04-12 2012-09-12 福建联迪商用设备有限公司 终端识别开发者及划分不同权限开发者的方法
CN102915416A (zh) * 2012-09-18 2013-02-06 北京深思洛克软件技术股份有限公司 一种实现应用程序间虚拟物品安全共享的系统

Also Published As

Publication number Publication date
CN106991298A (zh) 2017-07-28
US20190138698A1 (en) 2019-05-09
US10878066B2 (en) 2020-12-29
CN106991298B (zh) 2021-02-02

Similar Documents

Publication Publication Date Title
WO2017124960A1 (zh) 应用程序对接口的访问方法、授权请求方法及装置
CN111741036B (zh) 一种可信数据传输方法、装置及设备
US11315110B2 (en) Private resource discovery and subgroup formation on a blockchain
CN110414268B (zh) 访问控制方法、装置、设备及存储介质
JP5852265B2 (ja) 計算装置、コンピュータプログラム及びアクセス許否判定方法
WO2018072471A1 (zh) 版权维权检测的方法、装置和系统
CN111932426B (zh) 一种基于可信硬件的身份管理方法、装置及设备
CN109274652B (zh) 身份信息验证系统、方法及装置及计算机存储介质
JP5281074B2 (ja) 情報セキュリティ装置および情報セキュリティシステム
US20190333031A1 (en) System, method, and computer program product for validating blockchain or distributed ledger transactions in a service requiring payment
US8131997B2 (en) Method of mutually authenticating between software mobility device and local host and a method of forming input/output (I/O) channel
US10554663B2 (en) Self-destructing smart data container
JP2016520230A (ja) 安全な承認システム及び方法
WO2013107362A1 (zh) 一种保护数据的方法和系统
KR20140114229A (ko) 어플리케이션 간의 상호 인증 방법 및 장치
CN110555293A (zh) 用于保护数据的方法、装置、电子设备和计算机可读介质
CN109831435B (zh) 一种数据库操作方法、系统及代理服务器和存储介质
US20120284507A1 (en) Protected authorization
US20150205973A1 (en) Method and apparatus for providing data sharing
US10333717B2 (en) Timestamped license data structure
US20180218364A1 (en) Managing distributed content using layered permissions
KR102011363B1 (ko) 블록체인 인증을 이용한 소프트웨어 인증 방법
Abraham et al. SSI Strong Authentication using a Mobile-phone based Identity Wallet Reaching a High Level of Assurance.
Deng et al. Towards a cross‐context identity management framework in e‐health
CN112865981B (zh) 一种令牌获取、验证方法及装置

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 17740991

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 17740991

Country of ref document: EP

Kind code of ref document: A1