WO2016188290A1 - Api调用的安全认证方法、装置、系统 - Google Patents

Api调用的安全认证方法、装置、系统 Download PDF

Info

Publication number
WO2016188290A1
WO2016188290A1 PCT/CN2016/080307 CN2016080307W WO2016188290A1 WO 2016188290 A1 WO2016188290 A1 WO 2016188290A1 CN 2016080307 W CN2016080307 W CN 2016080307W WO 2016188290 A1 WO2016188290 A1 WO 2016188290A1
Authority
WO
WIPO (PCT)
Prior art keywords
token
api request
client
server
identity
Prior art date
Application number
PCT/CN2016/080307
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 WO2016188290A1 publication Critical patent/WO2016188290A1/zh

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/40—Network security protocols
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/04—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks
    • H04L63/0428—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks wherein the data content is protected, e.g. by encrypting or encapsulating the payload

Definitions

  • the present application relates to a technology for securely calling an API, and more particularly to a security authentication method, apparatus, and system for API calls.
  • Internet software products are mainly divided into two categories from product audiences, including popular Internet products for end consumers, such as Sina Weibo Web and Zhiwei.
  • the characteristics of such products are that the objects of such products are human, and most of the provided media content is unstructured text (such as novels, blogs), pictures, audio and video, and the like.
  • Another type of product is aimed at the computer, that is, the main form of the service is an API (Application Programming Interface) that provides a programming interface, which is convenient for programmers to use the API for secondary development.
  • API Application Programming Interface
  • the characteristics of this type of product are that the service object is a computer, and the media content provided is mostly structured text, such as XML, JSON, and the like.
  • the current practice for security authentication is to adopt a method of submitting each authentication each time through authentication information such as user accounts and passwords.
  • the server For the end-consumer product, usually after the user enters the server homepage using the client browser, the server creates a session for the user after the first authentication to the user, and issues a session ID to the user, and the client browser passes the cookie. Or the URL records the session ID, and the session ID information is carried in the next submission request content, and the server receives the session ID. If the session ID is in the server's session ID storage list, the user is considered as a legitimate user.
  • the application provides a security authentication method, device and system for API calls, which improves the authentication efficiency of the client and reduces the burden on the user center under the premise of ensuring security.
  • a secure authentication method for an API call running on a server, the method comprising the steps of:
  • the API request After receiving the API request of the client, if the API request carries a token, verify whether the token in the API request is valid; if the API request does not carry the token or the API request The token is an invalid token, and the authentication information in the API request is submitted to the user center for identity verification; after the user center identity verification is passed, the calculated token is sent to the client;
  • the token in the API request and the token obtained by the calculation are encrypted random numbers obtained by an irreversible algorithm according to pre-agreed parameters.
  • This application verifies the identity of the client by issuing a token to the client and using the token.
  • the encrypted random number is obtained as an token by an irreversible algorithm according to a pre-agreed parameter, and the calculated random number is a random number having a unique value, and the server receives the API request of the client each time. Verify that the token is valid again to ensure the security of the token. Since the user center is not required to be frequently accessed to verify the identity of the client, the number of requests from the server to the user center is reduced while the security is ensured, the burden on the user center is reduced, and the delay and the login verification are accelerated. It also avoids the transient failure of the server requesting the user center due to uncertainties such as fluctuations in the overall environment, thereby improving system performance and stability.
  • a security authentication method for an API call is provided, running on a client, where the method includes the following steps:
  • the token is stored when a token of the server is received; the token is an encrypted random number obtained by an irreversible algorithm according to a pre-agreed parameter;
  • the client of the application After receiving the token of the server, the client of the application stores the token and carries the token in the API request and returns it to the server, so that the server can verify the validity of the token carried in the API, so that the server can There is no need to frequently visit the user center to verify the identity of the client, which ensures the security and reduces the number of requests from the server to the user center, reducing the burden on the user center.
  • a security authentication apparatus for an API call is provided on the server side, including:
  • a first communication module configured to receive an API request of the client
  • a processing module configured to: when the token is carried in the API request, verify whether the token in the API request is valid; the token is not carried in the API request, or the token in the API request is When the invalid token is invalid, the authentication information in the API request is submitted to the user center for identity verification; after the user center identity verification is passed, the calculated obtained token is sent to the second communication module; the API request
  • the token in the token and the token obtained by the calculation are encrypted random numbers obtained by an irreversible algorithm according to pre-agreed parameters
  • a second communication module configured to send the calculated token to the client.
  • This application verifies the identity of the client by issuing a token to the client and using the token.
  • the encrypted random number is obtained as an token by an irreversible algorithm according to a pre-agreed parameter, and the calculated random number is a random number having a unique value, and the server receives the API request of the client each time. Verify that the token is valid again to ensure the security of the token. Since the user center is not required to be frequently accessed to verify the identity of the client, the number of requests from the server to the user center is reduced while the security is ensured, the burden on the user center is reduced, and the delay and the login verification are accelerated. It also avoids the transient failure of the server requesting the user center due to uncertainties such as fluctuations in the overall environment, thereby improving system performance and stability.
  • a security authentication apparatus for an API call which is executed on a client, and includes:
  • a storage module configured to store the token when receiving a token of the server;
  • the token An encrypted random number obtained by an irreversible algorithm according to a pre-agreed parameter;
  • a message construction module configured to carry the token and the authentication information in the API request when constructing an API request
  • a communication module configured to receive the token of the server, send the token to the storage module, and send the API request to the server.
  • the client of the application After receiving the token of the server, the client of the application stores the token and carries the token in the API request and returns it to the server, so that the server can verify the validity of the token carried in the API, so that the server can There is no need to frequently visit the user center to verify the identity of the client, which ensures the security and reduces the number of requests from the server to the user center, reducing the burden on the user center.
  • a security authentication system for an API call including a server and a user center.
  • the server is configured to check whether the token in the API request is valid if the API request carries a token after receiving the API request of the client; if the token is not carried in the API request Or the token in the API request is an invalid token, and the authentication information in the API request is submitted to the user center for identity verification; after the user center identity verification is passed, the calculated token is sent.
  • Giving the client; the token in the API request and the token obtained by the calculation are encrypted random numbers obtained by an irreversible algorithm according to pre-agreed parameters;
  • the user center is configured to perform identity verification on the client according to the authentication information sent by the server, and notify the server of a result of the identity verification.
  • This application verifies the identity of the client by issuing a token to the client and using the token.
  • the encrypted random number is obtained as an token by an irreversible algorithm according to a pre-agreed parameter, and the calculated random number is a random number having a unique value, and the client will make a token after receiving the token of the server.
  • the card is stored, and the token is carried in the API request and returned to the server.
  • the server After receiving the API request from the client, the server checks whether the token is valid again to ensure the security of the token. Since the user center is not required to be frequently accessed to verify the identity of the client, the number of requests of the server to the user center is reduced while ensuring security, and the burden on the user center is reduced. At the same time, the delay is reduced, the login verification is accelerated, and the instant server requesting user center call failure due to the uncertainty of the overall environment fluctuation is avoided, thereby improving system performance and stability.
  • FIG. 1 is a network environment diagram of an embodiment of the present application.
  • FIG. 2 is a flowchart of a method for securely authenticating an API of a server side in an embodiment of the present application
  • FIG. 3 is a flowchart of a method for securely authenticating an API by a client side in an embodiment of the present application
  • FIG. 4 is a sequence diagram of a method for securely calling an API in an application example of the present application
  • FIG. 5 is a hardware architecture diagram of a security authentication apparatus that invokes an API in an embodiment of the present application
  • FIG. 6 is a software logic block diagram of an API security authentication apparatus in an embodiment of the present application.
  • FIG. 7 is a software logic block diagram of an API security authentication apparatus in an embodiment of the present application.
  • FIG. 8 is a software logic block diagram of an API security authentication system in an embodiment of the present application.
  • first, second, third, etc. may be used to describe various information in this application, such information should not be limited to these terms. These terms are only used to refer to the same type of information. This area is separate.
  • the first information may also be referred to as the second information without departing from the scope of the present application.
  • the second information may also be referred to as the first information.
  • the word "if” as used herein may be interpreted as "when” or “when” or "in response to a determination.”
  • the security authentication method of the API call provided by the present application is applicable to an API system in which the client and server interaction process is a stateless interaction.
  • a typical application environment is a REST (Representational State Transfer) style API system.
  • REST-API system REST-API system.
  • REST is usually based on the currently widely used connection protocol, such as HTTP, which is stateless (that is, does not record information about each connection), but contains all state information for the application in the REST transport.
  • FIG. 1 is a more common network environment to which the present application applies.
  • network 100 can generally include any type of wired or wireless communication channel capable of coupling network nodes together. This includes, but is not limited to, a local area network, a wide area network, a combination of networks, or other networks that support communication between two or more computing systems.
  • network 100 includes the Internet.
  • the device included in the network 100 includes a client 101 requesting to invoke an API, a server 102 as a provider of the API, and a user center 103 having the capability of authenticating the client according to the authentication information, and storing the client.
  • Various identification information corresponding to the terminal 101 such as a user account, a password, a user number, and the like.
  • FIG. 2 provides a flow diagram of an embodiment of the present application showing the secure authentication process of the server 102 in the process of calling the API.
  • the server 102 when the client 101 logs in to the server 102 for the first time, since the server 102 has not issued a token to the client 101 at this time, the authentication information of the client 101 needs to be used to authenticate the user center 103; the user center After the verification is passed, the server 102 generates a token by calculation and issues it to the client 101. After the client 101 interacts with the server 102, the token is carried. The server 102 checks the token each time to confirm the client. The source of the terminal 101, if the token in the API request is invalid, is authenticated to the user center 103 again through the authentication information of the client, and the token is re-issued to the client after the authentication is passed.
  • the present application authenticates the identity of the client by issuing a token to the client 101, and if the token is valid, the identity of the client is considered legal.
  • the encrypted random number is obtained as an token by an irreversible algorithm according to a pre-agreed parameter, and the calculated random number is a random number having a unique value, and the server receives the API request of the client each time. Verify that the token is valid again to ensure the security of the token. Since the user center is not required to be frequently accessed to verify the identity of the client, the number of requests of the server 102 to the user center 103 is also reduced while ensuring security, thereby improving system performance and stability.
  • the method for the server 102 to check whether the token in the API request is valid may be: obtaining a pre-agreed parameter according to the index information of the token, calculating the current token by an irreversible algorithm according to the pre-agreed parameter, and determining the current order. Whether the token is the same as the token in the received API request. If the token is the same, it is determined that the token carried in the API request is valid. If the token carried in the API request is valid, the client authentication is considered to be performed. The subsequent interaction process, for example, sends the relevant data of the API interface requested by the client to the client; if not, it determines that the token carried in the API request is invalid.
  • the index information of the token may be sent to the client, so that the client carries the index information of the token together with the calculated token to return to the server 102.
  • the index information and the calculated token are carried in the same message and sent to the client, and the index information and the calculated token are sent to the client as two different messages.
  • the index information is used to find a pre-determined parameter related to the token of the client, which can be regarded as a unique identifier that distinguishes different tokens.
  • the identifier may be generated when the token is calculated, or may be an identity returned by the user center 103 after the client 101 is authenticated (for example, the client's IP address, MAC address, client identifier, User number, user account, etc.).
  • the pre-determined parameters may include parameters related to client uniqueness, for example, may be at least one identity identifier, and the identity identifier may include a client's IP address, a MAC address, a client identifier, a user number, and a user. Account number, etc.
  • the pre-agreed parameters also include the encryption key, and a random number can be used as the encryption key and stored on the server.
  • a hash algorithm can be used as an irreversible algorithm, such as the case described by the example of Equation 1:
  • the Token in Equation 1 is a token that needs to be calculated.
  • the parameters pre-agreed in Equation 1 are the client's MAC address, user code UID, and encryption key KEY.
  • the token can be additionally transmitted in the HTTP protocol header.
  • the pre-agreed parameters may also include a validity period verification parameter, and the validity period verification parameter is also used when generating the token.
  • Input parameters of an irreversible algorithm such as the example described in Equation 2:
  • Token Hash(MAC, UID, SEED, KEY) (Equation 2)
  • the Token in Equation 2 is the token to be calculated.
  • the parameters pre-agreed in Equation 2 are the client's MAC address, user code UID, encryption key KEY, and validity period verification parameter SEED.
  • SEED is a value related to the Token call life cycle. If time is used as SEED, then the Token can be invalid after a fixed time. If the number of calls is SEED, then the Token can be invalid after a fixed number of times. It is easy to understand. , the realization of the validity period verification parameter The method is not limited to the several ways listed.
  • the validity period verification parameter may be sent to the client together; when the client returns the API request, the validity period verification parameter is carried in the HTTP protocol header, and the server obtains the parameter. After the validity period verifies the parameters, it will verify whether the current token expires. For example, if the SEED timestamp has been greater than the expiration time and the SEED call times are greater than the fixed number of times, then the token can be regarded as invalid. If the token in the verification API request has expired, the authentication is re-authenticated to the user center, and the new token is issued again for the client; if not expired, the current token is calculated according to the pre-agreed parameters, and the current token is determined. Is the same as the token in the API request, if the same, the token in the API request is valid, if not the same, the token in the API request is invalid.
  • 3 provides a flow diagram of an embodiment of the present application showing the secure authentication process of the client 101 in the process of calling the API.
  • the authentication information may be sent to the server, and the authentication information is information required for authenticating to the user center, for different design schemes.
  • the content of the authentication information may be different, and the more common ones may be user accounts, passwords, and the like.
  • the server requests the user center to authenticate the identity of the client according to the authentication information of the client. If the authentication fails, the server notifies the client that the identity authentication fails. If the user center passes the client authentication, the server generates the data according to the pre-agreed parameters.
  • the token is returned to the client. As an example, after the client receives the token returned by the server, the token can be stored in the current process space.
  • the index information corresponding to the token can also be stored.
  • the index information of the token can be either a unique random number or an identity identifier, such as the IP address, MAC address, client identifier, user number, and user account of the client.
  • the index information corresponding to the token may be sent through the server, or may be pre-agreed with the server. For example, if the user account is used as the index information, the user account may be saved when the user logs in.
  • the server if the token sent by the client to the server is an invalid token, then the server The client is requested to authenticate the identity of the client according to the authentication information of the client. If the authentication fails, the server will notify the client that the identity authentication fails. If the user center passes the client authentication, the server will again according to the pre-agreed parameters. A new token is generated and returned to the client, which updates the saved token with the new token.
  • the information that may be carried in the API request may include a token, an index information, a user account, a password, and the like according to different embodiments.
  • the secure communication channel can be used for transmission.
  • the API can be invoked using a URL, and the request can be sent as an HTTP "GET" message over an HTTPS session.
  • the client and the server need to agree in advance to calculate the parameters of the token.
  • the parameters that can be obtained by the server can be collected by the client and sent to the server in the API request, for example, some identity such as a MAC address, After the client collects it, it is sent to the server through an API request.
  • FIG. 4 shows a method for securely authenticating an API call in an embodiment of the present application in a specific application scenario.
  • the user wants to use the weather forecast service provided by a certain "weather forecast” client.
  • the user needs to authenticate to the "weather forecast” server through the “weather forecast” client, and the “weather forecast” server authenticates the user identity.
  • the API interface will be opened to allow the "weather forecast” client to read the weather forecast related data and store the photos on the "weather forecast” server. Therefore, after the "weather forecast” client needs to be authorized by the user, the "weather forecast” server will agree to the "weather forecast” client to read the photos.
  • the client 101 is a "weather forecast” client and the server 102 is a “weather forecast” server.
  • the pre-agreed parameters required to calculate the token include the IP address of the client, the user number UID, the encryption key KEY, and the validity period verification parameter SEED.
  • the “weather forecast” client carries the user account and password of the user in the API request, and sends the message to the “weather forecast” server through the HTTPS secure channel; the token and the UID are empty at this time;
  • the “weather forecast” server fails to verify the identity by using the token, and then requests the user center to authenticate the identity of the user.
  • the “weather forecast” server calculates the token according to the IP address carried in the API request and the UID returned by the user center according to the following formula
  • Token Hash(IP, UID, KEY, SEED)
  • the "weather forecast” server sends the Token and the UID, SEED together to the "weather forecast” client, and opens the API interface to the "weather forecast” client;
  • each API request carries Token and UID, SEED and authentication information to the "weather forecast” server; SEED carries the message in HTTP In the head
  • the "weather forecast” server determines whether the SEED has expired, if it expires, according to the authentication information to access the user center for authentication; if not expired, then execute S409;
  • the present application also provides an embodiment of a device for secure authentication of an API call.
  • An embodiment of the device for secure authentication of the API call of the present application can be applied to a server or client.
  • the device embodiment may be implemented by software, or may be implemented by hardware or a combination of hardware and software. Taking the software implementation as an example, as a logical means, the processor or the client's processor reads the corresponding computer program instructions in the non-volatile memory into the memory. From the hardware level, as shown in FIG. 5, a hardware structure diagram of a client or a server where the device for security authentication invoked by the API of the present application is located, except for the processor, memory, network interface, and non- In addition to the volatile memory, the client or the server where the device is located in the embodiment may also include other hardware according to the actual function of the device, and details are not described herein.
  • the software logic block diagram of the security authentication device 600 invoked by the API is as shown in the figure, and is located at the server end, and includes:
  • the first communication module 601 is configured to receive an API request of the client.
  • the processing module 602 is configured to check whether the token in the API request is valid when the API request carries the token, and does not carry the token or the token in the API request in the API request. When the token is invalid, the authentication information in the API request is submitted to the user center for authentication; after the user center authentication is passed, the token is calculated, and the obtained calculation is sent to the second communication module. 603; the token in the API request and the calculated obtained token are encrypted random numbers obtained by an irreversible algorithm according to pre-agreed parameters;
  • the second communication module 603 is configured to send the calculated token to the client.
  • the process of the processing module 602 verifying whether the token is valid may be:
  • the index information of the token is an identity identifier, where the identity identifier includes any one of an IP address, a MAC address, a client identifier, a user ID, and a user account of the client;
  • the communication module 602 is further configured to: after the user center identity verification passes, receive the identity identifier returned by the user center; and send the identity identifier to the client when the token is sent to the client Client
  • the processing module 602 is further configured to: when the token in the API request is valid, obtain the identity identifier from the API request, and search for a pre-agreed parameter corresponding to the identity identifier according to the identity identifier. .
  • the pre-agreed parameter includes at least one identity identifier
  • the identity identifier includes any one of the client's IP address, MAC address, client identifier, user number, and user account.
  • pre-agreed parameters may further include an encryption key, which is a random number.
  • the pre-agreed parameter may further include a validity period verification parameter
  • the communication module 602 is further configured to send the validity period verification parameter to the client when the token is sent to the client;
  • the process of the processing module 602 verifying whether the token is valid may also be:
  • FIG. 7 is a software logic block diagram of the secure authentication device 700 invoked by the API as shown in the figure, the device running on the client, including:
  • the storage module 701 is configured to: when the token of the server is received, store the token; the token and the new token are encrypted random numbers obtained by an irreversible algorithm according to pre-agreed parameters;
  • the message construction module 702 is configured to: when the API request is constructed, carry the token and the authentication information in the API request;
  • the communication module 703 is configured to receive the token of the server, send the token to the storage module, and send the API request to the server.
  • the communication module 703 is further configured to receive the index information of the token sent by the server, and send the information to the storage module 701 for storage;
  • the message construction module 702 is further configured to carry the index information in the API request when constructing the API request.
  • the index information of the token is an identity identifier
  • the identity identifier includes any one of an IP address, a MAC address, a client identifier, a user ID, and a user account of the client.
  • the pre-agreed parameter includes at least one identity identifier, where the identity identifier includes any one of the IP address, the MAC address, the client identifier, the user ID, and the user account of the client;
  • the message construction module 702 is further configured to collect the identity identifier and carry the identity identifier in the API request when constructing an API request.
  • a logical block diagram of the security authentication system 800 invoked by the API of the present application includes a server 102 and a user center 103.
  • the server 102 is configured to: after receiving the API request of the client, if the API request carries a token, verify whether the token in the API request is valid; if the API request does not carry a token or If the token in the API request is an invalid token, the authentication information in the API request is submitted to the user center 103 for identity verification; after the user center 103 passes the identity verification, the obtained token is calculated. Sent to the client; the token in the API request and the calculated token are encrypted random numbers obtained by an irreversible algorithm according to pre-agreed parameters;
  • the user center 103 is configured to perform identity verification on the client according to the authentication information sent by the server 102, and notify the server 102 of the result of the identity verification.
  • the server 102 verifying whether the token is valid includes:
  • the index information of the token is an identity identifier, where the identity identifier includes any one of an IP address, a MAC address, a client identifier, a user ID, and a user account of the client.
  • the user center 103 is further configured to return the identity of the client to the server 102 after being authenticated by the client;
  • the server 102 is further configured to send the identity identifier to the client when the calculated obtained token is sent to the client; when verifying whether the token in the API request is valid, Obtaining the identity identifier from the API request, and searching for a pre-agreed parameter corresponding to the identity identifier according to the identity identifier.
  • the pre-agreed parameter includes at least one identity identifier
  • the identity identifier includes any one of the client's IP address, MAC address, client identifier, user number, and user account.
  • the pre-agreed parameters further include an encryption key, and the encryption key is a random number.
  • a validity period verification parameter the server 102 is further configured to:
  • Whether the server 102 checks whether the token in the API request is valid includes:
  • the device embodiment since it basically corresponds to the method embodiment, reference may be made to the partial description of the method embodiment.
  • the device embodiments described above are merely illustrative, wherein the units described as separate components may or may not be physically separate.
  • the components displayed for the unit may or may not be physical units, ie may be located in one place, or may be distributed over multiple network units. Some or all of the modules may be selected according to actual needs to achieve the objectives of the present application. Those of ordinary skill in the art can understand and implement without any creative effort.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computer Hardware Design (AREA)
  • Computing Systems (AREA)
  • General Engineering & Computer Science (AREA)
  • Telephonic Communication Services (AREA)

Abstract

本申请公开了API调用的安全认证方法、装置和系统，运行于服务器端的方法包括步骤，当收到客户端的API请求后，如果API请求中携带有令牌，则校验所述令牌是否有效；如果API请求中未携带所述令牌或所述令牌为无效令牌，则将API请求中的鉴权信息提交给用户中心进行身份验证；在所述用户中心身份验证通过后，计算获得新的令牌发送给所述客户端；所述令有效牌令牌为根据预先约定的参数通过不可逆算法获得的加密的随机数。本申请能够在保证安全性前提下，减少提升对客户端的身份验证效率，并减少用户中心的负担服务器端性能损耗。

Description

API调用的安全认证方法、装置、系统 技术领域
本申请涉及安全调用API的技术，尤其涉及API调用的安全认证方法、装置、系统。
背景技术
目前互联网软件产品从产品受众主要划分为两大类，包括面向终端消费者的大众类互联网产品，例如新浪微博Web端、知乎Web端等。这类产品的特点在于使用该类产品的对象是人类，大部分提供的媒体内容为无结构化的文本(例如小说、博客)、图片、音视频等。另一类产品面向的受众是计算机，即服务主要形式为提供编程接口的API(Application Programming Interface，应用程序接口)，方便程序员利用该API进行二次开发。这类产品的特点在于服务的对象为计算机，提供的媒体内容大部分为结构化的文本，例如XML、JSON等。
针对API型产品，目前对于安全认证常见的做法是采用通过用户账户和密码等鉴权信息每次提交每次认证的方式。针对终端消费者型的产品，通常是用户使用客户端浏览器进入服务器主页后，服务器在首次对用户认证通过后，为该用户创建一个Session，并向用户颁发Session ID，客户端浏览器通过cookie或者URL记录该Session ID，在下次提交请求内容会携带该Session ID信息，服务器收到Session ID，如果Session ID在服务器的Session ID存储列表里便认为该用户为合法用户。
由于目前对于API型产品的认证方式，每次认证均需要调用用户中心来进行认证，因此当网络调用抖动等意外因素发生时极有可能导致服务端调用用户中心出现间歇性不稳定情况，最终影响到用户调用不稳定。而对于终端消费者型的产品，由于依赖于cookie来存储Session ID，因此存在伪造攻击 的安全漏洞，并且当恶意用户通过嗅探网络协议包并破解了HTTP有关cookie或者Session ID的值后，便可伪装为合法用户向服务器端进行交互。
发明内容
本申请提供API调用的安全认证方法、装置、系统，在保证安全性前提下，提升对客户端的身份验证效率，并减少用户中心的负担。
根据本申请实施例的第一方面，提供一种API调用的安全认证方法，运行于服务器端，该方法包括步骤：
当收到客户端的API请求后，如果所述API请求中携带有令牌，则校验所述API请求中的令牌是否有效；如果所述API请求中未携带令牌或所述API请求中的令牌为无效令牌，则将所述API请求中的鉴权信息提交给用户中心进行身份验证；在所述用户中心身份验证通过后，将计算获得的令牌发送给所述客户端；所述API请求中的令牌和所述计算获得的令牌为根据预先约定的参数通过不可逆算法获得的加密的随机数。
本申请通过向客户端发放令牌，用令牌来对客户端的身份进行验证。在计算令牌时，根据预先约定的参数通过不可逆算法获得加密的随机数作为令牌，这样算出来的随机数是具有唯一值的随机数，服务器在每次收到客户端的API请求后，均再次校验令牌是否有效，以保证令牌的安全性。由于不需要频繁访问用户中心来对客户端的身份进行验证，因此在保证安全性同时也减小服务器对用户中心的请求次数，减少了用户中心的负担，同时减小了时延、加速了登录验证，也避免了由于整体环境的波动等不确定因素引起的瞬间服务端请求用户中心调用失败，从而提升了系统性能和稳定性。
根据本申请实施例的第二方面，提供一种API调用的安全认证方法，运行于客户端，该方法包括步骤：
当接收到服务器的令牌时，将所述令牌存储；所述令牌为根据预先约定的参数通过不可逆算法获得的加密的随机数；
当构造API请求时，将所述令牌及鉴权信息携带在所述API请求；
将所述API请求发送给服务器。
本申请的客户端在收到服务器的令牌后，将令牌存储，并在API请求中携带令牌返回给服务器，从而使服务器可以对API中所携带的令牌的有效性进行验证，以便不需要频繁访问用户中心来对客户端的身份进行验证，实现在保证安全性同时也减小服务器对用户中心的请求次数，减少了用户中心的负担。
根据本申请实施例的第三方面，提供一种API调用的安全认证装置，位于服务器端，包括：
第一通信模块，用于接收客户端的API请求；
处理模块，用于在所述API请求中携带有令牌时，校验所述API请求中的令牌是否有效；在所述API请求中未携带令牌或所述API请求中的令牌为无效令牌时，将所述API请求中的鉴权信息提交给用户中心进行身份验证；在所述用户中心身份验证通过后，将计算获得的令牌发送给第二通信模块；所述API请求中的令牌和所述计算获得的令牌为根据预先约定的参数通过不可逆算法获得的加密的随机数；
第二通信模块，用于向所述客户端发送所述计算获得的令牌。
本申请通过向客户端发放令牌，用令牌来对客户端的身份进行验证。在计算令牌时，根据预先约定的参数通过不可逆算法获得加密的随机数作为令牌，这样算出来的随机数是具有唯一值的随机数，服务器在每次收到客户端的API请求后，均再次校验令牌是否有效，以保证令牌的安全性。由于不需要频繁访问用户中心来对客户端的身份进行验证，因此在保证安全性同时也减小服务器对用户中心的请求次数，减少了用户中心的负担，同时减小了时延、加速了登录验证，也避免了由于整体环境的波动等不确定因素引起的瞬间服务端请求用户中心调用失败，从而提升了系统性能和稳定性。
根据本申请实施例的第四方面，提供一种API调用的安全认证装置，运行于客户端，包括：
存储模块，用于当接收到服务器的令牌时，将所述令牌存储；所述令牌 为根据预先约定的参数通过不可逆算法获得的加密的随机数；
消息构造模块，用于当构造API请求时，将所述令牌及鉴权信息携带在所述API请求；
通信模块，用于接收服务器的所述令牌，并发给所述存储模块，以及将所述API请求发送给服务器。
本申请的客户端在收到服务器的令牌后，将令牌存储，并在API请求中携带令牌返回给服务器，从而使服务器可以对API中所携带的令牌的有效性进行验证，以便不需要频繁访问用户中心来对客户端的身份进行验证，实现在保证安全性同时也减小服务器对用户中心的请求次数，减少了用户中心的负担。
根据本申请实施例的第五方面，提供一种API调用的安全认证系统，包括服务器、用户中心，
所述服务器，用于当收到客户端的API请求后，如果所述API请求中携带有令牌，则校验所述API请求中的令牌是否有效；如果所述API请求中未携带令牌或所述API请求中的令牌为无效令牌，则将所述API请求中的鉴权信息提交给用户中心进行身份验证；在所述用户中心身份验证通过后，将计算获得的令牌发送给所述客户端；所述API请求中的令牌和所述计算获得的令牌为根据预先约定的参数通过不可逆算法获得的加密的随机数；
所述用户中心，用于根据所述服务器发送的所述鉴权信息对所述客户端进行身份验证，以及将身份验证的结果通知所述服务器。
本申请通过向客户端发放令牌，用令牌来对客户端的身份进行验证。在计算令牌时，根据预先约定的参数通过不可逆算法获得加密的随机数作为令牌，这样算出来的随机数是具有唯一值的随机数，客户端在收到服务器的令牌后，将令牌存储，并在API请求中携带令牌返回给服务器，服务器在每次收到客户端的API请求后，均再次校验令牌是否有效，以保证令牌的安全性。由于不需要频繁访问用户中心来对客户端的身份进行验证，因此在保证安全性同时也减小服务器对用户中心的请求次数，减少了用户中心的负担， 同时减小了时延、加速了登录验证，也避免了由于整体环境的波动等不确定因素引起的瞬间服务端请求用户中心调用失败，从而提升了系统性能和稳定性。
附图说明
图1为本申请实施例中一种网络环境图；
图2为本申请实施例中服务器侧调用API的安全认证方法的流程图；
图3为本申请实施例中客户端侧调用API的安全认证方法的流程图；
图4为本申请一个应用实例中调用API的安全认证方法的时序图；
图5为本申请实施例中调用API的安全认证装置的硬件架构图；
图6为本申请一个实施例中API的安全认证装置的软件逻辑框图；
图7为本申请一个实施例中API的安全认证装置的软件逻辑框图；
图8为本申请一个实施例中API的安全认证系统的软件逻辑框图。
具体实施方式
这里将详细地对示例性实施例进行说明，其示例表示在附图中。下面的描述涉及附图时，除非另有表示，不同附图中的相同数字表示相同或相似的要素。以下示例性实施例中所描述的实施方式并不代表与本申请相一致的所有实施方式。相反，它们仅是与如所附权利要求书中所详述的、本申请的一些方面相一致的装置和方法的例子。
在本申请使用的术语是仅仅出于描述特定实施例的目的，而非旨在限制本申请。在本申请和所附权利要求书中所使用的单数形式的“一种”、“所述”和“该”也旨在包括多数形式，除非上下文清楚地表示其他含义。还应当理解，本文中使用的术语“和/或”是指并包含一个或多个相关联的列出项目的任何或所有可能组合。
应当理解，尽管在本申请可能采用术语第一、第二、第三等来描述各种信息，但这些信息不应限于这些术语。这些术语仅用来将同一类型的信息彼 此区分开。例如，在不脱离本申请范围的情况下，第一信息也可以被称为第二信息，类似地，第二信息也可以被称为第一信息。取决于语境，如在此所使用的词语“如果”可以被解释成为“在……时”或“当……时”或“响应于确定”。
本申请所提供的API调用的安全认证方法适用于客户端和服务器交互过程是无状态交互的API系统，一个典型的应用环境是REST(Representational State Transfer，表征性状态传输)风格的API系统，简称REST-API系统。REST通常基于使用HTTP等目前广泛流行的连接协议，HTTP连接是无状态的(也就是不记录每个连接的信息)，而是在REST传输中包含应用的所有状态信息。
图1是本申请所适用的一种较常见的网络环境。如图所示，网络100通常可以包括能够将网络节点耦合到一起的任意类型的有线或无线通信信道。这包括但不限于，局域网、广域网、网络的组合或支持两个或多个计算系统之间的通信的其他网络。在本申请的一种实施方式中，网络100包括因特网。
网络100中所包含的设备包括请求调用API的客户端101、作为API的提供方的服务器102，用户中心103，用户中心103具备根据鉴权信息对客户端进行身份认证的能力，并保存有客户端101所对应的各种标识信息，例如用户账号、密码、用户编号等。
图2提供了本申请的实施例的流程图，其中示出了服务器102在调用API的过程中的安全认证流程。
S201，接收客户端的API请求；
S202，如果API请求中携带有令牌，则校验API请求中的令牌是否有效；如果API请求中未携带令牌或API请求中的令牌为无效令牌，则将API请求中的鉴权信息提交给用户中心进行身份验证；在用户中心身份验证通过后，计算获得新的令牌，将计算获得的令牌发送给客户端；API请求中携带的令牌和计算所获得的令牌均为根据预先约定的参数通过不可逆算法获得的加密的随机数。
在本申请中，当客户端101首次登录服务器102时，由于此时服务器102尚未向客户端101发放令牌，因此，需要使用客户端101的鉴权信息向用户中心103进行身份验证；用户中心103验证通过后，服务器102会通过计算生成令牌并发放给客户端101，之后，客户端101与服务器102交互时携带此令牌，服务器102每次对这个令牌进行校验，来确认客户端101的来源，如果API请求中的令牌无效，则再次通过客户端的鉴权信息向用户中心103进行身份认证，认证通过后会重新向客户端发放令牌。
本申请通过向客户端101发放令牌，用令牌来对客户端的身份进行验证，如果令牌有效，则认为该客户端的身份合法。在计算令牌时，根据预先约定的参数通过不可逆算法获得加密的随机数作为令牌，这样算出来的随机数是具有唯一值的随机数，服务器在每次收到客户端的API请求后，均再次校验令牌是否有效，以保证令牌的安全性。由于不需要频繁访问用户中心来对客户端的身份进行验证，因此在保证安全性同时也减小服务器102对用户中心103的请求次数，提升了系统性能和稳定性。
在一个实施例中，服务器102校验API请求中的令牌是否有效的途径可以是根据令牌的索引信息获得预先约定的参数，根据预先约定的参数通过不可逆算法计算当前令牌，判断当前令牌与所收到的API请求中的令牌是否相同，如果相同，则判断该API请求中携带的令牌有效，如果API请求中携带的令牌有效，则认为该客户端身份验证通过，进行后续的交互过程，例如，将客户端请求的API接口的相关数据发送给客户端；如果不相同，则判断API请求中携带的令牌无效。
服务器102在将计算后获得的令牌发送给客户端101时，可以将令牌的索引信息发给客户端，以便客户端携带此令牌的索引信息连同计算获得的令牌一起返回给服务器102，作为一个实施例，可以将索引信息与计算获得的令牌携带在同一条消息中发送给客户端，也可以将索引信息和计算获得的令牌作为两条不同的消息发送给客户端。索引信息用来找到计算与该客户端的令牌相关的预先预定的参数，可以看做是区分不同令牌的唯一标识。例如， 可以是在计算令牌时，生成一个唯一性的字符串；或者可以是用户中心103在对客户端101认证通过后返回的一个身份标识(例如，客户端的IP地址、MAC地址、客户端标识、用户编号、用户账号等等)。
为了能够计算出具有唯一值，且可重现的随机数作为令牌，需要预先约定好相关的参数以及算法，在发放令牌时和校验令牌有效性时使用相同的参数及算法来计算令牌。
作为一个例子，预先预定好的参数可以包括与客户端唯一性有关的参数，例如，可以是至少一种身份标识，身份标识可以包括客户端的IP地址、MAC地址、客户端标识、用户编号、用户账号等。
为了能够更好地防止恶意用户通过尝试猜测到预先约定的参数的具体值以获得令牌，预先约定的参数还包括加密秘钥，可以将一个随机数作为加密秘钥并保存在服务器上。
作为一个例子，可以通过哈希算法作为不可逆算法，例如公式1的例子所描述的情形：
Token＝Hash(MAC,UID,KEY)  (公式1)
公式1中Token为需要计算的令牌，在公式1中预先约定的参数为客户端的MAC地址、用户编码UID、加密秘钥KEY。
在一个例子中，令牌可以附加在HTTP协议头中传输，为了更好的防止令牌被盗用的风险，预先约定的参数还可以包括有效期验证参数，在生成令牌时将有效期验证参数也作为不可逆算法的输入参数，例如公式2所描述的实例：
Token＝Hash(MAC,UID,SEED,KEY)  (公式2)
公式2中Token为需要计算的令牌，在公式2中预先约定的参数为客户端的MAC地址、用户编码UID、加密秘钥KEY、有效期验证参数SEED。SEED是一个跟Token调用生命周期相关的值，如果以时间作为SEED，那么可以选择在固定的时间后该Token失效，如果以调用次数作为SEED，那么可以选择在固定次数之后该Token失效，容易理解，有效期验证参数的实现 方式不局限于所列举的几种方式。
在计算获得令牌后，向客户端发送该令牌时，可以将有效期验证参数一并发送至客户端；客户端返回API请求时在HTTP的协议头中携带此有效期验证参数，服务器端获取有效期验证参数后，将验证当前的令牌是否过期，例如SEED时间戳已经和当前时间间隔大于失效时间，或者SEED调用次数大于固定次数，那么可以视作令牌已经失效。如果校验API请求中的令牌已经失效，那么重新向用户中心认证鉴权，并为客户端再次颁发新令牌；如果未过期，则根据预先约定的参数计算当前令牌，判断当前令牌与API请求中的令牌是否相同，如果相同，则API请求中的令牌有效，如果不相同，则API请求中的令牌无效。
图3提供了本申请的实施例的流程图，其中示出了客户端101在调用API的过程中的安全认证流程。
S301，当接收到服务器的令牌时，将令牌存储；
在一个实施例中，客户端在首次向服务器发送调用API的请求时，可以将鉴权信息发送给服务器，鉴权信息是用来向用户中心进行鉴权所需要的信息，对于不同的设计方案，鉴权信息的内容可以不同，较常见的可以是用户账户、密码等信息。服务器根据客户端的鉴权信息向用户中心请求认证该客户端的身份，如果认证不通过，则服务器将通知客户端身份认证失败，如果用户中心对客户端认证通过，则服务器将根据预先约定的参数生成令牌返回给客户端。作为一个例子，在客户端收到服务器返回的令牌后，可以将令牌存储在当前的进程空间中。另外，还可以将令牌所对应的索引信息进行存储。令牌的索引信息既可以是一个具有唯一性的随机数，也可以是身份标识，例如客户端的IP地址、MAC地址、客户端标识、用户编号、用户账号等信息。令牌所对应的索引信息可以是通过服务器发送过来，也可以是与服务器预先约定好的信息，例如，如果将用户账号作为索引信息，则可以在用户登录时将用户账号进行保存。
在另一个实施例中，如果客户端发给服务器的令牌为无效令牌，则服务器 再次根据客户端的鉴权信息向用户中心请求认证该客户端的身份，如果认证不通过，则服务器将通知客户端身份认证失败，如果用户中心对客户端认证通过，则服务器再次将根据预先约定的参数生成新的令牌返回给客户端，客户端用新的令牌更新已保存的令牌。
S302，当构造API请求时，将令牌及鉴权信息携带在API请求中；
从S301可以看出，API请求中依据不同的实施例，可能携带的信息可以包括令牌、索引信息、用户账户、密码等。
S303，将API请求发送给服务器。
由于令牌是经过加密的不可逆随机数，因此被截获后无法获取到令牌中的具体值，为了保证索引信息、用户账号、密码等敏感信息不被恶意截获，可以使用安全通信信道进行发送。例如，可以使用URL来调用API，并且请求可以通过HTTPS会话、作为HTTP“GET(得到)”消息来发送。
在一个例子中，客户端与服务器需要事先约定计算令牌的参数，对于服务器无法获得的参数，可以通过客户端收集后在API请求中发送给服务器，例如，一些诸如MAC地址的身份标识，可以在客户端收集后，通过API请求发送给服务器。
图4示出了具体的应用场景下本申请实施例的API调用的安全认证方法。
假设用户希望使用某“天气预报”的客户端提供的天气预报服务，用户为了使用该服务，需要通过“天气预报”客户端向“天气预报”服务器身份认证，“天气预报”服务器认证用户身份合法后，才会开放API接口允许“天气预报”的客户端读取天气预报的相关数据自己储存在“天气预报”服务器上的照片。因此“天气预报”客户端需要得到用户授权后，“天气预报”服务器才会同意“天气预报”客户端读取这些照片。在本应用实例中，客户端101为“天气预报”客户端，服务器102为“天气预报”服务器。在本应用实例中，计算令牌所需要的预先约定的参数包括客户端的IP地址、用户编号UID、加密秘钥KEY、有效期验证参数SEED。
S401，用户打开“天气预报”客户端以后，输入用户账户和密码，并要求“天气预报”客户端向“天气预报”服务器获取天气预报数据；
S402，“天气预报”客户端将用户的用户账号及密码携带在API请求中，通过HTTPS安全通道发送给“天气预报”服务器；此时令牌和UID为空；
S403，由于令牌值为空，因此“天气预报”服务器通过令牌验证身份失败，于是向用户中心请求认证该用户的身份；
S404，用户中心认证后，返回认证结果。如果用户中心的认证未能通过，将直接报错，并返回错误信息。如果认证通过并将该用户的用户编码一起返回给“天气预报”服务器；
S405，“天气预报”服务器根据API请求中携带的IP地址、以及用户中心返回的UID，按照以下公式计算出令牌；
Token＝Hash(IP，UID,KEY，SEED)
S406，“天气预报”服务器将Token及UID、SEED一并发送给“天气预报”客户端，并向“天气预报”客户端开放API接口；
S407，“天气预报”客户端在后续对“天气预报”服务器的访问过程中，每个API请求都会携带Token及UID、SEED及鉴权信息发送给“天气预报”服务器；SEED携带在HTTP的消息头中；
S408，“天气预报”服务器判断SEED是否已过期，如果过期，则根据根据鉴权信息访问用户中心进行认证；如果没过期，则执行S409；
S409，根据UID读出所存储的KEY、IP地址，连同UID、SEED作为输入参数再次计算Token的值，如果与“天气预报”客户端所发送的Token值相同，则允许“天气预报”客户端访问相关的天气预报数据(S410)；如果未通过，则再次根据鉴权信息访问用户中心进行认证，按照S411执行认证过程(图中未示出)；
S411，用户中心认证后，返回认证结果。如果用户中心的认证未能通过，将直接报错，并返回错误信息。如果认证通过并将该用户的用户编码一起返回给天气预报服务器；天气预报服务器再次计算Token值，并将新获得 的Token值发送给“天气预报”客户端。
与前述API调用的安全认证的方法的实施例相对应，本申请还提供了API调用的安全认证的装置的实施例。
本申请API调用的安全认证的装置的实施例可以应用在服务器或客户端上。装置实施例可以通过软件实现，也可以通过硬件或者软硬件结合的方式实现。以软件实现为例，作为一个逻辑意义上的装置，是通过其所在服务器或客户端的处理器将非易失性存储器中对应的计算机程序指令读取到内存中运行形成的。从硬件层面而言，如图5所示，为本申请API调用的安全认证的装置所在客户端或服务器的一种硬件结构图，除了图5所示的处理器、内存、网络接口、以及非易失性存储器之外，实施例中装置所在的客户端或服务器通常根据该设备的实际功能，还可以包括其他硬件，对此不再赘述。
请参考图6，API调用的安全认证装置600的软件逻辑框图如图所示，位于服务器端，包括：
第一通信模块601，用于接收客户端的API请求；
处理模块602，用于在所述API请求中携带有令牌时，校验所述API请求中的令牌是否有效；在所述API请求中未携带令牌或所述API请求中的令牌为无效令牌时，将所述API请求中的鉴权信息提交给用户中心进行身份验证；在所述用户中心身份验证通过后，计算获得令牌，并将计算获得的发送给第二通信模块603；所述API请求中的令牌和计算获得的令牌为根据预先约定的参数通过不可逆算法获得的加密的随机数；
第二通信模块603，用于向客户端发送计算获得的令牌。
在一个实施例中，所述处理模块602校验所述令牌是否有效的过程可以是：
根据所述令牌的索引信息获得所述预先约定的参数，根据所述预先约定的参数通过不可逆算法计算当前令牌，判断当前令牌与所述API请求中的令牌是否相同，如果相同，则API请求中的令牌有效，如果不相同，则API请求中的令牌无效。
在一个实施例中，所述令牌的索引信息为身份标识，所述身份标识包括所述客户端的IP地址、MAC地址、客户端标识、用户编号、用户账号中的任意一种信息；所述通信模块602还用于在所述用户中心身份验证通过后，接收所述用户中心返回的身份标识；并在将所述令牌发送给所述客户端时，将所述身份标识发给所述客户端；
所述处理模块602还用于当校验API请求中的令牌是否有效时，从所述API请求中获取所述身份标识，根据所述身份标识查找与所述身份标识对应的预先约定的参数。
在一个实施例中，预先约定的参数包括至少一种身份标识，所述身份标识包括所述客户端的IP地址、MAC地址、客户端标识、用户编号、用户账号中的任意一种信息。
另外，预先约定的参数还可以包括加密秘钥，所述加密秘钥为随机数。
再者，预先约定的参数还可以包括有效期验证参数，所述通信模块602还用于向所述客户端发送所述令牌时，将所述有效期验证参数发送至客户端；
所述处理模块602校验所述令牌是否有效的过程还可以是：
根据所述有效期验证参数判断所述令牌是否过期，如果已过期，则所述API请求中的令牌失效；如果未过期，则根据所述预先约定的参数计算当前令牌，判断当前令牌与所述API请求中的令牌是否相同，如果相同，则所述API请求中的令牌有效，如果不相同，则所述API请求中的令牌无效。
图7是API调用的安全认证装置700的软件逻辑框图如图所示，该装置运行于客户端，包括：
存储模块701，用于当接收到服务器的令牌时，将所述令牌存储；所述令牌和所述新的令牌为根据预先约定的参数通过不可逆算法获得的加密的随机数；
消息构造模块702，用于当构造API请求时，将所述令牌及鉴权信息携带在所述API请求；
通信模块703，用于接收服务器的所述令牌，并发给所述存储模块，以及将所述API请求发送给服务器。
其中所述通信模块703还用于接收所述服务器发送的令牌的索引信息，并发给所述存储模块701存储；
消息构造模块702还用于当构造所述API请求时，将所述索引信息携带在所述API请求中。
在一个实施例中，所述令牌的索引信息为身份标识，所述身份标识包括所述客户端的IP地址、MAC地址、客户端标识、用户编号、用户账号中的任意一种信息。
在一个实施例中，预先约定的参数包括至少一种身份标识，所述身份标识包括所述客户端的IP地址、MAC地址、客户端标识、用户编号、用户账号中的任意一种信息；所述消息构造模块702还用于收集所述身份标识，并在构造API请求时，将所述身份标识携带在所述API请求中。
请参见图8，为本申请API调用的安全认证系统800的逻辑框图，包括服务器102、用户中心103。
服务器102，用于当收到客户端的API请求后，如果所述API请求中携带有令牌，则校验所述API请求中的令牌是否有效；如果所述API请求中未携带令牌或所述API请求中的令牌为无效令牌，则将所述API请求中的鉴权信息提交给用户中心103进行身份验证；在所述用户中心103身份验证通过后，将计算获得的令牌发送给所述客户端；API请求中令牌和计算获得的令牌为根据预先约定的参数通过不可逆算法获得的加密的随机数；
所述用户中心103，用于根据所述服务器102发送的所述鉴权信息对所述客户端进行身份验证，以及将身份验证的结果通知所述服务器102。
在一个实施例中，所述服务器102校验所述令牌是否有效包括：
根据所述令牌的索引信息获得所述预先约定的参数，根据所述预先约定的参数通过不可逆算法计算当前令牌，判断当前令牌与所述API请求中的令牌是否相同，如果相同，则所述API请求中的令牌有效，如果不相同，则所 述API请求中的令牌无效。
在一个实施例中，所述令牌的索引信息为身份标识，所述身份标识包括所述客户端的IP地址、MAC地址、客户端标识、用户编号、用户账号中的任意一种信息；
所述用户中心103还用于在通过所述客户端的身份验证后，将所述客户端的身份标识返回给所述服务器102；
所述服务器102还用于将所述计算获得的令牌发送给所述客户端时，将所述身份标识发给所述客户端；当校验所述API请求中的令牌是否有效时，从所述API请求中获取所述身份标识，根据所述身份标识查找与所述身份标识对应的预先约定的参数。
在一个实施例中，预先约定的参数包括至少一种身份标识，所述身份标识包括所述客户端的IP地址、MAC地址、客户端标识、用户编号、用户账号中的任意一种信息。
另外，在另一个实施例中，预先约定的参数还包括加密秘钥，所述加密秘钥为随机数。以及有效期验证参数，所述服务器102还用于：
向所述客户端发送所述计算获得的令牌时，将所述有效期验证参数发送至客户端；
所述服务器102校验所述API请求中的令牌是否有效包括：
根据所述有效期验证参数判断所述API请求中的令牌是否过期，如果已过期，则所述令牌失效；如果未过期，则根据所述预先约定的参数计算当前令牌，判断当前令牌与所述API请求中的令牌是否相同，如果相同，则所述令牌有效，如果不相同，则所述API请求中的令牌无效。
上述装置中各个单元的功能和作用的实现过程具体详见上述方法中对应步骤的实现过程，在此不再赘述。
对于装置实施例而言，由于其基本对应于方法实施例，所以相关之处参见方法实施例的部分说明即可。以上所描述的装置实施例仅仅是示意性的，其中所述作为分离部件说明的单元可以是或者也可以不是物理上分开的，作 为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部模块来实现本申请方案的目的。本领域普通技术人员在不付出创造性劳动的情况下，即可以理解并实施。
以上所述仅为本申请的较佳实施例而已，并不用以限制本申请，凡在本申请的精神和原则之内，所做的任何修改、等同替换、改进等，均应包含在本申请保护的范围之内。

Claims (26)

  1. 一种API调用的安全认证方法，运行于服务器端，其特征在于，该方法包括步骤：
    当收到客户端的API请求后，如果所述API请求中携带有令牌，则校验所述API请求中的令牌是否有效；如果所述API请求中未携带令牌或所述API请求中的令牌为无效令牌，则将所述API请求中的鉴权信息提交给用户中心进行身份验证；在所述用户中心身份验证通过后，将计算获得的令牌发送给所述客户端；所述API请求中的令牌和所述计算获得的令牌为根据预先约定的参数通过不可逆算法获得的加密的随机数。
  2. 根据权利要求1所述的方法，其特征在于，校验所述API请求中的令牌是否有效的过程包括：
    根据所述API请求中的令牌的索引信息获得所述预先约定的参数，根据所述预先约定的参数通过不可逆算法计算当前令牌，判断当前令牌与所述API请求中的令牌是否相同，如果相同，则所述API请求中的令牌有效，如果不相同，则所述API请求中的令牌无效。
  3. 根据权利要求2所述的方法，其特征在于，所述API请求中的令牌的索引信息为身份标识，所述身份标识包括所述客户端的IP地址、MAC地址、客户端标识、用户编号、用户账号中的任意一种信息；所述方法还包括：
    在所述用户中心通过所述客户端的身份验证后，接收所述用户中心返回的身份标识；
    将所述计算获得的令牌发送给所述客户端时，将所述身份标识发给所述客户端；
    当校验所述API请求中的令牌是否有效时，从所述API请求中获取所述身份标识，根据所述身份标识查找与所述身份标识对应的预先约定的参数。
  4. 根据权利要求1所述的方法，其特征在于：
    预先约定的参数包括至少一种身份标识，所述身份标识包括所述客户端的IP地址、MAC地址、客户端标识、用户编号、用户账号中的任意一种信息。
  5. 根据权利要求4所述的方法，其特征在于：预先约定的参数还包括加密秘钥，所述加密秘钥为随机数。
  6. 根据权利要求4所述的方法，其特征在于，预先约定的参数还包括有效期验证参数，所述方法还包括步骤：
    向所述客户端发送所述计算获得的令牌时，将所述有效期验证参数发送至客户端；
    校验所述API请求中的令牌是否有效的步骤包括：
    根据所述有效期验证参数判断所述API请求中的令牌是否过期，如果已过期，则所述API请求中的令牌失效；如果未过期，则根据所述预先约定的参数计算当前令牌，判断当前令牌与所述API请求中的令牌是否相同，如果相同，则所述API请求中的令牌有效，如果不相同，则所述API请求中的令牌无效。
  7. 一种API调用的安全认证方法，运行于客户端，其特征在于，该方法包括步骤：
    当接收到服务器的令牌时，将所述令牌存储；所述令牌为根据预先约定的参数通过不可逆算法获得的加密的随机数；
    当构造API请求时，将所述令牌及鉴权信息携带在所述API请求中；
    将所述API请求发送给服务器。
  8. 根据权利要求7所述的方法，其特征在于，所述方法还包括步骤：
    当接收到服务器所发送的令牌的索引信息时，将所述令牌的索引信息存储；
    当构造所述API请求时，将所述索引信息携带在所述API请求中。
  9. 根据权利要求8所述的方法，其特征在于，所述令牌的索引信息为身份标识，所述身份标识包括所述客户端的IP地址、MAC地址、客户端标 识、用户编号、用户账号中的任意一种信息。
  10. 根据权利要求7所述的方法，其特征在于，预先约定的参数包括至少一种身份标识，所述身份标识包括所述客户端的IP地址、MAC地址、客户端标识、用户编号、用户账号中的任意一种信息；所述方法还包括步骤：
    收集所述身份标识，并在构造API请求时，将所述身份标识携带在所述API请求中。
  11. 一种API调用的安全认证装置，位于服务器端，其特征在于，包括：
    第一通信模块，用于接收客户端的API请求；
    处理模块，用于在所述API请求中携带有令牌时，校验所述API请求中的令牌是否有效；在所述API请求中未携带令牌或所述API请求中的令牌为无效令牌时，将所述API请求中的鉴权信息提交给用户中心进行身份验证；在所述用户中心身份验证通过后，将计算获得的令牌发送给第二通信模块；所述API请求中的令牌和所述计算获得的令牌为根据预先约定的参数通过不可逆算法获得的加密的随机数；
    所述第二通信模块，用于向所述客户端发送所述计算获得的令牌。
  12. 根据权利要求11所述的装置，其特征在于，所述处理模块校验所述API请求中的令牌是否有效包括：
    根据所述API请求中的令牌的索引信息获得所述预先约定的参数，根据所述预先约定的参数通过不可逆算法计算当前令牌，判断当前令牌与所述API请求中的令牌是否相同，如果相同，则所述API请求中的令牌有效，如果不相同，则所述API请求中的令牌无效。
  13. 根据权利要求12所述的装置，其特征在于，所述API请求中的令牌的索引信息为身份标识，所述身份标识包括所述客户端的IP地址、MAC地址、客户端标识、用户编号、用户账号中的任意一种信息；所述通信模块还用于在所述用户中心通过所述客户端的身份验证后，接收所述用户中心返回的身份标识；并在将所述计算获得的令牌发送给所述客户端时，将所述身份标识发给所述客户端；
    所述处理模块还用于当校验所述API请求中的令牌是否有效时，从所述API请求中获取所述身份标识，根据所述身份标识查找与所述身份标识对应的预先约定的参数。
  14. 根据权利要求11所述的装置，其特征在于：
    预先约定的参数包括至少一种身份标识，所述身份标识包括所述客户端的IP地址、MAC地址、客户端标识、用户编号、用户账号中的任意一种信息。
  15. 根据权利要求14所述的装置，其特征在于：预先约定的参数还包括加密秘钥，所述加密秘钥为随机数。
  16. 根据权利要求14所述的装置，其特征在于，预先约定的参数还包括有效期验证参数，所述通信模块还用于向所述客户端发送所述令牌时，将所述有效期验证参数发送至客户端；
    所述处理模块校验所述API请求中的令牌是否有效包括：
    根据所述有效期验证参数判断所述API请求中的令牌是否过期，如果已过期，则所述API请求中的令牌失效；如果未过期，则根据所述预先约定的参数计算当前令牌，判断当前令牌与所述API请求中的令牌是否相同，如果相同，则所述API请求中的令牌有效，如果不相同，则所述API请求中的令牌无效。
  17. 一种API调用的安全认证装置，运行于客户端，其特征在于，包括：
    存储模块，用于当接收到服务器的令牌时，将所述令牌存储；所述令牌为根据预先约定的参数通过不可逆算法获得的加密的随机数；
    消息构造模块，用于当构造API请求时，将所述令牌及鉴权信息携带在所述API请求；
    通信模块，用于接收服务器的所述令牌，并发给所述存储模块，以及将所述API请求发送给服务器。
  18. 根据权利要求17所述的装置，其特征在于，所述通信模块还用于接收所述服务器发送的令牌的索引信息，并发给所述存储模块存储；
    消息构造模块还用于当构造所述API请求时，将所述索引信息携带在所述API请求中。
  19. 根据权利要求18所述的装置，其特征在于，所述令牌的索引信息为身份标识，所述身份标识包括所述客户端的IP地址、MAC地址、客户端标识、用户编号、用户账号中的任意一种信息。
  20. 根据权利要求17所述的装置，其特征在于，预先约定的参数包括至少一种身份标识，所述身份标识包括所述客户端的IP地址、MAC地址、客户端标识、用户编号、用户账号中的任意一种信息；所述消息构造模块还用于收集所述身份标识，并在构造API请求时，将所述身份标识携带在所述API请求中。
  21. 一种API调用的安全认证系统，包括服务器、用户中心，其特征在于，
    所述服务器，用于当收到客户端的API请求后，如果所述API请求中携带有令牌，则校验所述API请求中的令牌是否有效；如果所述API请求中未携带令牌或所述API请求中的令牌为无效令牌，则将所述API请求中的鉴权信息提交给用户中心进行身份验证；在所述用户中心身份验证通过后，将计算获得的令牌发送给所述客户端；所述API请求中的令牌和所述计算获得的令牌为根据预先约定的参数通过不可逆算法获得的加密的随机数；
    所述用户中心，用于根据所述服务器发送的所述鉴权信息对所述客户端进行身份验证，以及将身份验证的结果通知所述服务器。
  22. 根据权利要求21所述的系统，其特征在于，所述服务器校验所述API请求中的令牌是否有效包括：
    根据所述API请求中的令牌的索引信息获得所述预先约定的参数，根据所述预先约定的参数通过不可逆算法计算当前令牌，判断当前令牌与所述API请求中的令牌是否相同，如果相同，则所述API请求中的令牌有效，如果不相同，则所述API请求中的令牌无效。
  23. 根据权利要求22所述的系统，其特征在于，所述API请求中的令牌 的索引信息为身份标识，所述身份标识包括所述客户端的IP地址、MAC地址、客户端标识、用户编号、用户账号中的任意一种信息；
    所述用户中心还用于在通过所述客户端的身份验证后，将所述客户端的身份标识返回给所述服务器；
    所述服务器还用于将所述计算获得的令牌发送给所述客户端时，将所述身份标识发给所述客户端；当校验所述API请求中的令牌是否有效时，从所述API请求中获取所述身份标识，根据所述身份标识查找与所述身份标识对应的预先约定的参数。
  24. 根据权利要求21所述的系统，其特征在于：
    预先约定的参数包括至少一种身份标识，所述身份标识包括所述客户端的IP地址、MAC地址、客户端标识、用户编号、用户账号中的任意一种信息。
  25. 根据权利要求24所述的系统，其特征在于：预先约定的参数还包括加密秘钥，所述加密秘钥为随机数。
  26. 根据权利要求24所述的系统，其特征在于，预先约定的参数还包括有效期验证参数，所述服务器还用于：
    向所述客户端发送所述计算获得的令牌时，将所述有效期验证参数发送至客户端；
    所述服务器校验所述API请求中的令牌是否有效包括：
    根据所述有效期验证参数判断所述API请求中的令牌是否过期，如果已过期，则所述API请求中的令牌失效；如果未过期，则根据所述预先约定的参数计算当前令牌，判断当前令牌与所述API请求中的令牌是否相同，如果相同，则所述API请求中的令牌有效，如果不相同，则所述API请求中的令牌无效。
PCT/CN2016/080307 2015-05-27 2016-04-27 Api调用的安全认证方法、装置、系统 WO2016188290A1 (zh)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
CN201510280745.2 2015-05-27
CN201510280745.2A CN106302346A (zh) 2015-05-27 2015-05-27 Api调用的安全认证方法、装置、系统

Publications (1)

Publication Number Publication Date
WO2016188290A1 true WO2016188290A1 (zh) 2016-12-01

Family

ID=57392441

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2016/080307 WO2016188290A1 (zh) 2015-05-27 2016-04-27 Api调用的安全认证方法、装置、系统

Country Status (2)

Country Link
CN (1) CN106302346A (zh)
WO (1) WO2016188290A1 (zh)

Cited By (16)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN108259437A (zh) * 2016-12-29 2018-07-06 北京神州泰岳软件股份有限公司 一种http访问方法、http服务器和系统
CN109495426A (zh) * 2017-09-12 2019-03-19 腾讯科技（深圳）有限公司 一种数据访问方法、装置及电子设备
CN110263574A (zh) * 2019-06-06 2019-09-20 深圳前海微众银行股份有限公司 数据管理方法、装置、系统及可读存储介质
CN110287265A (zh) * 2019-06-28 2019-09-27 深圳市元征科技股份有限公司 一种登录请求处理方法、装置、服务器及可读存储介质
CN110958119A (zh) * 2019-10-25 2020-04-03 泰康保险集团股份有限公司 身份验证方法和装置
CN111080253A (zh) * 2019-12-11 2020-04-28 深圳供电局有限公司 随机太阳式输电线路现场作业方法与系统
CN111416846A (zh) * 2020-03-12 2020-07-14 苏州浪潮智能科技有限公司 一种通信方法、系统、服务器及存储介质
CN112437079A (zh) * 2020-11-20 2021-03-02 中国人寿保险股份有限公司 一种内网访问方法及装置
CN113485824A (zh) * 2021-04-24 2021-10-08 中电长城网际系统应用广东有限公司 一体化运维平台的api接口管理方法
CN113672884A (zh) * 2021-08-23 2021-11-19 浙江大华技术股份有限公司 身份认证方法、装置、存储介质和身份认证设备
CN113761503A (zh) * 2020-09-14 2021-12-07 北京沃东天骏信息技术有限公司 接口调用的处理方法及装置
CN114117401A (zh) * 2022-01-22 2022-03-01 深圳竹云科技股份有限公司 Api安全调用方法、装置、设备以及计算机存储介质
CN114760133A (zh) * 2022-04-15 2022-07-15 中国电信股份有限公司 RESTful接口认证方法、装置、系统、设备及介质
CN114826778A (zh) * 2022-06-21 2022-07-29 杭州安恒信息技术股份有限公司 一种鉴权方法、装置、设备及介质
CN114928487A (zh) * 2022-05-18 2022-08-19 山东浪潮智慧医疗科技有限公司 一种解决高并发场景下微信令牌失效的方法
CN115134113A (zh) * 2022-05-13 2022-09-30 山东鲁软数字科技有限公司 平台数据安全认证方法、系统、终端及存储介质

Families Citing this family (34)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN108322416B (zh) * 2017-01-16 2022-04-15 腾讯科技（深圳）有限公司 一种安全认证实现方法、装置及系统
CN107196950B (zh) * 2017-06-12 2020-06-16 武汉斗鱼网络科技有限公司 校验方法、装置及服务端
CN107493286A (zh) * 2017-08-23 2017-12-19 杭州安恒信息技术有限公司 一种基于安全鉴权的rpc远程过程调用方法
WO2019047064A1 (zh) * 2017-09-06 2019-03-14 深圳峰创智诚科技有限公司 权限控制方法及服务端
CN107911344A (zh) * 2017-10-28 2018-04-13 杭州安恒信息技术有限公司 一种云平台的安全对接方法
CN107911381A (zh) * 2017-12-01 2018-04-13 济南浪潮高新科技投资发展有限公司 应用程序编程接口的访问方法、系统、服务端及客户端
CN108462581B (zh) * 2018-01-08 2020-09-04 平安科技（深圳）有限公司 网络令牌生成的方法、装置、终端设备及存储介质
CN108259502B (zh) * 2018-01-29 2020-12-04 平安普惠企业管理有限公司 用于获取接口访问权限的鉴定方法、服务端及存储介质
CN108512845B (zh) * 2018-03-30 2020-09-29 广州视源电子科技股份有限公司 接口调用的校验方法及装置
CN108830099A (zh) * 2018-05-04 2018-11-16 平安科技（深圳）有限公司 调用api接口的验证方法、装置、计算机设备和存储介质
CN108989283A (zh) * 2018-05-31 2018-12-11 努比亚技术有限公司 一种数据请求、控制方法、服务器、客户终端及存储介质
CN108809988A (zh) * 2018-06-14 2018-11-13 北京中电普华信息技术有限公司 一种请求的认证方法及系统
CN109189590A (zh) * 2018-08-16 2019-01-11 黄疆 基于RESTful服务的存储管理方法及装置
CN109246092B (zh) * 2018-08-22 2021-08-10 北京旷视科技有限公司 接口管理方法、装置、系统、计算机可读存储介质
CN109309667B (zh) * 2018-08-28 2021-08-13 东软集团股份有限公司 接口调用的认证方法和装置，存储介质和电子设备
CN109391689A (zh) * 2018-10-08 2019-02-26 郑州云海信息技术有限公司 一种微服务应用程序编程接口调用的方法及装置
TWI725352B (zh) * 2018-11-05 2021-04-21 緯創資通股份有限公司 驗證及授權的方法及驗證伺服器
CN109302425B (zh) * 2018-11-28 2021-02-26 河北省科学院应用数学研究所 身份认证方法及终端设备
CN109587251A (zh) * 2018-12-07 2019-04-05 用友网络科技股份有限公司 会话访问方法以及服务器
CN110191112B (zh) * 2019-05-22 2022-03-11 阿波罗智联(北京)科技有限公司 身份验证方法、装置、车载设备和服务器
CN110247905A (zh) * 2019-06-05 2019-09-17 黄疆 基于Token的安全鉴权方式的数据存储备份方法和系统
CN110611564B (zh) * 2019-07-30 2022-11-11 云南昆钢电子信息科技有限公司 一种基于时间戳的api重放攻击的防御系统及方法
CN112579996B (zh) * 2019-09-29 2023-11-03 杭州海康威视数字技术股份有限公司 临时授权方法及装置
CN111030812A (zh) * 2019-12-16 2020-04-17 Oppo广东移动通信有限公司 令牌验证方法、装置、存储介质及服务器
CN111147525A (zh) * 2020-02-27 2020-05-12 深圳市伊欧乐科技有限公司 基于api网关的认证方法、系统、服务器和存储介质
CN111698312B (zh) * 2020-06-08 2022-10-21 中国建设银行股份有限公司 基于开放平台的业务处理方法、装置、设备和存储介质
CN112804269B (zh) * 2021-04-14 2021-07-06 中建电子商务有限责任公司 一种实现网站接口反爬虫的方法
CN113781255A (zh) * 2021-08-06 2021-12-10 广西电网有限责任公司 基于区块链的电力交易系统数据安全存储方法及系统
CN113946811A (zh) * 2021-10-20 2022-01-18 工银科技有限公司 鉴权认证方法及装置
CN114356286A (zh) * 2021-11-29 2022-04-15 南京瀚元科技有限公司 一种低代码化接口开发的方法和系统
CN115242469B (zh) * 2022-07-07 2024-05-24 安天科技集团股份有限公司 安全访问api、安全通信的方法、电子设备及存储介质
CN115296877B (zh) * 2022-07-25 2024-06-14 紫光云技术有限公司 一种jwt存储令牌失效与续期的方法
CN114969684B (zh) * 2022-07-29 2023-06-23 江苏羽驰区块链科技研究院有限公司 基于区块链和抗打印扫描水印的文档打印与溯源追踪方法
CN118378253B (zh) * 2024-06-24 2024-10-15 国家工业信息安全发展研究中心 基于内生安全的api接口动态跳变方法及系统

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101217367A (zh) * 2007-01-04 2008-07-09 中国移动通信集团公司 引入鉴权客户端实现业务鉴权的系统及方法
US20120266229A1 (en) * 2011-04-12 2012-10-18 Salesforce.Com, Inc. Inter-application management of user credential data

Family Cites Families (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8621598B2 (en) * 2008-03-12 2013-12-31 Intuit Inc. Method and apparatus for securely invoking a rest API
CN103188344A (zh) * 2013-02-22 2013-07-03 浪潮电子信息产业股份有限公司 一种安全调用rest api的方法
CN104079407A (zh) * 2013-03-29 2014-10-01 北京千橡网景科技发展有限公司 令牌生成和验证方法以及设备
CN103699824A (zh) * 2014-01-13 2014-04-02 浪潮(北京)电子信息产业有限公司 一种调用rest api的方法、系统及客户端

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101217367A (zh) * 2007-01-04 2008-07-09 中国移动通信集团公司 引入鉴权客户端实现业务鉴权的系统及方法
US20120266229A1 (en) * 2011-04-12 2012-10-18 Salesforce.Com, Inc. Inter-application management of user credential data

Cited By (25)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN108259437A (zh) * 2016-12-29 2018-07-06 北京神州泰岳软件股份有限公司 一种http访问方法、http服务器和系统
CN108259437B (zh) * 2016-12-29 2021-06-04 北京神州泰岳软件股份有限公司 一种http访问方法、http服务器和系统
CN109495426A (zh) * 2017-09-12 2019-03-19 腾讯科技（深圳）有限公司 一种数据访问方法、装置及电子设备
CN110263574A (zh) * 2019-06-06 2019-09-20 深圳前海微众银行股份有限公司 数据管理方法、装置、系统及可读存储介质
CN110263574B (zh) * 2019-06-06 2024-08-27 深圳前海微众银行股份有限公司 数据管理方法、装置、系统及可读存储介质
CN110287265A (zh) * 2019-06-28 2019-09-27 深圳市元征科技股份有限公司 一种登录请求处理方法、装置、服务器及可读存储介质
CN110287265B (zh) * 2019-06-28 2023-10-10 深圳市元征科技股份有限公司 一种登录请求处理方法、装置、服务器及可读存储介质
CN110958119A (zh) * 2019-10-25 2020-04-03 泰康保险集团股份有限公司 身份验证方法和装置
CN111080253B (zh) * 2019-12-11 2023-03-03 深圳供电局有限公司 随机太阳式输电线路现场作业方法与系统
CN111080253A (zh) * 2019-12-11 2020-04-28 深圳供电局有限公司 随机太阳式输电线路现场作业方法与系统
CN111416846A (zh) * 2020-03-12 2020-07-14 苏州浪潮智能科技有限公司 一种通信方法、系统、服务器及存储介质
CN111416846B (zh) * 2020-03-12 2022-12-30 苏州浪潮智能科技有限公司 一种通信方法、系统、服务器及存储介质
CN113761503B (zh) * 2020-09-14 2024-05-17 北京沃东天骏信息技术有限公司 接口调用的处理方法及装置
CN113761503A (zh) * 2020-09-14 2021-12-07 北京沃东天骏信息技术有限公司 接口调用的处理方法及装置
CN112437079B (zh) * 2020-11-20 2023-04-07 中国人寿保险股份有限公司 一种内网访问方法及装置
CN112437079A (zh) * 2020-11-20 2021-03-02 中国人寿保险股份有限公司 一种内网访问方法及装置
CN113485824A (zh) * 2021-04-24 2021-10-08 中电长城网际系统应用广东有限公司 一体化运维平台的api接口管理方法
CN113672884A (zh) * 2021-08-23 2021-11-19 浙江大华技术股份有限公司 身份认证方法、装置、存储介质和身份认证设备
CN114117401A (zh) * 2022-01-22 2022-03-01 深圳竹云科技股份有限公司 Api安全调用方法、装置、设备以及计算机存储介质
CN114760133B (zh) * 2022-04-15 2023-10-03 中国电信股份有限公司 RESTful接口认证方法、装置、系统、设备及介质
CN114760133A (zh) * 2022-04-15 2022-07-15 中国电信股份有限公司 RESTful接口认证方法、装置、系统、设备及介质
CN115134113A (zh) * 2022-05-13 2022-09-30 山东鲁软数字科技有限公司 平台数据安全认证方法、系统、终端及存储介质
CN115134113B (zh) * 2022-05-13 2024-04-09 山东鲁软数字科技有限公司 平台数据安全认证方法、系统、终端及存储介质
CN114928487A (zh) * 2022-05-18 2022-08-19 山东浪潮智慧医疗科技有限公司 一种解决高并发场景下微信令牌失效的方法
CN114826778A (zh) * 2022-06-21 2022-07-29 杭州安恒信息技术股份有限公司 一种鉴权方法、装置、设备及介质

Also Published As

Publication number Publication date
CN106302346A (zh) 2017-01-04

Similar Documents

Publication Publication Date Title
WO2016188290A1 (zh) Api调用的安全认证方法、装置、系统
US11588649B2 (en) Methods and systems for PKI-based authentication
US10652282B2 (en) Brokered authentication with risk sharing
CN106209749B (zh) 单点登录方法及装置、相关设备和应用的处理方法及装置
CN102201915B (zh) 一种基于单点登录的终端认证方法和装置
US9166969B2 (en) Session certificates
US9923906B2 (en) System, method and computer program product for access authentication
CN114679293A (zh) 基于零信任安全的访问控制方法、设备及存储介质
US20210152342A1 (en) Cryptographic key management to prevent data exfiltration
WO2018228036A1 (zh) 校验方法、装置、服务端及可读存储介质
US20210092115A1 (en) Custom authorization of network connected devices using signed credentials
WO2015196908A1 (zh) 业务处理方法、终端、服务器及系统
US20130007867A1 (en) Network Identity for Software-as-a-Service Authentication
US20160381001A1 (en) Method and apparatus for identity authentication between systems
US20140289831A1 (en) Web authentication using client platform root of trust
CN110662091B (zh) 第三方直播视频接入方法、存储介质、电子设备及系统
CN103475666A (zh) 一种物联网资源的数字签名认证方法
WO2022246997A1 (zh) 业务处理方法、装置、服务器及存储介质
EP4162647B1 (en) Anonymous authentication with token redemption
Mohamed et al. Adaptive security architectural model for protecting identity federation in service oriented computing
CN112600674A (zh) 一种前后端分离系统的用户安全认证方法、装置及存储介质
KR101824562B1 (ko) 인증 게이트웨이 및 인증 게이트웨이의 인증 방법
US20130091355A1 (en) Techniques to Prevent Mapping of Internal Services in a Federated Environment
US9553863B2 (en) Computer implemented method and system for an anonymous communication and computer program thereof
CN108390878B (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: 16799179

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

Country of ref document: EP

Kind code of ref document: A1