WO2019210579A1 - 调用api接口的验证方法、装置、计算机设备和存储介质 - Google Patents

调用api接口的验证方法、装置、计算机设备和存储介质 Download PDF

Info

Publication number
WO2019210579A1
WO2019210579A1 PCT/CN2018/095672 CN2018095672W WO2019210579A1 WO 2019210579 A1 WO2019210579 A1 WO 2019210579A1 CN 2018095672 W CN2018095672 W CN 2018095672W WO 2019210579 A1 WO2019210579 A1 WO 2019210579A1
Authority
WO
WIPO (PCT)
Prior art keywords
party application
application end
user
verification
api interface
Prior art date
Application number
PCT/CN2018/095672
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 WO2019210579A1 publication Critical patent/WO2019210579A1/zh

Links

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/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
    • 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 the field of Internet technologies, and in particular, to a verification method, apparatus, computer device, and storage medium for calling an API interface.
  • the requesting party logs in to the third-party application (any application) and often wants to access other applications on the third-party application.
  • the API interface of other applications can be invoked (Application Programming). Interface, application programming interface) to access.
  • the API interface is mainly used when the external application (third-party application) is called, that is, when the user wants to access other applications on the external application that has logged in, the API interface of other applications is implemented.
  • the way in which the API interface is invoked in the industry is mostly implemented by means of user password authentication login and simple token (temporary token).
  • the password authentication login mode of the user password requires the user to enter a password or save the password, which is cumbersome and unsafe.
  • the use of a simple token method can achieve user password-free login, but there is a risk that the token will be crawled or leaked.
  • the main purpose of the present application is to provide a verification method, device, computer device and storage medium for calling an API interface, which overcomes the cumbersome operation of calling the API interface and the insecure call.
  • the present application provides a verification method for calling an API interface, including the following steps:
  • the server receives a call request from the third-party application end to the API interface, where the call request carries the feature information of the third-party application end, where the feature information is a preset ID and password of the third-party application end with the call permission;
  • the application also provides a verification device that calls an API interface, including:
  • the first receiving unit is configured to receive a call request of the third-party application end to the API interface, where the call request carries the feature information of the third-party application end, where the feature information is a preset ID of the third-party application end with the call permission And password;
  • a sending unit configured to send a first temporary token to the third-party application end according to the calling request, where the first temporary token is bound to the feature information of the third-party application end The first temporary token of the relationship;
  • a second receiving unit configured to receive a data request sent by the user by using the third-party application end, where the data request carries a second temporary token and user information of the third-party application end user;
  • a verification unit configured to perform rights verification on the user information when the first temporary token is the same as the second temporary token
  • a processing unit configured to process, according to the verification result, a call request of the third-party application end to the API interface.
  • the application further provides a computer device comprising a memory and a processor, the memory storing computer readable instructions, the processor executing the computer readable instructions to implement the steps of any of the methods described above.
  • the present application also provides a computer non-transitory readable storage medium having stored thereon computer readable instructions that, when executed by a processor, implement the steps of any of the methods described above.
  • the method, the device, the computer device, and the storage medium for calling the API interface provided by the present application when receiving the request for invoking the API interface by the third-party application end, issue a binding relationship with the feature information of the third-party application end.
  • the first temporary token is sent to the third-party application end, and the first temporary token is used as a unique identifier of the third-party application end, so as to avoid the risk of insecure user data when stolen; no user is required to input the password, and at the same time It is necessary to verify various information in the data request, enhance the security of the data accessed by the user, simplify the user operation, and overcome the cumbersome operation of calling the API interface and the insecure call.
  • FIG. 1 is a schematic diagram of steps of a verification method for calling an API interface in an embodiment of the present application
  • FIG. 2 is a schematic diagram of steps of a verification method for calling an API interface in another embodiment of the present application
  • FIG. 3 is a structural block diagram of a verification apparatus for calling an API interface in an embodiment of the present application
  • FIG. 4 is a block diagram showing the structure of a processing unit in an embodiment of the present application.
  • FIG. 5 is a structural block diagram of a verification unit in an embodiment of the present application.
  • FIG. 6 is a structural block diagram of a verification unit in another embodiment of the present application.
  • FIG. 7 is a schematic block diagram showing the structure of a computer device according to an embodiment of the present application.
  • an embodiment of the present application provides a verification method for calling an API interface, including the following steps:
  • Step S1 The server receives a call request from the third-party application end to the API interface, where the call request carries the feature information of the third-party application end; the feature information includes a preset third-party application end ID with the call permission and its corresponding
  • the password can be used to identify whether the third-party application has the calling right only through the ID. Combining the password helps to improve security and prevent the ID from being spoofed when it is stolen.
  • the server in this embodiment is pre-configured with a list of IDs of third-party applications having calling rights and corresponding passwords.
  • each third-party application has its own feature information, such as an ID, a password, a key, etc., which is used to indicate the uniqueness of each third-party application.
  • the user the requester of the data access
  • the third-party application end may be configured with the entry information (for example, an icon, etc.) of the data application end, and the user clicking the entry information automatically triggers the third-party application end to invoke the call request of the API interface of the data application end, and the call request is further Includes IDs for third-party applications.
  • the server is a management server of the data application end, and can receive the call request of the third-party application end to the API interface.
  • the data application side is any application end.
  • the data application side in this embodiment is based on the Django framework, and Django is an open source web application framework written by Python.
  • the data application introduces the oauth2 standard, which allows users to let third-party applications access the user's resources on the data application (such as photos, videos, contact lists, etc.) without having to provide the username and password.
  • the data application end is designed to access the resources under the system authority without entering the user password to facilitate user access, improve user experience and access efficiency.
  • Step S2 according to the call request, deliver a first temporary token to the third-party application end, where the first temporary token is a temporary binding relationship with the feature information of the third-party application end. Token.
  • the server after receiving the call request from the third-party application end to the API interface, the server obtains the ID and password of the third-party application end, and verifies that it is a preset third-party application end with the calling right, according to the The ID generates a first temporary token (token), and establishes a binding relationship between the first temporary token and the ID of the third-party application end, and the validity of the first temporary token has a certain time limit, such as one minute and half an hour. Wait.
  • a first temporary token token
  • the key information (having uniqueness) may also be obtained from the above-mentioned feature information, and a key is generated according to the key of the third-party application end and the ID corresponding to the ID.
  • a temporary token with a binding relationship It is possible to prevent other third-party applications from stealing the first temporary token described above, and spoofing by modifying its ID to steal data.
  • Step S3 Receive a data request sent by the user through the third-party application end, where the data request carries a second temporary token and user information of the third-party application end user.
  • the third temporary application when the third temporary application receives the first temporary token sent by the server, the first temporary token is used as the parameter value as the unique identifier of the third-party application, and the user passes the third-party application.
  • the data request is sent by the data request, and the data request includes the data information that the user wants to access (the operation that the user needs to perform or the data that the user wants to obtain), the user information of the user, the temporary token, the characteristic information of the third-party application end, and the like.
  • the third-party application When a user logs in to a third-party application, the third-party application records user information (user name, etc.). When the user invokes the API interface through the third-party application, the third-party application sends the user information to the server. According to the user information, it is possible to identify which third-party application the user invokes the API interface, and according to the ID of the third-party application and the user type, it can be determined whether the user is a user within the authority. If the second temporary token is the same as the first temporary token, it can be determined whether the third-party application is the application end of the API interface, and is prevented from being impersonated.
  • Step S4 When the first temporary token is the same as the second temporary token, perform rights verification on the user information.
  • the permission verification in this step is to realize the content of the user permission range directly in the data application end without requiring the user to input the user password again, that is, to realize the secret-free login.
  • the server in order to enhance security, it is necessary to perform authority verification on each of the above data requests. For example, it is first verified whether the third-party application is an application that initiates an API interface request, and then checks whether the user type and the data application match in the preset permission system, and checks whether the user has the corresponding operation permission. . That is, it is determined whether the data application end allows the third party application end of the requesting party to invoke the data application end, and judges whether the user has the right to access the data application end according to the user name. In this embodiment, each item in the data request is verified, and multiple verifications are performed to enhance security and prevent user data from being stolen.
  • Step S5 processing, according to the verification result, a call request of the third-party application end to the API interface.
  • the server after the server verifies the authority of the user information, the server performs corresponding processing according to the verification result.
  • the server automatically verifies the user's access rights, and simplifies the user's operation; and the above-mentioned authentication mechanism when calling the API interface ensures the security of the user data.
  • step S5 of processing the call request of the third-party application end to the API interface according to the verification result includes:
  • the feedback includes the verification result with the abnormal cause to the third-party application end.
  • the request is returned through the above call, and the processing result is returned, that is, the user is allowed to access the function that he wants to access, and the corresponding data is acquired. If the verification of the permission of any of the above data requests fails, the verification fails, and the verification result is returned.
  • the verification result includes the specific abnormal reason that the verification cannot pass, for example, the user does not have the corresponding authority, and the third-party application has no permission.
  • the method before the step S4 of performing the authority verification on the user information, the method includes:
  • the binding relationship between the first temporary token and the third-party application end is established, and in this step, the third-party application end is verified. If the first temporary token and the first temporary token are used in this step, If the temporary token does not correspond, it may be determined that the third-party application has the possibility of stealing data. To ensure the security of the user data, it is determined that the verification fails.
  • the user information includes a user type and user account information
  • the step of performing rights verification on the user information includes:
  • the user type and user account information are verified in turn to verify whether the user has access rights.
  • step S4a the user continues to verify whether the user has the access right. Specifically, the user type is first determined to meet the requirements. If the user meets the requirements, the user account information is determined to meet the requirements. Further, it is not only possible to verify whether the user has the access right of the application, but also to further determine whether the module specifically accessed by the user has the corresponding authority. For example, the data application end in this embodiment has multiple modules, and different modules are open to different user groups. Therefore, it is not only required to verify whether the user has the right to access the data application end, but also needs to verify whether it has the right to access a certain module. .
  • the data request in the step S3 further includes IP address information of the third-party application end.
  • the IP address information is uploaded, and in this embodiment, the authority of the IP address information can also be verified.
  • the method before the step S4 of performing the authority verification on the user information, the method includes:
  • the database of the server has a list of authorized ranges of IP addresses pre-stored, that is, the call request sent in the IP address in the authorized range list can be passed, and the verification outside the authorized range fails.
  • the IP address information of the third-party application end is in the authorization range, verify whether the second temporary token is the same as the first temporary token, if in this step, the first temporary token and the second temporary order If the card does not correspond, it may be determined that the third-party application stores the possibility of stealing data. In order to ensure the security of the user data, it is determined that the verification fails.
  • the user continues to verify whether the user has the access right. Specifically, the user type is first determined to meet the requirements. If the user account information meets the requirements, the user account information is determined to meet the requirements. Further, it is not only possible to verify whether the user has the access right of the application, but also to further determine whether the module specifically accessed by the user has the corresponding authority. For example, the data application end in this embodiment has multiple modules, and different modules are open to different user groups. Therefore, it is not only required to verify whether the user has the right to access the data application end, but also needs to verify whether it has the right to access a certain module. .
  • the data request further includes time information that the third-party application sends the call request.
  • the server has pre-set the time period during which the data can be accessed, that is, the data access is enabled within a preset time period.
  • step S4 of performing the authority verification on the data request it is also required to verify whether the time when the third party application end issues the call request is within a preset time period.
  • reduce the running pressure of the server analyze the number of users calling the API interface according to the history, analyze which time period is the peak access period, and set a limited access time according to the peak period.
  • the list limits the specified user's call access, or directly restricts all users from being able to call.
  • the user may also set a list by combining the IP address information of the call request by the third-party application end, and the user in the list is limited to the IP address that can be accessed in the corresponding time period. For example, during peak hours, only users in a certain province can be called to access, and there is no restriction outside the peak period.
  • a third-party application is restricted from making an API interface call.
  • the current access volume is monitored from time to time. If the access volume is higher than the threshold, the specified user is restricted from invoking the access, which may be to limit the calling access permission of a certain local user, or to limit the calling API interface of a third-party application at the current moment. Permissions.
  • the method includes:
  • the user can directly access the data application end on the third-party application end, and the server matches the corresponding data page according to the user data request, and sends the data page to the third-party application end.
  • step S6 of displaying the data page requested by the data request on the third-party application end includes:
  • the content of the page in the data page is standardized and passed through the FILE through the JSOUP component (a Java HTML parser that directly parses a URL address, HTML text content).
  • the WITER component implementation inserts the standardized content into the page of the third-party application according to the page layout of the third-party application.
  • the method for verifying the API interface when receiving a request for a third-party application to invoke an API interface, sends a binding relationship with the feature information of the third-party application end.
  • the first temporary token is sent to the third-party application end, and the first temporary token is used as a unique identifier of the third-party application end, so as to avoid the risk of insecure user data when stolen; no user is required to input the password, and at the same time It is necessary to verify various information in the data request, enhance the security of the data accessed by the user, simplify the user operation, and overcome the cumbersome operation of calling the API interface and the insecure call.
  • the present application further provides a verification apparatus for calling an API interface, including:
  • the first receiving unit 10 is configured to receive a call request of the third-party application end to the API interface, where the call request carries the feature information of the third-party application end.
  • the feature information includes a preset ID and password of a third-party application having a calling right.
  • the server in this embodiment is pre-configured with a list of IDs of third-party applications having calling rights and corresponding passwords.
  • each third-party application has its own feature information, such as an ID, a password, a key, etc., which is used to indicate the uniqueness of each third-party application.
  • the user the requester of the data access
  • the third-party application end may be configured with the entry information (for example, an icon, etc.) of the data application end, and the user clicking the entry information automatically triggers the third-party application end to invoke the call request of the API interface of the data application end, and the call request is further Includes IDs for third-party applications.
  • the server is the management server of the data application end, and the first receiving unit 10 on the server can receive the call request of the third-party application end to the API interface.
  • the data application side is any application end.
  • the data application side in this embodiment is based on the Django framework, and Django is an open source web application framework written by Python.
  • the data application introduces the oauth2 standard, which allows users to let third-party applications access the user's resources (such as photos, videos, contact lists) on the data application without providing usernames and passwords to the data.
  • the purpose of the application is to access the resources under the system authority without logging in the user password, which is convenient for users to access, improving user experience and access efficiency.
  • the sending unit 20 is configured to send a first temporary token to the third-party application end according to the calling request, where the first temporary token is tied with the feature information of the third-party application end. a temporary token for the relationship;
  • the server after receiving the request of the third-party application end to the API interface, the server obtains the ID and password of the third-party application end, and verifies that it is a preset third-party application end with the calling permission, and then issues the same.
  • the unit 20 generates a first temporary token (token) according to the ID, and establishes a binding relationship between the first temporary token and the ID of the third-party application end, and the validity of the first temporary token has a certain time limit, such as Minutes, half an hour, etc.
  • the key information (having uniqueness) may also be obtained from the above-mentioned feature information, and a key is generated according to the key of the third-party application end and the ID corresponding to the ID.
  • the first temporary token with a binding relationship. It is possible to prevent other third-party applications from stealing the above temporary token and spoofing by modifying its ID to steal data.
  • the second receiving unit 30 is configured to receive a data request sent by the user through the third-party application end, where the data request carries a second temporary token and user information that is logged into the third-party application end user.
  • the third temporary application when the third temporary application receives the first temporary token sent by the server, the first temporary token is used as the parameter value as the unique identifier of the third-party application, and the user passes the third-party application.
  • the terminal sends a data request, and the second receiving unit 30 accepts the above data request.
  • the data request includes data information that the user wants to access (operations that the user needs to perform or data that he wants to obtain), user information of the user, temporary tokens, and feature information of the third-party application end.
  • the third-party application When a user logs in to a third-party application, the third-party application records user information (user name, etc.). When the user invokes the API interface through the third-party application, the third-party application sends the user information to the server. According to the user information, it is possible to identify which third-party application the user invokes the API interface, and according to the ID of the third-party application and the user type, it can be determined whether the user is a user within the authority. If the second temporary token is the same as the first temporary token, it can be determined whether the third-party application is the application end of the API interface, and is prevented from being impersonated.
  • the verification unit 40 is configured to perform rights verification on the user information when the first temporary token is the same as the second temporary token;
  • the verification unit 40 Since the data request carries the data information that needs to be accessed, after the verification unit 40 verifies the authority of the user information, the user can directly access the data information without re-issuing the data information.
  • the authority verification of the verification unit 40 is to realize the content of the user authority directly in the data application end without requiring the user to input the user password again, that is, to realize the secret-free login.
  • the verification unit 40 needs to perform authority verification on each of the above data requests. For example, it is first verified whether the third-party application is an application that initiates an API interface request, and then checks whether the user type and the data application match in the preset permission system, and checks whether the user has the corresponding operation permission. . That is, it is determined whether the data application end allows the third party application end of the requesting party to invoke the data application end, and judges whether the user has the right to access the data application end according to the user name. In this embodiment, each item in the data request is verified, and multiple verifications are performed to enhance security and prevent user data from being stolen.
  • the processing unit 50 is configured to process, according to the verification result, a call request of the third-party application end to the API interface.
  • the server after the server verifies the authority of the user information, the server performs corresponding processing according to the verification result.
  • the server automatically verifies the user's access rights, and simplifies the user's operation; and the above-mentioned authentication mechanism when calling the API interface ensures the security of the user data.
  • the processing unit 50 includes:
  • the first processing module 501 is configured to: if the verification succeeds, request the calling of the API interface by using the third-party application end.
  • the second processing module 502 is configured to: if the verification fails, the feedback includes the verification result with the abnormal cause to the third-party application end.
  • the first processing module 501 requests and returns the processing result through the above call, that is, allows the user to access the function that he wants to access, and acquires corresponding data. If the verification of the permission of the data request fails, the verification fails, and the second processing module 502 returns the verification result, where the verification result includes a specific abnormal reason that the verification cannot pass, for example, the user does not have the corresponding permission, and the third-party application No permissions, etc.
  • the verification unit 40 includes:
  • a first verification module 401 configured to verify whether the first temporary token is the same as the second temporary token
  • the binding relationship between the first temporary token and the third-party application end is established, and the first verification module 401 is to verify the third-party application end, if the first temporary token and the second temporary token are If the temporary token does not correspond, it may be determined that the third-party application end has the possibility of stealing data. To ensure the security of the user data, it is determined that the verification fails.
  • the second verification module 402 is configured to verify, according to the binding relationship between the temporary token and the feature information of the third-party application end, the user type and the user account information to verify whether the user has access rights. .
  • the second verification module 402 continues to verify whether the user has the access right.
  • the user type may be first determined to meet the requirements. If the user account information is met, the user account information is determined. Meet the requirements. Further, it is not only possible to verify whether the user has the access right of the application, but also to further determine whether the module specifically accessed by the user has the corresponding authority.
  • the data application end in this embodiment has multiple modules, and different modules are open to different user groups. Therefore, it is not only required to verify whether the user has the right to access the data application end, but also needs to verify whether it has the right to access a certain module. .
  • the data request further includes IP address information of the third-party application end.
  • the IP address information is uploaded, and in this embodiment, the authority of the IP address information can also be verified.
  • the verification unit 40 includes:
  • the first verification sub-unit 403 is configured to verify, according to the IP address information of the third-party application end, whether it is within the authorized range.
  • the database of the server has a list of authorized ranges of IP addresses pre-stored, that is, the call request sent in the IP address in the authorized range list can be passed, and the verification outside the authorized range fails.
  • the second verification sub-unit 404 is configured to verify whether the second temporary token is the same as the first temporary token if in the authorization scope.
  • the second verification sub-unit 404 verifies whether the second temporary token is the same as the first temporary token, if the second temporary token and the first temporary token are If the temporary token does not correspond, the third party application may determine that the data is stolen. In order to ensure the security of the user data, it is determined that the verification fails.
  • the third verification sub-unit 405 is configured to verify whether the user has access rights if the same.
  • the third verification sub-unit 405 continues to verify whether the user has the access right, and specifically determines whether the user type meets the requirements, and if the requirements are met, the user account is determined. Whether the information meets the requirements. Further, it is not only possible to verify whether the user has the access right of the application, but also to further determine whether the module specifically accessed by the user has the corresponding authority. For example, the data application end in this embodiment has multiple modules, and different modules are open to different user groups. Therefore, it is not only required to verify whether the user has the right to access the data application end, but also needs to verify whether it has the right to access a certain module. .
  • the data request further includes time information that the third-party application sends the call request.
  • the server has pre-set the time period during which the data can be accessed, that is, the data access is enabled within a preset time period.
  • the verification unit 40 further needs to verify whether the time when the third party application sends the call request is within a preset time period.
  • reduce the running pressure of the server analyze the number of users calling the API interface according to the history, analyze which time period is the peak access period, and set a limited access time according to the peak period.
  • the list limits the specified user's call access, or directly restricts all users from being able to call.
  • the user may also set a list by combining the IP address information of the call request by the third-party application end, and the user in the list is limited to the IP address that can be accessed in the corresponding time period. For example, during peak hours, only users in a certain province can be called to access, and there is no restriction outside the peak period.
  • a third-party application is restricted from making an API interface call.
  • the current access volume is monitored from time to time. If the access volume is higher than the threshold, the specified user is restricted from invoking the access, which may be to limit the calling access permission of a certain local user, or to limit the calling API interface of a third-party application at the current moment. Permissions.
  • the verifying device that invokes the API interface further includes:
  • a display unit configured to display the data page requested by the data request on the third-party application end.
  • the user can directly access the data application end on the third-party application end, and the display unit matches the corresponding data page according to the user data request, and delivers the data page to the third-party application end.
  • the above display unit includes:
  • An extracting module configured to extract page content in the data page, and obtain a page layout of the third-party application end; for example, extract all the text images in the data page.
  • a display module configured to distribute the extracted page content according to a page layout of the third-party application end, and display the distributed page content on the third-party application end.
  • the content of the page in the data page is standardized and passed through the FILE through the JSOUP component (a Java HTML parser that directly parses a URL address, HTML text content).
  • the WITER component implementation inserts the standardized content into the page of the third-party application according to the page layout of the third-party application.
  • the authentication device that invokes the API interface provided in the embodiment of the present application, when receiving a request for a third-party application to invoke an API interface, the call request carries the feature information of the third-party application end,
  • the feature information is a preset ID and password of the third-party application with the call permission;
  • the first temporary token that is bound to the feature information of the third-party application is sent to the third-party application, the first A temporary token is used as the unique identifier of the third-party application to avoid the risk of insecure user data when stolen; no need for the user to input the password, and at the same time, it is necessary to verify various information in the data request, thereby enhancing user access.
  • the data security simplifying user operations, overcoming the cumbersome operation of calling the API interface and the insecure call.
  • the computer device may be a server, and its internal structure may be as shown in FIG. 7.
  • the computer device includes a processor, memory, network interface, and database connected by a system bus. Among them, the computer designed processor is used to provide calculation and control capabilities.
  • the memory of the computer device includes a non-volatile storage medium, an internal memory.
  • the non-volatile storage medium stores an operating system, computer readable instructions, and a database.
  • the internal memory provides an environment for operation of an operating system and computer readable instructions in a non-volatile storage medium.
  • the database of the computer device is used to store data such as computer readable instructions.
  • the network interface of the computer device is used to communicate with an external terminal via a network connection.
  • the computer readable instructions are executed by the processor to implement an authentication method that invokes an API interface.
  • the step of the above-mentioned processor executing the verification method of calling the API interface includes: receiving, by the server, a call request of the third-party application end to the API interface, where the call request carries the feature information of the third-party application end, and the feature information is preset.
  • the step of processing, by the processor, the third party application end to the API interface according to the verification result includes:
  • the third-party application end requests the API interface; if the verification fails, the feedback includes the verification result with the abnormal reason to the third-party application end.
  • the user information includes a user type and user account information
  • the step of the processor performing the rights verification on the user information includes:
  • the user type and user account information are verified in turn to verify whether the user has access rights.
  • the data request further includes IP address information of the third-party application end.
  • the method before the step of performing the authority verification on the user information by the processor, the method includes:
  • IP address information of the third-party application it is verified whether it is within the authorization scope.
  • the step of requesting the API interface by the third-party application end includes:
  • the step of the processor displaying the data page requested by the data request on the third-party application comprises:
  • FIG. 7 is only a block diagram of a part of the structure related to the solution of the present application, and does not constitute a limitation of the computer device to which the present application is applied.
  • An embodiment of the present application further provides a computer non-transparent readable storage medium, where computer readable instructions are stored, and when the computer readable instructions are executed by the processor, a verification method for calling an API interface is implemented, specifically:
  • the server receives a call request from the third-party application end to the API interface, where the call request carries the feature information of the third-party application end, where the feature information is a preset ID and password of the third-party application end with the call permission;
  • the step of processing, by the processor, the third party application end to the API interface according to the verification result includes:
  • the third-party application end requests the API interface; if the verification fails, the feedback includes the verification result with the abnormal reason to the third-party application end.
  • the user information includes a user type and user account information
  • the step of the processor performing the rights verification on the user information includes:
  • the user type and user account information are verified in turn to verify whether the user has access rights.
  • the data request further includes IP address information of the third-party application end.
  • the method before the step of performing the authority verification on the user information by the processor, the method includes:
  • IP address information of the third-party application it is verified whether it is within the authorization scope.
  • the step of requesting the API interface by the third-party application end includes:
  • the step of the foregoing processor displaying the requested data page of the data on the third-party application comprises:
  • the method, device, computer device, and storage medium for invoking an API interface provided in the embodiment of the present application, when receiving a request for a third-party application to invoke an API interface, issue a third party with the third party
  • the first temporary token of the binding relationship is established to the third-party application end, and the first temporary token is used as a unique identifier of the third-party application end to avoid the risk of insecure user data when stolen;
  • the user performs the operation of inputting the password, and needs to verify various information in the data request, enhances the data security of the user access, simplifies the user operation, and overcomes the cumbersome operation of calling the API interface and the insecure call.
  • Non-volatile memory can include read only memory (ROM), programmable ROM (PROM), electrically programmable ROM (EPROM), electrically erasable programmable ROM (EEPROM), or flash memory.
  • Volatile memory can include random access memory (RAM) or external cache memory.
  • RAM is available in a variety of formats, such as static RAM (SRAM), dynamic RAM (DRAM), synchronous DRAM (SDRAM), dual-speed SDRAM (SSRSDRAM), enhanced SDRAM (ESDRAM), synchronization.
  • SRAM static RAM
  • DRAM dynamic RAM
  • SDRAM synchronous DRAM
  • SSRSDRAM dual-speed SDRAM
  • ESDRAM enhanced SDRAM
  • SLDRAM Link (Synchlink) DRAM
  • SLDRAM Memory Bus
  • RDRAM Direct RAM
  • DRAM Direct Memory Bus Dynamic RAM
  • RDRAM Memory Bus Dynamic RAM

Landscapes

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

Abstract

本申请提供调用API接口的验证方法、装置、计算机设备和存储介质，接收第三方应用端对API接口的调用请求；下发一个与调用请求携带的特征信息建立绑定关系的第一临时令牌至第三方应用端；接收第三方应用端发送的数据请求；对数据请求进行权限验证；根据验证结果，处理调用请求；克服调用API接口操作繁琐与调用不安全的缺陷。

Description

调用API接口的验证方法、装置、计算机设备和存储介质
本申请要求于2018年5月4日提交中国专利局、申请号为2018104215513，发明名称为“调用API接口的验证方法、装置、计算机设备和存储介质”的中国专利申请的优先权，其全部内容通过引用结合在本申请中。
技术领域
本申请涉及互联网技术领域，特别涉及一种调用API接口的验证方法、装置、计算机设备和存储介质。
 背景技术
请求方（用户）登录第三方应用端（任意应用端），经常希望在第三方应用上来访问其它的应用，此时，则可以通过调用其它应用的API接口（Application Programming Interface，应用程序编程接口）来访问。
API接口主要是提供给外部应用端（第三方应用端）调用时使用，即用户在其已登录的外部应用端上想要访问其它的应用时，通过调用其它应用的API接口以实现。目前业内调用API接口的方式多为用户密码认证登录、简单token（临时令牌）等方式实现。
用户密码的密码认证登录方式需要用户输入密码或保存密码，操作繁琐不安全。而使用简单token方式虽然可以实现用户免密码登录，但是存在token被抓取或者泄露的风险。
目前Django框架中还没有成熟的跨平台、跨语种的SSO（Single Sign On，单点登录）方案。同时，现有的认证方式也不能很好对接第三方应用的权限控制进行统一的权限管理。
 技术问题
本申请的主要目的为提供一种调用API接口的验证方法、装置、计算机设备和存储介质，克服目前调用API接口操作繁琐以及调用不安全的缺陷。
 技术解决方案
为实现上述目的，本申请提供了一种调用API接口的验证方法，包括以下步骤：
服务器接收第三方应用端对API接口的调用请求，所述调用请求中携带有第三方应用端的特征信息，所述特征信息为预设的具有调用权限的第三方应用端的ID及密码；
根据所述调用请求，下发一个第一临时令牌至所述第三方应用端，其中，所述第一临时令牌是与所述第三方应用端的特征信息建立绑定关系的临时令牌；
接收用户通过所述第三方应用端发送的数据请求，所述数据请求中携带第二临时令牌以及登录所述第三方应用端用户的用户信息；
当所述第一临时令牌与所述第二临时令牌相同时，对所述用户信息进行权限验证；
根据验证结果，处理所述第三方应用端对所述API接口的调用请求。
本申请还提供了一种调用API接口的验证装置，包括：
第一接收单元，用于接收第三方应用端对API接口的调用请求，所述调用请求中携带有第三方应用端的特征信息，所述特征信息为预设的具有调用权限的第三方应用端的ID及密码；
下发单元，用于根据所述调用请求，下发一个第一临时令牌至所述第三方应用端，其中，所述第一临时令牌是与所述第三方应用端的特征信息建立绑定关系的第一临时令牌；
第二接收单元，用于接收用户通过所述第三方应用端发送的数据请求，所述数据请求中携带第二临时令牌以及登录所述第三方应用端用户的用户信息；
验证单元，用于当所述第一临时令牌与所述第二临时令牌相同时，对所述用户信息进行权限验证；
处理单元，用于根据验证结果，处理所述第三方应用端对所述API接口的调用请求。
本申请还提供一种计算机设备，包括存储器和处理器，所述存储器中存储有计算机可读指令，所述处理器执行所述计算机可读指令时实现上述任一项所述方法的步骤。
本申请还提供一种计算机非易失性可读存储介质，其上存储有计算机可读指令，所述计算机可读指令被处理器执行时实现上述任一项所述的方法的步骤。
 有益效果
本申请中提供的调用API接口的验证方法、装置、计算机设备和存储介质，接收到第三方应用端对API接口的调用请求时，下发一个与所述第三方应用端的特征信息建立绑定关系的第一临时令牌至所述第三方应用端，该第一临时令牌作为第三方应用端的唯一标识，避免被窃取时造成用户数据出现不安全的风险；无需用户进行输入密码的操作，同时需要对数据请求中的多种信息进行验证，增强了用户访问的数据安全，简化用户操作，克服目前调用API接口操作繁琐以及调用不安全的缺陷。
 附图说明
图1 是本申请一实施例中调用API接口的验证方法步骤示意图；
图2 是本申请另一实施例中调用API接口的验证方法步骤示意图；
图3 是本申请一实施例中调用API接口的验证装置结构框图；
图4 是本申请一实施例中处理单元结构框图；
图5 是本申请一实施例中验证单元结构框图；
图6 是本申请另一实施例中验证单元结构框图；
图7 是本申请一实施例的计算机设备的结构示意框图。
 本发明的最佳实施方式
参照图1，本申请实施例中提供了一种调用API接口的验证方法，包括以下步骤：
步骤S1，服务器接收第三方应用端对API接口的调用请求，所述调用请求中携带有第三方应用端的特征信息；所述特征信息包括预设的具有调用权限的第三方应用端的ID及其对应的密码，仅通过ID也可以识别该第三方应用端是否具有调用权限，结合密码有助于提升安全性，避免ID被窃取时被假冒。本实施例中的服务器上预设有具有调用权限的第三方应用端的ID的名单及其对应的密码。
在本实施例中，每一个第三方应用端均具有它自己的特征信息，例如ID、密码、密钥等，其用于标示每个第三方应用端的唯一性。用户（数据访问的请求方）通过账户、密码登录上述第三方应用端，并想在第三方应用端上打开其想要访问的数据应用端，以访问其在该数据应用端上的数据，同时又不想登录上述数据应用端，则需要调用该数据应用端的API接口。通常，在该第三方应用端上可以设置有上述数据应用端的入口信息（例如图标等），用户点击入口信息则自动触发第三方应用端调用数据应用端的API接口的调用请求，该调用请求中还包括有第三方应用端的ID。上述服务器为上述数据应用端的管理服务器，其可接收到上述第三方应用端对API接口的调用请求。上述数据应用端为任意应用端，举例地，本实施例中的数据应用端基于Django框架，Django是一个开放源代码的Web应用框架，由Python写成。该数据应用端引入了oauth2标准，该标准中可以允许用户让第三方应用断访问该用户在数据应用端上的资源（例如照片，视频，联系人列表等），而无需将用户名和密码提供给数据应用端，目的就是不需要输入用户密码登录就可以访问到他在系统权限下的资源，方便用户访问，提升用户体验以及访问效率。
步骤S2，根据所述调用请求，下发一个第一临时令牌至所述第三方应用端，其中，所述第一临时令牌是与所述第三方应用端的特征信息建立绑定关系的临时令牌。
本实施例中，服务器接收到上述第三方应用端对API接口的调用请求后，从中获取到第三方应用端的ID及密码，验证其为预设的具有调用权限的第三方应用端时，根据该ID生成一个第一临时令牌（token），将该第一临时令牌与第三方应用端的ID建立绑定关系，上述第一临时令牌的有效性具有一定的时间期限，如一分钟、半小时等。在其它实施例中，为了进一步加强第三方应用端调用API接口的安全性，还可以从上述特征信息中获取到密钥信息（具有唯一性），根据第三方应用端的密钥以及ID对应生成一个具有绑定关系的临时令牌。可以避免其它第三方应用端窃取到上述第一临时令牌，通过修改其ID进行假冒以窃取数据。
步骤S3，接收用户通过所述第三方应用端发送的数据请求，所述数据请求中携带第二临时令牌以及登录所述第三方应用端用户的用户信息。
本实施例中，第三方应用端接收到上述服务器下发的第一临时令牌时，则将上述第一临时令牌作为参数值作为第三方应用端的唯一标识，同时用户通过所述第三方应用端发送数据请求，该数据请求中包括有用户想要访问的数据信息（用户需要进行的操作或者想要获得的数据）、用户的用户信息、临时令牌、第三方应用端的特征信息等。
用户登录到第三方应用端时，该第三方应用端会记录用户信息（用户名等），当用户通过第三方应用端调用API接口时该第三方应用端会将用户信息发送至服务器。根据用户信息可以标识用户是通过哪个第三方应用端来调用API接口，根据第三方应用端的ID以及用户类型可以判断该用户是否为权限内的用户。根据上述第二临时令牌与第一临时令牌是否相同，可以判断该第三方应用端是否为上述调用API接口的应用端，避免被假冒。
步骤S4，当所述第一临时令牌与所述第二临时令牌相同时，对所述用户信息进行权限验证。
由于上述数据请求中携带有需要访问的数据信息，因此对上述用户信息的权限验证之后，用户则可以直接访问，无需再次发出数据信息。本步骤的权限验证就是为了实现不需要用户再次输入用户密码就可以直接在数据应用端中访问到用户权限范围内的内容，即实现免密登录。
在本步骤中，服务器获取到上述数据请求后，为了加强安全性，需要对上述数据请求中的每一项进行权限验证。例如，会先验证上述第三方应用端是否为发起调用API接口请求的应用端，再在预设的权限系统里面核对上述用户类型和数据应用端是否匹配，并查看该用户是否有相应的操作权限。即判断数据应用端是否允许请求方登录的第三方应用端来调用数据应用端，并根据用户名判断该用户是否具有访问数据应用端的权限。本实施例中，针对数据请求中的每一项信息进行验证，多重验证，增强安全性，避免用户数据被窃取。
步骤S5，根据验证结果，处理所述第三方应用端对所述API接口的调用请求。本实施例中，服务器对上述用户信息的权限验证之后，会根据验证结果，分别对应处理。
在上述过程中，始终不需要用户进行相应的登录操作，服务器会对用户的访问权限进行自动验证，简化用户的操作；且上述调用API接口时的验证机制保障了用户数据的安全性。
具体地，上述根据验证结果，处理所述第三方应用端对所述API接口的调用请求的步骤S5，包括：
S51，若验证通过，则通过所述第三方应用端对所述API接口的调用请求；
S52，若验证不通过，则反馈包括有异常原因的验证结果至所述第三方应用端。
在本实施例中，如果上述数据请求的权限验证都通过，则通过上述调用请求并返回处理结果，即允许用户访问其想要访问的功能，获取相应的数据。如果上述数据请求的中任一项权限验证失败，验证不通过，返回验证结果，验证结果中包括有验证无法通过的具体的异常原因，例如用户没有相应权限、第三方应用端无权限等。
在一实施例中，上述对所述用户信息进行权限验证的步骤S4之前，包括：
S4a，验证所述所述第一临时令牌与所述第二临时令牌是否相同。
如上述步骤S2中所述，建立有第一临时令牌与第三方应用端的绑定关系，本步骤中则是对第三方应用端的验证，若在此步骤中，上述第一临时令牌与第二临时令牌不对应，则可以判断该第三方应用端存在窃取数据的可能，为了保障用户数据安全，则判定为验证不通过。
在一实施例中，上述用户信息包括用户类型以及用户账户信息，所述对所述用户信息进行权限验证的步骤，包括：
依次对所述用户类型以及用户账户信息进行验证，以验证所述用户是否具有访问权限。
本实施例中，若上述步骤S4a验证通过，则继续验证该用户是否具有访问权限，具体可以先判断用户类型是否符合要求，若符合要求，再判断用户账户信息是否符合要求。进一步地，不仅可以验证用户是否具有该应用的访问权限，还可以进一步判断其具体访问的模块是否具有相应的权限。例如，本实施例中的数据应用端具有多个模块，不同的模块对不同的用户群体开放，因此不仅需要验证用户是否具有访问数据应用端的权限，还需要验证其是否具有访问某一个模块的权限。
在一实施例中，上述步骤S3中的数据请求中还包括所述第三方应用端的IP地址信息。第三应用端在发送数据请求时，则会一并将IP地址信息上传，本实施例中还可以对IP地址信息的权限进行验证。
在本实施例中，上述对所述用户信息进行权限验证的步骤S4之前，则包括：
S4b，根据所述第三方应用端的IP地址信息，验证是否在授权范围内；
本实施例中，服务器的数据库中预先存储有IP地址的授权范围名单，即限定为在授权范围名单内的IP地址内发送的调用请求才能被通过，授权范围之外的则验证不通过。
当第三方应用端的IP地址信息在授权范围时，则验证所述第二临时令牌与所述第一临时令牌是否相同，若在此步骤中，上述第一临时令牌与第二临时令牌不对应，则可以判断该第三方应用端存储窃取数据的可能，为了保障用户数据安全，则判定为验证不通过。
本实施例中，若上述第二临时令牌验证通过，则继续验证该用户是否具有访问权限，具体可以先判断用户类型是否符合要求，若符合要求，再判断用户账户信息是否符合要求。进一步地，不仅可以验证用户是否具有该应用的访问权限，还可以进一步判断其具体访问的模块是否具有相应的权限。例如，本实施例中的数据应用端具有多个模块，不同的模块对不同的用户群体开放，因此不仅需要验证用户是否具有访问数据应用端的权限，还需要验证其是否具有访问某一个模块的权限。
在另一实施例中，上述数据请求中还包括第三方应用端发出调用请求的时间信息。服务器中预设有数据可以被访问的时间段，即在预设的时间段内，才开启数据的访问。
上述对所述数据请求进行权限验证的步骤S4中，则还需要验证第三方应用端发出调用请求时的时间是否在预设的时间段内。
在另一实施例中，为了增强系统的稳定性，降低服务器的运行压力，根据历史调用API接口的用户量进行分析，分析出哪个时段为访问高峰期，根据高峰期时间段设置一个限制访问时间的名单，在高峰期时间段限制指定的用户进行调用访问，或者直接限制所有用户都不能调用。
在一实施例中，还可以结合用户通过第三方应用端发出调用请求的IP地址信息，设置一个名单，名单中限定有对应时间段内可以访问的IP地址的用户。例如高峰期，则限制只能某个省内用户进行调用访问，在高峰期外则不做限制。
在一实施例中，在高峰期内，则限制某个第三方应用端无法进行API接口调用。或者，时时监控当前的访问量，若访问量高于阈值，则限制指定用户调用访问，可以是限制某地域用户的调用访问权限，也可以是限制当前时刻某个第三方应用端的调用API接口的权限。
参照图2，在一实施例中，上述若验证通过，则通过所述第三方应用端对所述API接口的调用请求的步骤S51之后，包括：
S6，将所述数据请求所请求的数据页面显示于所述第三方应用端上。
若验证通过，则表示用户可以在第三方应用端上直接访问数据应用端，服务器则根据用户数据请求匹配出相应的数据页面，并将数据页面下发至所述第三方应用端上。
具体地，上述将所述数据请求所请求的数据页面显示于所述第三方应用端上的步骤S6，包括：
提取所述数据页面中的页面内容，以及获取所述第三方应用端的页面布局；例如将数据页面中的文字图片全部提取出来。
将提取的所述页面内容按照所述第三方应用端的页面布局进行分布，并将分布后的页面内容显示于所述第三方应用端上。
由于第三方应用端与数据应用端可能框架不同，在第三方应用端上直接访问数据应用端时，可能出现页面不兼容的情况。因此，在本实施例中，通过JSOUP组件（一种Java 的HTML解析器，可直接解析某个URL地址、HTML文本内容）将数据页面中的页面内容进行标准化，并通过FILE WITER组件实现将标准化后的内容按照第三方应用端的页面布局插入至第三方应用端的页面中。
综上所述，为本申请实施例中提供的调用API接口的验证方法，接收到第三方应用端对API接口的调用请求时，下发一个与所述第三方应用端的特征信息建立绑定关系的第一临时令牌至所述第三方应用端，该第一临时令牌作为第三方应用端的唯一标识，避免被窃取时造成用户数据出现不安全的风险；无需用户进行输入密码的操作，同时需要对数据请求中的多种信息进行验证，增强了用户访问的数据安全，简化用户操作，克服目前调用API接口操作繁琐以及调用不安全的缺陷。
参照图3，本申请还提供了一种调用API接口的验证装置，包括：
第一接收单元10，用于接收第三方应用端对API接口的调用请求，所述调用请求中携带有第三方应用端的特征信息。所述特征信息包括预设的具有调用权限的第三方应用端的ID及密码。本实施例中的服务器上预设有具有调用权限的第三方应用端的ID的名单及其对应的密码。
在本实施例中，每一个第三方应用端均具有它自己的特征信息，例如ID、密码、密钥等，其用于标示每个第三方应用端的唯一性。用户（数据访问的请求方）通过账户、密码登录上述第三方应用端，并想在第三方应用端上打开其想要访问的数据应用端，以访问其在该数据应用端上的数据，同时又不想登录上述数据应用端，则需要调用该数据应用端的API接口。通常，在该第三方应用端上可以设置有上述数据应用端的入口信息（例如图标等），用户点击入口信息则自动触发第三方应用端调用数据应用端的API接口的调用请求，该调用请求中还包括有第三方应用端的ID。上述服务器为上述数据应用端的管理服务器，服务器上的第一接收单元10可接收到上述第三方应用端对API接口的调用请求。上述数据应用端为任意应用端，举例地，本实施例中的数据应用端基于Django框架，Django是一个开放源代码的Web应用框架，由Python写成。该数据应用端引入了oauth2标准，该标准中可以允许用户让第三方应用断访问该用户在数据应用端上的资源（例如照片，视频，联系人列表），而无需将用户名和密码提供给数据应用端，目的就是不需要输入用户密码登录就可以访问到他在系统权限下的资源，方便用户访问，提升用户体验以及访问效率。
下发单元20，用于根据所述调用请求，下发一个第一临时令牌至所述第三方应用端，其中，所述第一临时令牌是与所述第三方应用端的特征信息建立绑定关系的临时令牌；
本实施例中，服务器接收到上述第三方应用端对API接口的调用请求后，从中获取到第三方应用端的ID及密码，验证其为预设的具有调用权限的第三方应用端时，下发单元20根据该ID生成一个第一临时令牌（token），将该第一临时令牌与第三方应用端的ID建立绑定关系，上述第一临时令牌的有效性具有一定的时间期限，如一分钟、半小时等。在其它实施例中，为了进一步加强第三方应用端调用API接口的安全性，还可以从上述特征信息中获取到密钥信息（具有唯一性），根据第三方应用端的密钥以及ID对应生成一个具有绑定关系的第一临时令牌。可以避免其它第三方应用端窃取到上述临时令牌，通过修改其ID来进行假冒以窃取数据。
第二接收单元30，用于接收用户通过所述第三方应用端发送的数据请求，所述数据请求中携带第二临时令牌以及登录所述第三方应用端用户的用户信息。
本实施例中，第三方应用端接收到上述服务器下发的第一临时令牌时，则将上述第一临时令牌作为参数值作为第三方应用端的唯一标识，同时用户通过所述第三方应用端发送数据请求，第二接收单元30则接受上述数据请求。该数据请求中包括有用户想要访问的数据信息（用户需要进行的操作或者想要获得的数据）、用户的用户信息、临时令牌、第三方应用端的特征信息等。
用户登录到第三方应用端时，该第三方应用端会记录用户信息（用户名等），当用户通过第三方应用端调用API接口时该第三方应用端会将用户信息发送至服务器。根据用户信息可以标识用户是通过哪个第三方应用端来调用API接口，根据第三方应用端的ID以及用户类型可以判断该用户是否为权限内的用户。根据上述第二临时令牌与第一临时令牌是否相同，可以判断该第三方应用端是否为上述调用API接口的应用端，避免被假冒。
验证单元40，用于当所述第一临时令牌与所述第二临时令牌相同时，对所述用户信息进行权限验证；
由于上述数据请求中携带有需要访问的数据信息，因此验证单元40对上述用户信息的权限验证之后，用户则可以直接访问，无需再次发出数据信息。这里验证单元40的权限验证就是为了实现不需要用户再次输入用户密码就可以直接在数据应用端中访问到用户权限范围内的内容，即实现免密登录。
在本实施例中，第二接收单元30获取到上述数据请求后，为了加强安全性，验证单元40需要对上述数据请求中的每一项进行权限验证。例如，会先验证上述第三方应用端是否为发起调用API接口请求的应用端，再在预设的权限系统里面核对上述用户类型和数据应用端是否匹配，并查看该用户是否有相应的操作权限。即判断数据应用端是否允许请求方登录的第三方应用端来调用数据应用端，并根据用户名判断该用户是否具有访问数据应用端的权限。本实施例中，针对数据请求中的每一项信息进行验证，多重验证，增强安全性，避免用户数据被窃取。
处理单元50，用于根据验证结果，处理所述第三方应用端对所述API接口的调用请求。本实施例中，服务器对上述用户信息的权限验证之后，会根据验证结果，分别对应处理。
在上述过程中，始终不需要用户进行相应的登录操作，服务器会对用户的访问权限进行自动验证，简化用户的操作；且上述调用API接口时的验证机制保障了用户数据的安全性。
在一实施例中，参照图4，上述处理单元50包括：
第一处理模块501，用于若验证通过，则通过所述第三方应用端对所述API接口的调用请求。
第二处理模块502，用于若验证不通过，则反馈包括有异常原因的验证结果至所述第三方应用端。
在本实施例中，如果上述数据请求的权限验证都通过，则第一处理模块501通过上述调用请求并返回处理结果，即允许用户访问其想要访问的功能，获取相应的数据。如果上述数据请求的中任一项权限验证失败，则验证不通过，第二处理模块502返回验证结果，验证结果中包括有验证无法通过的具体的异常原因，例如用户没有相应权限、第三方应用端无权限等。
在一实施例中，参照图5，上述验证单元40包括：
第一验证模块401，用于验证所述第一临时令牌与所述第二临时令牌是否相同；
如上述下发单元20中所述，建立有第一临时令牌与第三方应用端的绑定关系，第一验证模块401则是对第三方应用端的验证，若上述第一临时令牌与第二临时令牌不对应，则可以判断该第三方应用端存在窃取数据的可能，为了保障用户数据安全，则判定为验证不通过。
第二验证模块402，用于若上述临时令牌与所述第三方应用端的特征信息为对应的绑定关系，依次对上述用户类型以及用户账户信息进行验证，以验证所述用户是否具有访问权限。
本实施例中，若上述第一验证模块401验证通过，则第二验证模块402继续验证该用户是否具有访问权限，具体可以先判断用户类型是否符合要求，若符合要求，再判断用户账户信息是否符合要求。进一步地，不仅可以验证用户是否具有该应用的访问权限，还可以进一步判断其具体访问的模块是否具有相应的权限。例如，本实施例中的数据应用端具有多个模块，不同的模块对不同的用户群体开放，因此不仅需要验证用户是否具有访问数据应用端的权限，还需要验证其是否具有访问某一个模块的权限。
在一实施例中，上述数据请求中还包括所述第三方应用端的IP地址信息。第三应用端在发送数据请求时，则会一并将IP地址信息上传，本实施例中还可以对IP地址信息的权限进行验证。
参照图6，在本实施例中，上述验证单元40包括：
第一验证子单元403，用于根据所述第三方应用端的IP地址信息，验证是否在授权范围内。
本实施例中，服务器的数据库中预先存储有IP地址的授权范围名单，即限定为在授权范围名单内的IP地址内发送的调用请求才能被通过，授权范围之外的则验证不通过。
第二验证子单元404，用于若在授权范围，验证所述第二临时令牌与所述第一临时令牌是否相同。
当第三方应用端的IP地址信息在授权范围时，第二验证子单元404则验证所述第二临时令牌与所述第一临时令牌是否相同，若上述第二临时令牌与所述第一临时令牌不对应，则可以判断该第三方应用端存储窃取数据的可能，为了保障用户数据安全，则判定为验证不通过。
第三验证子单元405，用于若相同，则验证所述用户是否具有访问权限。
本实施例中，若上述第二验证子单元404验证通过，第三验证子单元405则继续验证该用户是否具有访问权限，具体可以先判断用户类型是否符合要求，若符合要求，再判断用户账户信息是否符合要求。进一步地，不仅可以验证用户是否具有该应用的访问权限，还可以进一步判断其具体访问的模块是否具有相应的权限。例如，本实施例中的数据应用端具有多个模块，不同的模块对不同的用户群体开放，因此不仅需要验证用户是否具有访问数据应用端的权限，还需要验证其是否具有访问某一个模块的权限。
在另一实施例中，上述数据请求中还包括第三方应用端发出调用请求的时间信息。服务器中预设有数据可以被访问的时间段，即在预设的时间段内，才开启数据的访问。
上述验证单元40则还需要验证第三方应用端发出调用请求时的时间是否在预设的时间段内。
在另一实施例中，为了增强系统的稳定性，降低服务器的运行压力，根据历史调用API接口的用户量进行分析，分析出哪个时段为访问高峰期，根据高峰期时间段设置一个限制访问时间的名单，在高峰期时间段限制指定的用户进行调用访问，或者直接限制所有用户都不能调用。
在一实施例中，还可以结合用户通过第三方应用端发出调用请求的IP地址信息，设置一个名单，名单中限定有对应时间段内可以访问的IP地址的用户。例如高峰期，则限制只能某个省内用户进行调用访问，在高峰期外则不做限制。
在一实施例中，在高峰期内，则限制某个第三方应用端无法进行API接口调用。或者，时时监控当前的访问量，若访问量高于阈值，则限制指定用户调用访问，可以是限制某地域用户的调用访问权限，也可以是限制当前时刻某个第三方应用端的调用API接口的权限。
在一实施例中，上述调用API接口的验证装置还包括：
显示单元，用于将所述数据请求所请求的数据页面显示于所述第三方应用端上。
若验证通过，则表示用户可以在第三方应用端上直接访问数据应用端，显示单元则根据用户数据请求匹配出相应的数据页面，并将数据页面下发至所述第三方应用端上。
具体地，上述显示单元包括：
提取模块，用于提取所述数据页面中的页面内容，以及获取所述第三方应用端的页面布局；例如将数据页面中的文字图片全部提取出来。
显示模块，用于将提取的所述页面内容按照所述第三方应用端的页面布局进行分布，并将分布后的页面内容显示于所述第三方应用端上。
由于第三方应用端与数据应用端可能框架不同，在第三方应用端上直接访问数据应用端时，可能出现页面不兼容的情况。因此，在本实施例中，通过JSOUP组件（一种Java 的HTML解析器，可直接解析某个URL地址、HTML文本内容）将数据页面中的页面内容进行标准化，并通过FILE WITER组件实现将标准化后的内容按照第三方应用端的页面布局插入至第三方应用端的页面中。
综上所述，为本申请实施例中提供的调用API接口的验证装置，接收到第三方应用端对API接口的调用请求时，所述调用请求中携带有第三方应用端的特征信息，所述特征信息为预设的具有调用权限的第三方应用端的ID及密码；下发一个与所述第三方应用端的特征信息建立绑定关系的第一临时令牌至所述第三方应用端，该第一临时令牌作为第三方应用端的唯一标识，避免被窃取时造成用户数据出现不安全的风险；无需用户进行输入密码的操作，同时需要对数据请求中的多种信息进行验证，增强了用户访问的数据安全，简化用户操作，克服目前调用API接口操作繁琐以及调用不安全的缺陷。
参照图7，本申请实施例中还提供一种计算机设备，该计算机设备可以是服务器，其内部结构可以如图7所示。该计算机设备包括通过系统总线连接的处理器、存储器、网络接口和数据库。其中，该计算机设计的处理器用于提供计算和控制能力。该计算机设备的存储器包括非易失性存储介质、内存储器。该非易失性存储介质存储有操作系统、计算机可读指令和数据库。该内存储器为非易失性存储介质中的操作系统和计算机可读指令的运行提供环境。该计算机设备的数据库用于存储计算机可读指令等数据。该计算机设备的网络接口用于与外部的终端通过网络连接通信。该计算机可读指令被处理器执行时以实现一种调用API接口的验证方法。
上述处理器执行上述调用API接口的验证方法的步骤包括：服务器接收第三方应用端对API接口的调用请求，所述调用请求中携带有第三方应用端的特征信息，所述特征信息为预设的具有调用权限的第三方应用端的ID及密码；
根据所述调用请求，下发一个第一临时令牌至所述第三方应用端，其中，所述第一临时令牌是与所述第三方应用端的特征信息建立绑定关系的临时令牌；
接收用户通过所述第三方应用端发送的数据请求，所述数据请求中携带第二临时令牌以及登录所述第三方应用端用户的用户信息；
当所述第一临时令牌与所述第二临时令牌相同时，对所述用户信息进行权限验证；
根据验证结果，处理所述第三方应用端对所述API接口的调用请求。
在一实施例中，上述处理器根据验证结果，处理所述第三方应用端对所述API接口的调用请求的步骤，包括：
若验证通过，则通过所述第三方应用端对所述API接口的调用请求；若验证不通过，则反馈包括有异常原因的验证结果至所述第三方应用端。
在一实施例中，上述用户信息包括用户类型以及用户账户信息，上述处理器对所述用户信息进行权限验证的步骤包括：
依次对所述用户类型以及用户账户信息进行验证，以验证所述用户是否具有访问权限。
在一实施例中，上述数据请求中还包括所述第三方应用端的IP地址信息。
在一实施例中，上述处理器对所述用户信息进行权限验证的步骤之前，包括：
根据所述第三方应用端的IP地址信息，验证是否在授权范围内。
在一实施例中，上述处理器验证通过，则通过所述第三方应用端对所述API接口的调用请求的步骤之后，包括：
将所述数据请求所请求的数据页面显示于所述第三方应用端上。
在一实施例中，上述处理器将所述数据请求所请求的数据页面显示于所述第三方应用端上的步骤，包括：
提取所述数据页面中的页面内容，以及获取所述第三方应用端的页面布局；
将提取的所述页面内容按照所述第三方应用端的页面布局进行分布，并将分布后的页面内容显示于所述第三方应用端上。
本领域技术人员可以理解，图7中示出的结构，仅仅是与本申请方案相关的部分结构的框图，并不构成对本申请方案所应用于其上的计算机设备的限定。
本申请一实施例还提供一种计算机非易失性可读存储介质，其上存储有计算机可读指令，计算机可读指令被处理器执行时实现一种调用API接口的验证方法，具体为：服务器接收第三方应用端对API接口的调用请求，所述调用请求中携带有第三方应用端的特征信息，所述特征信息为预设的具有调用权限的第三方应用端的ID及密码；
根据所述调用请求，下发一个第一临时令牌至所述第三方应用端，其中，所述第一临时令牌是与所述第三方应用端的特征信息建立绑定关系的临时令牌；
接收用户通过所述第三方应用端发送的数据请求，所述数据请求中携带第二临时令牌以及登录所述第三方应用端用户的用户信息；
当所述第一临时令牌与所述第二临时令牌相同时，对所述用户信息进行权限验证；
根据验证结果，处理所述第三方应用端对所述API接口的调用请求。
在一实施例中，上述处理器根据验证结果，处理所述第三方应用端对所述API接口的调用请求的步骤，包括：
若验证通过，则通过所述第三方应用端对所述API接口的调用请求；若验证不通过，则反馈包括有异常原因的验证结果至所述第三方应用端。
在一实施例中，上述用户信息包括用户类型以及用户账户信息，上述处理器对所述用户信息进行权限验证的步骤包括：
依次对所述用户类型以及用户账户信息进行验证，以验证所述用户是否具有访问权限。
在一实施例中，上述数据请求中还包括所述第三方应用端的IP地址信息。
在一实施例中，上述处理器对所述用户信息进行权限验证的步骤之前，包括：
根据所述第三方应用端的IP地址信息，验证是否在授权范围内。
在一实施例中，上述处理器验证通过，则通过所述第三方应用端对所述API接口的调用请求的步骤之后，包括：
将所述数据请求所请求的数据页面显示于所述第三方应用端上。
在一实施例中，上述处理器将所述数据请求所述请求的数据页面显示于所述第三方应用端上的步骤，包括：
提取所述数据页面中的页面内容，以及获取所述第三方应用端的页面布局；
将提取的所述页面内容按照所述第三方应用端的页面布局进行分布，并将分布后的页面内容显示于所述第三方应用端上。
综上所述，为本申请实施例中提供的调用API接口的验证方法、装置、计算机设备和存储介质，接收到第三方应用端对API接口的调用请求时，下发一个与所述第三方应用端的特征信息建立绑定关系的第一临时令牌至所述第三方应用端，该第一临时令牌作为第三方应用端的唯一标识，避免被窃取时造成用户数据出现不安全的风险；无需用户进行输入密码的操作，同时需要对数据请求中的多种信息进行验证，增强了用户访问的数据安全，简化用户操作，克服目前调用API接口操作繁琐以及调用不安全的缺陷。
本领域普通技术人员可以理解实现上述实施例方法中的全部或部分流程，是可以通过计算机可读指令来指令相关的硬件来完成，所述的计算机可读指令可存储与一非易失性计算机可读取存储介质中，该计算机可读指令在执行时，可包括如上述各方法的实施例的流程。其中，本申请所提供的和实施例中所使用的对存储器、存储、数据库或其它介质的任何引用，均可包括非易失性和/或易失性存储器。非易失性存储器可以包括只读存储器（ROM）、可编程ROM（PROM）、电可编程ROM（EPROM）、电可擦除可编程ROM（EEPROM）或闪存。易失性存储器可包括随机存取存储器（RAM）或者外部高速缓冲存储器。作为说明而非局限，RAM通过多种形式可得，诸如静态RAM（SRAM）、动态RAM（DRAM）、同步DRAM（SDRAM）、双速据率SDRAM（SSRSDRAM）、增强型SDRAM（ESDRAM）、同步链路（Synchlink）DRAM（SLDRAM）、存储器总线（Rambus）直接RAM（RDRAM）、直接存储器总线动态RAM（DRDRAM）、以及存储器总线动态RAM（RDRAM）等。
需要说明的是，在本文中，术语“包括”、“包含”或者其任何其它变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、装置、物品或者方法不仅包括那些要素，而且还包括没有明确列出的其它要素，或者是还包括为这种过程、装置、物品或者方法所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括该要素的过程、装置、物品或者方法中还存在另外的相同要素。
以上所述仅为本申请的优选实施例，并非因此限制本申请的专利范围，凡是利用本申请说明书及附图内容所作的等效结构或等效流程变换，或直接或间接运用在其它相关的技术领域，均同理包括在本申请的专利保护范围内。

Claims (20)

  1. 一种调用API接口的验证方法，其特征在于，包括以下步骤：
    接收第三方应用端对API接口的调用请求，所述调用请求中携带有第三方应用端的特征信息，所述特征信息为预设的具有调用权限的第三方应用端的ID及密码；
    根据所述调用请求，下发一个第一临时令牌至所述第三方应用端，其中，所述第一临时令牌是与所述第三方应用端的特征信息建立绑定关系的临时令牌；
    接收用户通过所述第三方应用端发送的数据请求，所述数据请求中携带第二临时令牌以及登录所述第三方应用端用户的用户信息；
    当所述第一临时令牌与所述第二临时令牌相同时，对所述用户信息进行权限验证；
    根据验证结果，处理所述第三方应用端对所述API接口的调用请求。
  2. 根据权利要求1所述的调用API接口的验证方法，其特征在于，所述根据验证结果，处理所述第三方应用端对所述API接口的调用请求的步骤，包括：
    若验证通过，则通过所述第三方应用端对所述API接口的调用请求；若验证不通过，则反馈包括有异常原因的验证结果至所述第三方应用端。
  3. 根据权利要求1所述的调用API接口的验证方法，其特征在于，所述用户信息包括用户类型以及用户账户信息，所述对所述用户信息进行权限验证的步骤，包括：
    依次对所述用户类型以及用户账户信息进行验证，以验证所述用户是否具有访问权限。
  4. 根据权利要求1所述的调用API接口的验证方法，其特征在于，所述数据请求中还包括所述第三方应用端的IP地址信息。
  5. 根据权利要求4所述的调用API接口的验证方法，其特征在于，所述对所述用户信息进行权限验证的步骤之前，包括：
    根据所述第三方应用端的IP地址信息，验证是否在授权范围内。
  6. 根据权利要求2所述的调用API接口的验证方法，其特征在于，所述若验证通过，则通过所述第三方应用端对所述API接口的调用请求的步骤之后，包括：
    将所述数据请求所请求的数据页面显示于所述第三方应用端上。
  7. 根据权利要求6所述的调用API接口的验证方法，其特征在于，所述将所述数据请求所请求的数据页面显示于所述第三方应用端上的步骤，包括：
    提取所述数据页面中的页面内容，以及获取所述第三方应用端的页面布局；
    将提取的所述页面内容按照所述第三方应用端的页面布局进行分布，并将分布后的页面内容显示于所述第三方应用端上。
  8. 一种调用API接口的验证装置，其特征在于，包括：
    第一接收单元，用于接收第三方应用端对API接口的调用请求，所述调用请求中携带有第三方应用端的特征信息，所述特征信息为预设的具有调用权限的第三方应用端的ID及密码；
    下发单元，用于根据所述调用请求，下发一个第一临时令牌至所述第三方应用端，其中，所述第一临时令牌是与所述第三方应用端的特征信息建立绑定关系的第一临时令牌；
    第二接收单元，用于接收用户通过所述第三方应用端发送的数据请求，所述数据请求中携带第二临时令牌以及登录所述第三方应用端用户的用户信息；
    验证单元，用于当所述第一临时令牌与所述第二临时令牌相同时，对所述用户信息进行权限验证；
    处理单元，用于根据验证结果，处理所述第三方应用端对所述API接口的调用请求。
  9. 根据权利要求8所述的调用API接口的验证装置，其特征在于，所述处理单元包括：
    第一处理模块，用于若验证通过，则通过所述第三方应用端对所述API接口的调用请求；
    第二处理模块，用于若验证不通过，则反馈包括有异常原因的验证结果至所述第三方应用端。
  10. 根据权利要求8所述的调用API接口的验证装置，其特征在于，所述用户信息包括用户类型以及用户账户信息，所述验证单元用于：
    依次对所述用户类型以及用户账户信息进行验证，以验证所述用户是否具有访问权限。
  11. 根据权利要求8所述的调用API接口的验证装置，其特征在于，所述数据请求中还包括所述第三方应用端的IP地址信息。
  12. 根据权利要求11所述的调用API接口的验证装置，其特征在于，所述验证单元包括：
    第一验证子单元，用于根据所述第三方应用端的IP地址信息，验证是否在授权范围内。
  13. 根据权利要求9所述的调用API接口的验证装置，其特征在于，还包括：
    显示单元，用于将所述数据请求所请求的数据页面显示于所述第三方应用端上。
  14. 根据权利要求13所述的调用API接口的验证装置，其特征在于，所述显示单元包括：
    提取模块，用于提取所述数据页面中的页面内容，以及获取所述第三方应用端的页面布局；
    显示模块，用于将提取的所述页面内容按照所述第三方应用端的页面布局进行分布，并将分布后的页面内容显示于所述第三方应用端上。
  15. 一种计算机设备，包括存储器和处理器，所述存储器存储有计算机可读指令，其特征在于，所述处理器执行所述计算机可读指令时实现调用API接口的验证方法，所述方法包括：
    接收第三方应用端对API接口的调用请求，所述调用请求中携带有第三方应用端的特征信息，所述特征信息为预设的具有调用权限的第三方应用端的ID及密码；
    根据所述调用请求，下发一个第一临时令牌至所述第三方应用端，其中，所述第一临时令牌是与所述第三方应用端的特征信息建立绑定关系的临时令牌；
    接收用户通过所述第三方应用端发送的数据请求，所述数据请求中携带第二临时令牌以及登录所述第三方应用端用户的用户信息；
    当所述第一临时令牌与所述第二临时令牌相同时，对所述用户信息进行权限验证；
    根据验证结果，处理所述第三方应用端对所述API接口的调用请求。
  16. 根据权利要求15所述的计算机设备，其特征在于，所述处理器根据验证结果，处理所述第三方应用端对所述API接口的调用请求的步骤，包括：
    若验证通过，则通过所述第三方应用端对所述API接口的调用请求；若验证不通过，则反馈包括有异常原因的验证结果至所述第三方应用端。
  17. 根据权利要求15所述的计算机设备，其特征在于，所述用户信息包括用户类型以及用户账户信息，所述处理器对所述用户信息进行权限验证的步骤，包括：
    依次对所述用户类型以及用户账户信息进行验证，以验证所述用户是否具有访问权限。
  18. 一种计算机非易失性可读存储介质，其上存储有计算机可读指令，其特征在于，所述计算机可读指令被处理器执行时实现调用API接口的验证方法，所述方法包括：
    接收第三方应用端对API接口的调用请求，所述调用请求中携带有第三方应用端的特征信息，所述特征信息为预设的具有调用权限的第三方应用端的ID及密码；
    根据所述调用请求，下发一个第一临时令牌至所述第三方应用端，其中，所述第一临时令牌是与所述第三方应用端的特征信息建立绑定关系的临时令牌；
    接收用户通过所述第三方应用端发送的数据请求，所述数据请求中携带第二临时令牌以及登录所述第三方应用端用户的用户信息；
    当所述第一临时令牌与所述第二临时令牌相同时，对所述用户信息进行权限验证；
    根据验证结果，处理所述第三方应用端对所述API接口的调用请求。
  19. 根据权利要求18所述的计算机非易失性可读存储介质，其特征在于，所述处理器根据验证结果，处理所述第三方应用端对所述API接口的调用请求的步骤，包括：
    若验证通过，则通过所述第三方应用端对所述API接口的调用请求；若验证不通过，则反馈包括有异常原因的验证结果至所述第三方应用端。
  20. 根据权利要求18所述的计算机非易失性可读存储介质，其特征在于，所述用户信息包括用户类型以及用户账户信息，所述处理器对所述用户信息进行权限验证的步骤，包括：
    依次对所述用户类型以及用户账户信息进行验证，以验证所述用户是否具有访问权限。
PCT/CN2018/095672 2018-05-04 2018-07-13 调用api接口的验证方法、装置、计算机设备和存储介质 WO2019210579A1 (zh)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
CN201810421551.3 2018-05-04
CN201810421551.3A CN108830099A (zh) 2018-05-04 2018-05-04 调用api接口的验证方法、装置、计算机设备和存储介质

Publications (1)

Publication Number Publication Date
WO2019210579A1 true WO2019210579A1 (zh) 2019-11-07

Family

ID=64147484

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2018/095672 WO2019210579A1 (zh) 2018-05-04 2018-07-13 调用api接口的验证方法、装置、计算机设备和存储介质

Country Status (2)

Country Link
CN (1) CN108830099A (zh)
WO (1) WO2019210579A1 (zh)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN111601038A (zh) * 2020-05-28 2020-08-28 无锡睿勤科技有限公司 一种摄像头的控制方法及装置、电子终端及存储介质

Families Citing this family (10)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN109614778B (zh) * 2018-12-12 2021-07-06 思必驰科技股份有限公司 用户权限的动态配置方法、网关及系统
CN109871287A (zh) * 2018-12-15 2019-06-11 中国平安人寿保险股份有限公司 接口调用方法、装置、计算机装置及存储介质
CN110007950A (zh) * 2019-04-10 2019-07-12 优信拍（北京）信息科技有限公司 一种应用程序接口的管理方法、装置及服务器
CN110287037B (zh) * 2019-05-20 2023-11-03 平安科技（深圳）有限公司 分布式的智能api异步回调方法及装置
CN110414215B (zh) * 2019-06-21 2021-12-10 北京奇艺世纪科技有限公司 应用程序隐私权限声明校正方法、装置及电子设备
CN110740163B (zh) * 2019-09-04 2021-04-02 华云数据控股集团有限公司 幂等性控制方法、装置、电子设备及可读存储介质
CN111901342B (zh) * 2020-07-28 2022-06-17 平安科技（深圳）有限公司 权限申请验证方法、装置、设备及存储介质
CN112738167A (zh) * 2020-12-18 2021-04-30 福建新大陆软件工程有限公司 基于api网关的文件服务开放方法、装置、设备和介质
CN113962696A (zh) * 2021-10-21 2022-01-21 上海阵方科技有限公司 数据调用方法、装置和终端设备
CN114244563A (zh) * 2021-11-15 2022-03-25 珠海许继芝电网自动化有限公司 基于aes加密的前后端跨语言通讯方法及系统

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP1621960A2 (en) * 1996-08-30 2006-02-01 Intertrust Technologies Corp. Secure transaction management
CN103609090A (zh) * 2013-06-19 2014-02-26 华为技术有限公司 身份登录方法及设备
CN103716326A (zh) * 2013-12-31 2014-04-09 华为技术有限公司 一种资源访问方法及用户资源网关
CN106961332A (zh) * 2016-01-11 2017-07-18 腾讯科技（深圳）有限公司 一种权限认证方法及装置

Family Cites Families (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN102378170B (zh) * 2010-08-27 2014-12-10 中国移动通信有限公司 一种鉴权及业务调用方法、装置和系统
CN103051630B (zh) * 2012-12-21 2016-01-27 微梦创科网络科技（中国）有限公司 基于开放平台实现第三方应用授权的方法、装置及系统
CN104519018B (zh) * 2013-09-29 2018-09-18 阿里巴巴集团控股有限公司 一种防止针对服务器的恶意请求的方法、装置和系统
US9602949B2 (en) * 2013-12-11 2017-03-21 Capital One Financial Corporation Systems and methods for populating online applications using third party platforms
CN106302346A (zh) * 2015-05-27 2017-01-04 阿里巴巴集团控股有限公司 Api调用的安全认证方法、装置、系统
CN106897586B (zh) * 2016-08-04 2020-01-14 阿里巴巴集团控股有限公司 一种应用程序编程接口api权限管理方法与装置
CN106506494B (zh) * 2016-10-27 2019-10-11 上海斐讯数据通信技术有限公司 一种开放平台的应用接入方法

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP1621960A2 (en) * 1996-08-30 2006-02-01 Intertrust Technologies Corp. Secure transaction management
CN103609090A (zh) * 2013-06-19 2014-02-26 华为技术有限公司 身份登录方法及设备
CN103716326A (zh) * 2013-12-31 2014-04-09 华为技术有限公司 一种资源访问方法及用户资源网关
CN106961332A (zh) * 2016-01-11 2017-07-18 腾讯科技（深圳）有限公司 一种权限认证方法及装置

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN111601038A (zh) * 2020-05-28 2020-08-28 无锡睿勤科技有限公司 一种摄像头的控制方法及装置、电子终端及存储介质

Also Published As

Publication number Publication date
CN108830099A (zh) 2018-11-16

Similar Documents

Publication Publication Date Title
WO2019210579A1 (zh) 调用api接口的验证方法、装置、计算机设备和存储介质
US11323441B2 (en) System and method for proxying federated authentication protocols
CN106487774B (zh) 一种云主机服务权限控制方法、装置和系统
US12047365B2 (en) System and method for pool-based identity authentication for service access without use of stored credentials
US9172541B2 (en) System and method for pool-based identity generation and use for service access
US10484385B2 (en) Accessing an application through application clients and web browsers
US6807577B1 (en) System and method for network log-on by associating legacy profiles with user certificates
US9191375B2 (en) System and method for accessing integrated applications in a single sign-on enabled enterprise solution
CN115021991A (zh) 未经管理的移动设备的单点登录
US9954850B2 (en) Service locking method, apparatuses and systems thereof
CN105991614B (zh) 一种开放授权、资源访问的方法及装置、服务器
CN103051630A (zh) 基于开放平台实现第三方应用授权的方法、装置及系统
CN111800378B (zh) 一种登录认证方法、装置、系统和存储介质
WO2020173019A1 (zh) 访问凭证验证方法、装置、计算机设备及存储介质
CN111818088A (zh) 授权模式管理方法、装置、计算机设备及可读存储介质
CN112929388B (zh) 网络身份跨设备应用快速认证方法和系统、用户代理设备
CN114866247B (zh) 一种通信方法、装置、系统、终端及服务器
CN109428869B (zh) 钓鱼攻击防御方法和授权服务器
TW201508538A (zh) 用於基於網頁瀏覽器網路餅乾的安全符記的擁有證明
WO2023191777A1 (en) Web-based authentication for desktop applications
CN115834234A (zh) 一种网络接入方法、网络连接系统及存储介质
KR20190069171A (ko) SDN의 보안 인증을 강화하기 위하여 FIDO UAF에 사용자를 식별하기 위한 Open ID IDP를 적용하는 인증 방법 및 인증 장치

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: 18917267

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

32PN Ep: public notification in the ep bulletin as address of the adressee cannot be established

Free format text: NOTING OF LOSS OF RIGHTS PURSUANT TO RULE 112(1) EPC (EPO FORM 1205A DATED 25/03/2021)

122 Ep: pct application non-entry in european phase

Ref document number: 18917267

Country of ref document: EP

Kind code of ref document: A1