CN113938328A - Interface label checking method and system - Google Patents
Interface label checking method and system Download PDFInfo
- Publication number
- CN113938328A CN113938328A CN202111556845.5A CN202111556845A CN113938328A CN 113938328 A CN113938328 A CN 113938328A CN 202111556845 A CN202111556845 A CN 202111556845A CN 113938328 A CN113938328 A CN 113938328A
- Authority
- CN
- China
- Prior art keywords
- client
- signature verification
- server
- request
- signature
- Prior art date
- Legal status (The legal status 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 status listed.)
- Pending
Links
Images
Classifications
-
- 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
- H04L63/083—Network architectures or network communication protocols for network security for authentication of entities using passwords
-
- 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
- H04L63/0807—Network architectures or network communication protocols for network security for authentication of entities using tickets, e.g. Kerberos
-
- 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/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
- H04L9/321—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving a third party or a trusted authority
-
- 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/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
- H04L9/3297—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving time stamps, e.g. generation of time stamps
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)
- Computer And Data Communications (AREA)
Abstract
The embodiment of the application discloses a method and a system for interface signature verification, which comprise the following steps: the server receives a synchronous clock request sent by the client and returns a current timestamp of the server; the server receives a service interface request sent by the client and analyzes the signature verification information in the service interface request, wherein the signature verification information comprises a public key, a request timestamp and/or a second signature verification certificate; the server side determines whether the client side request is legal or not based on the signature checking information and the client side parameters, and time validity judgment is added into the signature checking, so that repeated use of signature checking certificates is prevented, and safety is improved.
Description
Technical Field
The present application relates to the field of data transmission, and in particular, to a method and a system for interface signature verification.
Background
From early informatization to current informatization, information interconnection is increasingly emphasized. The interconnection and interworking of various systems are increasing, and in such a background, the communication security between the client and the server is important. Therefore, an interface signature checking method is urgently needed to improve communication safety.
Disclosure of Invention
The specification provides an interface label checking method, and the interface label checking method comprises the following steps: the server receives a synchronous clock request sent by the client and returns a current timestamp of the server; the server receives a service interface request sent by the client and analyzes the signature verification information in the service interface request, wherein the signature verification information comprises a public key, a request timestamp and/or a second signature verification certificate; and the server determines whether the client request is legal or not based on the signature verification information and the client parameters.
Further, the interface signature verification method further includes: the client sends a synchronous clock request to the server to obtain a current timestamp returned by the server, and a clock difference value is calculated based on the current timestamp; the client generates a second signature verification certificate based on the public key, the second secret key, the second interface path and/or the request timestamp; the client generates signature verification information based on the public key, the request timestamp and/or the second signature verification certificate, and sends a service interface request to the server based on the signature verification information; and the client receives the feedback information sent by the server.
Further, the interface signature verification method further includes: the server receives a registration application of the client; the server distributes a secret key and a public key for the client; the server receives a white list IP address and/or preset signature verification effective duration configured by the client;
and the server stores the client parameters, wherein the client parameters comprise a public key, a secret key, a white list IP address and/or preset signature verification effective duration.
Further, the interface signature verification method further includes: analyzing the signature verification information in the service interface request comprises the following steps:
the server analyzes the IP address of the client sending the service interface request; the server side obtains a first interface path requested by the client side;
and the server side acquires the public key, the request timestamp and the second signature verification certificate.
Further, the interface signature verification method further includes: determining whether the client request is legitimate based on the signature verification information and the client parameters comprises: the server side inquires client side parameters stored in a database based on the public key; the server responds to the existence of client parameters corresponding to the public key in the database, and compares the client IP address with a white list IP address in the client parameters; the server side responds to the fact that the IP address of the client side is a white list IP address, and whether the effective signature checking duration is smaller than the preset effective signature checking duration in the client side parameters or not is judged; the server side responds to the fact that the signature verification effective duration is smaller than the preset signature verification effective duration, and generates a first signature verification certificate based on the public key, a first secret key, a first interface path and/or a request timestamp, wherein the first secret key is a secret key obtained from the client side parameters; the server compares the first signature verification certificate with the second signature verification certificate; and determining that the service interface request sent by the client is legal in response to the first signature verification certificate being equal to the second signature verification certificate.
Further, the interface signature verification method further includes: based on the result of the signature verification, the server side sends feedback information to the client side; the feedback information includes:
the server side responds to the fact that client side parameters corresponding to the public key do not exist in the database, and sends feedback information of 'signature error' to the client side; the server side responds to that the IP address of the client side is not the white list IP address, and sends 'illegal IP address' feedback information to the client side; the server side responds to the fact that the signature verification effective duration is larger than the preset signature verification effective duration, and sends feedback information of 'signature expired' to the client side; and the server side responds to the fact that the first signature verification certificate is not equal to the second signature verification certificate, and sends feedback information of 'signature error' to the client side.
Further, the interface signature verification method further includes: the client side puts forward a registration application to the server side so that the server side can distribute a public key and a secret key; the client receives a public key and a secret key distributed by the server; the client configures a white list IP address and/or preset signature verification effective duration at the server.
Further, the feedback information includes "signature error", "IP address is illegal", "signature expired", or "request is legal".
The invention also discloses a system for checking the interface, which comprises:
the synchronous clock request receiving module is used for receiving a synchronous clock request sent by the client side by the server side and returning a current timestamp of the server side;
the service interface request receiving module is used for receiving a service interface request sent by the client side by the server side and analyzing the signature verification information in the service interface request, wherein the signature verification information comprises a public key, a request timestamp and/or a second signature verification certificate;
and the server side is used for determining whether the client side request is legal or not based on the signature checking information and the client side parameters.
Further, the interface signature verification system further includes:
the synchronous clock request sending module is used for sending a synchronous clock request to the server by the client so as to obtain a current timestamp returned by the server and calculate a clock difference value based on the current timestamp;
the second signature verification certificate generation module is used for generating a second signature verification certificate by the client based on the public key, the second secret key, the second interface path and/or the request timestamp;
the service interface request sending module is used for the client side to generate signature verification information based on the public key, the request timestamp and/or the second signature verification certificate and send a service interface request to the server side based on the signature verification information;
and the feedback information receiving module is used for the client side to receive the feedback information sent by the server side.
Drawings
FIG. 1 is an exemplary flow chart of a method of interface signature verification;
FIG. 2 is an exemplary flow chart of a method of determining whether a client request is legitimate;
FIG. 3 is an exemplary flow chart of a method of interface signature verification at a client;
FIG. 4 is an exemplary block diagram of a system for interface verification at a server;
fig. 5 is an exemplary block diagram of a system for interface verification at a client.
Detailed Description
In order to more clearly illustrate the technical solutions of the embodiments of the present disclosure, the drawings used in the description of the embodiments will be briefly described below. It is obvious that the drawings in the following description are only examples or embodiments of the present description, and that for a person skilled in the art, the present description can also be applied to other similar scenarios on the basis of these drawings without inventive effort. Unless otherwise apparent from the context, or otherwise indicated, like reference numbers in the figures refer to the same structure or operation.
The present application will be further explained by way of exemplary embodiments, which will be described in detail by way of the accompanying drawings. These embodiments are not intended to be limiting, and like reference numerals refer to like structures throughout these embodiments.
The application scenario of the embodiment of the present application may include one or more of a server, a client, an open platform, and the like.
In an embodiment, the client may submit a registration request to the server to communicate with the server. For example, the client may register the application directly with the server. For another example, the client may register an application with the server via the open platform. For details of a client making a registration request to a server, refer to fig. 1 and its related description.
In an embodiment, the server may communicate with the client and check the client for signs. For example, the client can directly perform interface check and sign with the server. For another example, the client may interface with the server via the open platform. The specific content of the client for the server to check the label is shown in fig. 1 and its related description.
The open platform may be an intermediate platform for the server to communicate with the client. In an embodiment, the client may submit the registration application to the server through a registration application module provided on the open platform. In an embodiment, the client can configure the server through a configuration management module on the open platform; of course, the server may also configure the client through the configuration management module. For details of the configuration, see fig. 1 and 3 and their associated description.
Fig. 1 is an exemplary flow chart of a method for interface signature verification according to the present application, denoted as flow 100. As shown in fig. 1, the process 100 includes one or more of the following steps. In an embodiment, the process 100 may be performed by the system 400.
In an embodiment, the client may perform a registration application with the server through the open platform, and the server may receive the registration application sent by the client. For example, a client sends a data registration application request to an open platform, and the open platform configures a public key (publicKey) and a secret key (secretekey) for the client based on a server.
And step 120, the server distributes a public key and a secret key for the client. For example, the server may directly or indirectly distribute a public key and a secret key to the client applying for successful registration.
In an embodiment, the server-side system may assign a separate public key and secret key to each client. For example, client a corresponds to public key a and secret key a; the client B corresponds to the public key B and the secret key B.
And step 130, the server receives the white list IP address and/or the preset signature verification effective duration configured by the client.
The white list IP address may refer to an IP address of the access server set by the client at the server. For example, the whitelist IP address is the IP address of the client server. In an embodiment, a client may configure the IP address of its own server as a whitelist IP address.
The preset signature verification effective duration refers to a time period in which the signature verification information is effective. For example, the maximum difference between the preset request timestamp sent by the client and the current timestamp of the server indicates that the signature has expired if the difference is greater than the preset maximum difference. For example, the preset signature validation duration may be 5s, 10s, 1min, or the like.
In an embodiment, the server may determine the preset signature verification effective duration based on the communication duration with the client. For example, the client may use an average of the time taken for the multiple requests to pass through the network to the server as the preset effective time for signature verification.
In an embodiment, the client may configure a white list IP address and a preset signature verification effective duration (ms) in the system management of the server.
In an embodiment, the server may store the client parameters in a database for subsequent use.
And 150, the server receives the synchronous clock request sent by the client and returns the current timestamp of the server.
The synchronous clock request may refer to a request to obtain server-side clock information. For example, the server receives a request sent by the client to obtain the current time of the server.
The current timestamp (timestamp) may refer to time information when the server receives a sync clock request sent by the client. For example, the current timestamp may refer to clock information local to the server.
And step 160, the server receives the service interface request sent by the client and analyzes the signature verification information in the service interface request, wherein the signature verification information comprises a public key, a request timestamp and/or a second signature verification certificate.
A service interface request may refer to a request by a client to request a server interface for data transfer.
In an embodiment, the service interface request may include information transmitted by various requesting interfaces. Such as signature verification information.
The signature verification information refers to information for verifying the signature of the client. For example, information identifying whether the client is trusted.
In embodiments, the signature verification information may include a public key, a request timestamp, and/or a second signature verification credential, among others.
The request timestamp may be used to indicate time information of the request.
In an embodiment, the request timestamp may comprise the client current timestamp ScAnd the clock difference SDWherein the difference of the clocksSDThe clock difference between the client and the server is referred to.
In an embodiment, the server may parse the signature verification information based on various feasible methods. In an embodiment, parsing the signature verification information in the service interface request includes:
the server analyzes the IP address of the client sending the service interface request and records the IP address as clientIp;
the client IP address may refer to the actual IP address at which the client sends the traffic interface request.
The server side obtains a first interface address requested by the client side, and the first interface address is recorded as apiPath 1;
the first interface address may refer to an interface address where the client requests data transmission with the server. Such as the interface address with which the requesting server communicates.
And the server side acquires the public key, the request timestamp and the second signature verification certificate.
In an embodiment, reference is made to fig. 3 and its related description for details of the clock difference value.
The second signature verification voucher refers to a voucher sent by the client for signature verification.
In an embodiment, see fig. 3 and its related description for details of the second signature verification voucher.
In step 170, the server determines whether the client request is legal based on the signature verification information and the client parameters.
The client parameter refers to a parameter which is stored by the server and is related to the client. For example, one or more of basic information, a public key, a secret key, a white list IP address, a preset signature verification valid duration, and the like of the client locally stored in the server are stored.
In an embodiment, the client parameters may be obtained based on the signature verification information. For example, the server obtains the client parameters stored in the server database based on the public key in the signature verification information.
In an embodiment, the server may compare the signature verification information with information in the client parameter, and determine whether the client request is legal based on a comparison result. For details on determining whether the client request is legitimate, see fig. 2 and its associated description.
According to the embodiment of the specification, time validity judgment is added into the interface signature verification, so that repeated use of the signature verification voucher is prevented, and safety is improved.
Fig. 2 is an exemplary flow chart of a method of determining whether a client request is legitimate, denoted as step 200. As shown in fig. 2, step 200 may include one or more of the following. In an embodiment, step 200 may be performed by the determining module 430 and/or the feedback information sending module 440.
And step 230, the server responds to the fact that the client IP address is a white list IP address, and judges whether the effective signature checking duration is smaller than the preset effective signature checking duration in the client parameters.
The effective signature verification duration refers to the actual duration of signature verification performed by the client. For example, the time it takes for a client to send a traffic interface request to pass through the network to a server.
In an embodiment, the signature verification validity duration may be determined based on a difference between the current timestamp and the current request timestamp. For example, the difference between the current timestamp and the current request timestamp is determined as the signature validity duration.
The current request timestamp may refer to the time the service received the traffic interface request. For example, the local time when the service end receives the service interface request sent by the corresponding client.
In an embodiment, the signature verification effective duration may be compared with a preset signature verification effective duration, and it is determined whether the signature verification effective duration is smaller than the preset signature verification effective duration based on the comparison result. For example, the effective time of signature verification is 1s, the preset effective time of signature verification is 3s, and the effective time of signature verification is determined to be less than the preset effective time of signature verification.
And 240, the server generates a first signature verification certificate based on the public key, the first secret key, the first interface path and/or the request timestamp in response to the signature verification effective duration being less than the preset signature verification effective duration.
The first key (secretekey 1) may refer to a key obtained from the client parameter. For example, a key previously assigned to the client at the time of registration application.
The first interface path (apiPath 1) may refer to an interface path (apiPath) obtained from client parameters. For example, the server allocates an interface path for the corresponding client to communicate in advance when registering the application.
The first signature verification voucher can be a signature verification voucher generated by the server based on the signature verification information and the client parameters. For example, a signature verification credential generated based on part of the signature verification information and part of the client parameters is taken by the encryption algorithm used by the client.
In an embodiment, generating the first signing certificate may be performed based on the public key in the signing information, the request timestamp, and the first key in the client parameters and the first interface path using an SDK algorithm. In embodiments, various other possible algorithms may also be used.
For example, the public Key, the first interface path and the current timestamp are put into a HashMap, and the HashMap is serialized into a Jason string, denoted as S, according to the ascending order of keysjson1. Illustratively, { "apiPath1": "first interface path", "publicKey": "public key", "secretekey 1": first secret key "," timestamp ": current timestamp" }.
Then, the S of the previous step is addedjson1Calculating to obtain a character string by using an MD5 algorithm, and marking as Stoken1And serves as a first signature verification voucher.
And step 260, in response to that the first signature verification certificate is equal to the second signature verification certificate, determining that the service interface request sent by the client is legal.
And 270, sending feedback information to the client based on the signature checking result.
In an embodiment, the server sends feedback information of 'signature error' to the client in response to the absence of the client parameter corresponding to the public key in the database.
In an embodiment, the server sends feedback information of 'illegal IP address' to the client in response to the client IP address not being a white list IP address.
In the embodiment, the server sends feedback information of 'signature expired' to the client in response to the fact that the signature verification effective duration is larger than the preset signature verification effective duration.
In an embodiment, the server sends feedback information of 'signature error' to the client in response to the first signature verification certificate and the second signature verification certificate being not equal.
The embodiment in the specification improves the communication security of the server side through an irreversible encryption mode. And by the incomplete asymmetric encryption mode, the encryption mode can be conveniently and directly implanted into the server side. The method is transparent to service development, facilitates the algorithm and reduces the coupling degree.
Fig. 3 is an exemplary flow chart of a method for interface signature verification at a client, denoted as flow 300. As shown in fig. 3, the process 300 includes one or more of the following steps. In an embodiment, the process 300 may be performed by the system 500.
In step 310, the client issues a registration request to the server, so that the server distributes a public key and a secret key. The public key and the secret key are used for sending a service interface request to the server. For details of the registration application, refer to fig. 1 and its related description.
In step 320, the client receives the public key and the secret key distributed by the server.
And step 330, the client configures a white list IP address and/or preset signature verification effective duration at the server. For specific contents of configuring the white list IP address and the preset signature verification valid duration, refer to fig. 1 and its related description.
In step 340, the client sends a synchronous clock request to the server to obtain a current timestamp returned by the server, and calculates a clock difference value based on the current timestamp.
In an embodiment, the client may send a synchronous clock request to the server periodically. In another embodiment, the client may send a synchronous clock request to the server before making a traffic interface request. For details of the synchronous clock request, refer to fig. 1 and its associated description.
For the details of the current timestamp, refer to fig. 1 and its associated description.
In an embodiment, the client may determine a clock difference value based on the current timestamp of the server and the local clock of the client. For example, the difference between the current timestamp and the local clock of the client is taken as the clock difference SD。
In step 350, the client generates a second signature verification certificate based on the public key, the second interface path and/or the request timestamp.
The second key (secretekey 2) may refer to a key provided locally by the client. For example, the server side is the key distributed by the client side.
The second interface path (apiPath 2) may refer to an interface path recorded locally by the client for communication with the server. For example, the server allocates an interface address for the client to transmit information.
For details of the request timestamp, refer to fig. 1 and its associated description.
The second signing certificate may refer to a signing certificate generated locally by the client. For example, the client utilizes a signature verification credential generated by an encryption algorithm based on the public key, the second interface path, and the request timestamp.
In an embodiment, the encryption algorithm may be an SDK encryption algorithm. For example, the public Key, the second interface path and the request timestamp are put into the HashMap at a time, and the HashMap is serialized into a Json string, denoted as Sjson2, according to the ascending ordering of keys. Illustratively, { "apiPath2": "second interface path", "publicKey": "public key", "secretekey 2": "second secret key", "timestamp": "current timestamp" }.
S of the previous stepjson2Calculating to obtain a character string by using an MD5 algorithm, and marking as Stoken2And serves as a second signature verification voucher.
And step 360, the client generates signature verification information based on the public key, the request timestamp and/or the second signature verification certificate, and sends a service interface request to the server based on the signature verification information.
In an embodiment, the client may add the public key, the request timestamp, and the second signing credential to the header as the signing information.
In an embodiment, the client may send the check-sign information to the server to implement the service interface request.
In step 370, the client receives the feedback information sent by the server.
For the details of the feedback information, refer to fig. 1 and its related description.
In embodiments, the feedback information received by the client may include one or more of "signature error", "IP address is illegal", "signature expired", "request is legitimate", and the like.
In an embodiment, the client may further continue to communicate with the server based on the received feedback information.
The embodiment in the specification improves the communication security of the client through an irreversible encryption mode. And by the incomplete asymmetric encryption mode, the encryption mode can be conveniently and directly implanted into the client. The method is transparent to service development, facilitates the algorithm and reduces the coupling degree.
Fig. 4 is an exemplary block diagram of a system for interface verification at a server, denoted as system 400. As shown in fig. 4, the system 400 includes one or more of the following modules.
And the registration management module is used for receiving a registration application of the client by the server, distributing a public key and a secret key to the client, receiving a white list IP address and/or preset signature verification effective duration configured by the client, storing client parameters and the like. For more contents of receiving a registration application of a client, allocating a public key and a secret key to the client, receiving a white list IP address and/or a preset signature verification valid duration configured by the client, and storing a client parameter, refer to fig. 1 and related description thereof.
And the synchronous clock request receiving module is used for receiving the synchronous clock request sent by the client side by the server side and returning the current timestamp of the server side. For specific contents of receiving a synchronous clock request sent by a client and returning a current timestamp of a server, refer to fig. 1 and its related description.
And the service interface request receiving module is used for receiving the service interface request sent by the client by the server and analyzing the signature verification information in the service interface request, wherein the signature verification information comprises a public key, a request timestamp and/or a second signature verification certificate. With respect to receiving a service interface request sent by a client, and analyzing specific content of the signature verification information in the service interface request, refer to fig. 1 and its related description.
And the judging module is used for determining whether the client request is legal or not by the server based on the signature checking information and the client parameters. For specific content that determines whether the client request is legitimate based on the signature verification information and the client parameters, refer to fig. 1 and its associated description.
In an embodiment, the determination module may include one or more of an identity authentication unit, a white list verification unit, a timestamp verification unit, a signature verification credential verification unit, and the like.
And the identity authentication unit is used for the server side to inquire whether the client side parameters are stored in the database or not based on the public key. For the specific content of the client parameter stored in the database based on the public key query, refer to fig. 2 and its related description.
And the white list checking unit is used for comparing the client IP address with the white list IP address in the client parameter by the server. For specific contents of comparing the client IP address with the white list IP address in the client parameter, refer to fig. 2 and its related description.
And the timestamp checking unit is used for judging whether the effective signature checking duration is less than the preset effective signature checking duration in the client parameters by the server. For specific contents of determining whether the signature verification valid duration is smaller than the preset signature verification valid duration in the client parameter, refer to fig. 2 and related description thereof.
And the verification unit of the signature verification certificate is used for generating the first signature verification certificate by the server side and comparing the first signature verification certificate with the second signature verification certificate. For details of generating the first signature verification certificate and comparing the first signature verification certificate with the second signature verification certificate, refer to fig. 2 and its related description.
And the feedback information sending module is used for sending the feedback information to the client by the server based on the signature verification result. For specific content of sending feedback information to the client based on the result of the signature verification, refer to fig. 2 and its related description.
Fig. 5 is an exemplary block diagram of a system for interface verification at a client, denoted as system 500. As shown in fig. 5, the system 500 includes one or more of the following modules.
And the synchronous clock request sending module is used for sending a synchronous clock request to the server by the client so as to obtain the current timestamp returned by the server and calculate the clock difference value based on the current timestamp. For sending a synchronous clock request to the server to obtain the current timestamp returned by the server, and calculating the specific content of the clock difference value based on the current timestamp, refer to fig. 3 and its related description.
And the second signature verification certificate generation module is used for generating a second signature verification certificate by the client based on the public key, the second secret key, the second interface path and/or the request timestamp. For details regarding generating the second signature verification credential based on the public key, the second interface path, and/or the request timestamp, see fig. 3 and its associated description.
And the service interface request sending module is used for generating the signature verification information by the client based on the public key, the request timestamp and/or the second signature verification certificate and sending a service interface request to the server based on the signature verification information. For generating the signature verification information based on the public key, the request timestamp, and/or the second signature verification certificate, and sending the specific content of the service interface request to the server based on the signature verification information, refer to fig. 3 and its related description.
And the feedback information receiving module is used for the client side to receive the feedback information sent by the server side. For specific content of the feedback information sent by the receiving server, refer to fig. 3 and its related description.
It should be understood that the embodiments described herein are merely illustrative of the principles of embodiments of this disclosure. Other variations are also possible within the scope of the present description. Thus, by way of example, and not limitation, alternative configurations of the embodiments of the specification can be considered consistent with the teachings of the specification. Accordingly, the embodiments of the present description are not limited to only those embodiments explicitly described and depicted herein.
Claims (10)
1. A method of interface signature verification, the method comprising:
the server receives a synchronous clock request sent by the client and returns a current timestamp of the server;
the server receives a service interface request sent by the client and analyzes the signature verification information in the service interface request, wherein the signature verification information comprises a public key, a request timestamp and/or a second signature verification certificate;
and the server determines whether the client request is legal or not based on the signature verification information and the client parameters.
2. The method of interface signature verification of claim 1, further comprising:
the client sends a synchronous clock request to the server to obtain a current timestamp returned by the server, and a clock difference value is calculated based on the current timestamp;
the client generates a second signature verification certificate based on the public key, the second secret key, the second interface path and/or the request timestamp;
the client generates signature verification information based on the public key, the request timestamp and/or the second signature verification certificate, and sends a service interface request to the server based on the signature verification information;
and the client receives the feedback information sent by the server.
3. The method of interface signature verification of claim 1, further comprising:
the server receives a registration application of the client;
the server distributes a secret key and a public key for the client;
the server receives a white list IP address and/or preset signature verification effective duration configured by the client;
and the server stores the client parameters, wherein the client parameters comprise a public key, a secret key, a white list IP address and/or preset signature verification effective duration.
4. The method for interface signature verification according to claim 1, wherein parsing signature verification information in the service interface request comprises:
the server analyzes the IP address of the client sending the service interface request;
the server side obtains a first interface path requested by the client side;
and the server side acquires the public key, the request timestamp and the second signature verification certificate.
5. The method of interface signature verification according to claim 4, wherein determining whether the client request is legitimate based on the signature verification information and the client parameters comprises:
the server side inquires client side parameters stored in a database based on the public key;
the server responds to the existence of client parameters corresponding to the public key in the database, and compares the client IP address with a white list IP address in the client parameters;
the server side responds to the fact that the IP address of the client side is a white list IP address, and whether the effective signature checking duration is smaller than the preset effective signature checking duration in the client side parameters or not is judged;
the server side responds to the fact that the signature verification effective duration is smaller than the preset signature verification effective duration, and generates a first signature verification certificate based on the public key, a first secret key, a first interface path and/or a request timestamp, wherein the first secret key is a secret key obtained from the client side parameters;
the server compares the first signature verification certificate with the second signature verification certificate;
and determining that the service interface request sent by the client is legal in response to the first signature verification certificate being equal to the second signature verification certificate.
6. The interface signature verification method of claim 5, further comprising the step of sending feedback information to the client by the server based on the signature verification result; the feedback information includes:
the server side responds to the fact that client side parameters corresponding to the public key do not exist in the database, and sends feedback information of 'signature error' to the client side;
the server side responds to that the IP address of the client side is not the white list IP address, and sends 'illegal IP address' feedback information to the client side;
the server side responds to the fact that the signature verification effective duration is larger than the preset signature verification effective duration, and sends feedback information of 'signature expired' to the client side;
and the server side responds to the fact that the first signature verification certificate is not equal to the second signature verification certificate, and sends feedback information of 'signature error' to the client side.
7. The method of interface signature verification of claim 2, further comprising:
the client side puts forward a registration application to the server side so that the server side can distribute a public key and a secret key;
the client receives a public key and a secret key distributed by the server;
the client configures a white list IP address and/or preset signature verification effective duration at the server.
8. The method for interface signature verification according to claim 2, wherein the feedback information comprises "signature error", "IP address illegal", "signature expired" or "request legal".
9. A system for interface signature verification, comprising:
the synchronous clock request receiving module is used for receiving a synchronous clock request sent by the client side by the server side and returning a current timestamp of the server side;
the service interface request receiving module is used for receiving a service interface request sent by the client side by the server side and analyzing the signature verification information in the service interface request, wherein the signature verification information comprises a public key, a request timestamp and/or a second signature verification certificate;
and the server side is used for determining whether the client side request is legal or not based on the signature checking information and the client side parameters.
10. The interface tag verification system of claim 9, further comprising:
the synchronous clock request sending module is used for sending a synchronous clock request to the server by the client so as to obtain a current timestamp returned by the server and calculate a clock difference value based on the current timestamp;
the second signature verification certificate generation module is used for generating a second signature verification certificate by the client based on the public key, the second secret key, the second interface path and/or the request timestamp;
the service interface request sending module is used for the client side to generate signature verification information based on the public key, the request timestamp and/or the second signature verification certificate and send a service interface request to the server side based on the signature verification information;
and the feedback information receiving module is used for the client side to receive the feedback information sent by the server side.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202111556845.5A CN113938328A (en) | 2021-12-18 | 2021-12-18 | Interface label checking method and system |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202111556845.5A CN113938328A (en) | 2021-12-18 | 2021-12-18 | Interface label checking method and system |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| CN113938328A true CN113938328A (en) | 2022-01-14 |
Family
ID=79289344
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN202111556845.5A Pending CN113938328A (en) | 2021-12-18 | 2021-12-18 | Interface label checking method and system |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN113938328A (en) |
Cited By (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN114553416A (en) * | 2022-03-18 | 2022-05-27 | 北京友普信息技术有限公司 | Data encryption processing method for signature verification of application program interface |
Citations (8)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN104935568A (en) * | 2015-04-20 | 2015-09-23 | 成都康赛信息技术有限公司 | Interface authentication signature method facing cloud platform |
| CN107135073A (en) * | 2016-02-26 | 2017-09-05 | 北京京东尚科信息技术有限公司 | Interface interchange method and apparatus |
| CN108432180A (en) * | 2015-11-13 | 2018-08-21 | 维萨国际服务协会 | Method and system for the certification based on PKI |
| CN109150503A (en) * | 2018-11-22 | 2019-01-04 | 江苏方天电力技术有限公司 | Authentication method in Electric Power Marketing System interface calling based on RSA Algorithm |
| CN109542637A (en) * | 2018-10-26 | 2019-03-29 | 深圳点猫科技有限公司 | A kind of interface of educational system calls and parameter tamper resistant method and electronic equipment |
| CN110855624A (en) * | 2019-10-18 | 2020-02-28 | 平安科技（深圳）有限公司 | Safety verification method based on web interface and related equipment |
| CN111277418A (en) * | 2020-02-17 | 2020-06-12 | 福建天晴在线互动科技有限公司 | Method for realizing safety of Api interface |
| CN111814136A (en) * | 2020-06-30 | 2020-10-23 | 中国信息通信研究院 | Android application signature and signature verification method and device, and signature verification system |
-
2021
- 2021-12-18 CN CN202111556845.5A patent/CN113938328A/en active Pending
Patent Citations (8)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN104935568A (en) * | 2015-04-20 | 2015-09-23 | 成都康赛信息技术有限公司 | Interface authentication signature method facing cloud platform |
| CN108432180A (en) * | 2015-11-13 | 2018-08-21 | 维萨国际服务协会 | Method and system for the certification based on PKI |
| CN107135073A (en) * | 2016-02-26 | 2017-09-05 | 北京京东尚科信息技术有限公司 | Interface interchange method and apparatus |
| CN109542637A (en) * | 2018-10-26 | 2019-03-29 | 深圳点猫科技有限公司 | A kind of interface of educational system calls and parameter tamper resistant method and electronic equipment |
| CN109150503A (en) * | 2018-11-22 | 2019-01-04 | 江苏方天电力技术有限公司 | Authentication method in Electric Power Marketing System interface calling based on RSA Algorithm |
| CN110855624A (en) * | 2019-10-18 | 2020-02-28 | 平安科技（深圳）有限公司 | Safety verification method based on web interface and related equipment |
| CN111277418A (en) * | 2020-02-17 | 2020-06-12 | 福建天晴在线互动科技有限公司 | Method for realizing safety of Api interface |
| CN111814136A (en) * | 2020-06-30 | 2020-10-23 | 中国信息通信研究院 | Android application signature and signature verification method and device, and signature verification system |
Non-Patent Citations (3)
| Title |
|---|
| 佚名: "API接口验签", 《HTTPS://BLOG.CSDN.NET/JACK1LIU/ARTICLE/DETAILS/93379328》 * |
| 佚名: "微信公众平台宣布增加接口IP白名单提高安全性", 《HTTPS://WWW.CNBLOGS.COM/LXWPHP/P/7943536.HTML》 * |
| 黄杰: "《信息系统安全》", 30 November 2019 * |
Cited By (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN114553416A (en) * | 2022-03-18 | 2022-05-27 | 北京友普信息技术有限公司 | Data encryption processing method for signature verification of application program interface |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US10642969B2 (en) | Automating internet of things security provisioning | |
| CN110168971B (en) | Method, computer-readable medium, system, and vehicle for validating a function of time | |
| CN101547095B (en) | Application service management system and management method based on digital certificate | |
| CN104184713B (en) | Terminal identification method, machine identifier register method and corresponding system, equipment | |
| US20090144541A1 (en) | Method and apparatus of mutual authentication and key distribution for downloadable conditional access system in digital cable broadcasting network | |
| US20100154040A1 (en) | Method, apparatus and system for distributed delegation and verification | |
| CN111131416B (en) | Service providing method and device, storage medium and electronic device | |
| US8261336B2 (en) | System and method for making accessible a set of services to users | |
| JP2003521154A (en) | How to issue electronic identification information | |
| JP2007510391A (en) | User validity check method for checking user validity | |
| CN101540757A (en) | Method and system for identifying network and identification equipment | |
| CN110740038B (en) | Blockchain and communication method, gateway, communication system and storage medium thereof | |
| CN111080299B (en) | Anti-repudiation method for transaction information, client and server | |
| CN103475624A (en) | Internet of Things key management center system, key distribution system and method | |
| WO2023124958A1 (en) | Key update method, server, client and storage medium | |
| CN114338242A (en) | Cross-domain single sign-on access method and system based on block chain technology | |
| CN113938328A (en) | Interface label checking method and system | |
| CN107888615B (en) | Safety authentication method for node registration | |
| CN101345723A (en) | Management authentication method and system of client gateway | |
| CN114157693A (en) | Power-on authentication method of communication equipment, communication module and server | |
| KR101803535B1 (en) | Single Sign-On Service Authentication Method Using One-Time-Token | |
| CN113505353A (en) | Authentication method, device, equipment and storage medium | |
| US20230291574A1 (en) | Method for securely equipping a vehicle with an individual certificate | |
| US20210195418A1 (en) | A technique for authenticating data transmitted over a cellular network | |
| CN114679269B (en) | Block chain-based credential transmission method and device, electronic equipment and storage medium |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| PB01 | Publication | ||
| PB01 | Publication | ||
| SE01 | Entry into force of request for substantive examination | ||
| SE01 | Entry into force of request for substantive examination | ||
| RJ01 | Rejection of invention patent application after publication | ||
| RJ01 | Rejection of invention patent application after publication |
Application publication date: 20220114 |