CN111277418B - Method for realizing Api interface security - Google Patents
Method for realizing Api interface security Download PDFInfo
- Publication number
- CN111277418B CN111277418B CN202010097133.0A CN202010097133A CN111277418B CN 111277418 B CN111277418 B CN 111277418B CN 202010097133 A CN202010097133 A CN 202010097133A CN 111277418 B CN111277418 B CN 111277418B
- Authority
- CN
- China
- Prior art keywords
- request
- interface
- token
- application code
- appid
- 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.)
- Active
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/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
- H04L9/3213—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 using tickets or tokens, e.g. Kerberos
-
- 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
- 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/0876—Network architectures or network communication protocols for network security for authentication of entities based on the identity of the terminal or configuration, e.g. MAC address, hardware or software configuration or device fingerprint
-
- 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/10—Network architectures or network communication protocols for network security for controlling access to devices or network resources
- H04L63/108—Network architectures or network communication protocols for network security for controlling access to devices or network resources when the policy decisions are valid for a limited amount of time
-
- 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
- H04L63/0435—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 wherein the sending and receiving network entities apply symmetric encryption, i.e. same key used for encryption and decryption
-
- 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/3236—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 using cryptographic hash functions
- H04L9/3239—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 using cryptographic hash functions involving non-keyed hash functions, e.g. modification detection codes [MDCs], MD5, SHA or RIPEMD
-
- 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/3247—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 digital signatures
-
- 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)
- Power Engineering (AREA)
- Storage Device Security (AREA)
Abstract
The invention provides a method for realizing the security of an Api interface, which comprises the following steps: step 1: the system application with the Api interface in the access direction; step 2: after obtaining an application code AppID and an application key AppSercet of an application, an access party starts to organize a request to a system interface; step 3: the system returns the data information to be returned to the access party after carrying out Des encryption on the content key DesSecret returned by the interface corresponding to the application code AppID according to the service interface request; step 4: after obtaining the returned content of the request interface, the access side uses the interface returned content key DesSecret distributed by the system to decrypt Des, and the returned content is obtained. The invention effectively ensures the safety of the interface.
Description
Technical Field
The invention relates to the technical field of network communication, in particular to a method for realizing the security of an Api interface.
Background
Today, various Api interfaces are endless, such as interface calls between different teams inside a company, functional interfaces for opposite users, third party service interfaces, etc. A good Api has many dimensions to measure, where security and simplicity are the most basic and important two dimensions of an Api interface, but often these 2 dimensions are paradox, the more complex the design, the higher the security, but for an access party, it is a laborious event, it is too difficult to access and not easy to understand, and many intolerable communication costs are generated. The design is too simple and not feasible, the interface has the risk of being tampered and invoked, and the security of the interface is directly influenced by Api recharging, prize issuing, sensitive data and the like. It is important to design a good Api interface that is both simple and secure.
Disclosure of Invention
In order to overcome the problems, the invention aims to provide a method for realizing the safety of the Api interface, which can effectively ensure the safety of the interface.
The invention is realized by adopting the following scheme: a method of implementing Api interface security, the method comprising the steps of:
step 1: the system application with the Api interface in the access direction;
step 2: after obtaining an application code AppID and an application key AppSercet of an application, an access party starts to organize a request to a system interface; the step 2 specifically comprises the following steps:
step 2.1: the access party requests to acquire a Token interface to acquire a Token;
step 2.2: after obtaining Token, the access party has the right to request a service interface with specific function from the system, and obtains the parameters required by the service interface and the signature rules to organize the service signature SdkSign;
step 2.3: requesting a service interface according to the Token and the service signature SdkSign, and adding parameters required by the service interface;
step 3: the system returns the data information to be returned to the access party after carrying out Des encryption on the content key DesSecret returned by the interface corresponding to the application code AppID according to the service interface request;
step 4: after obtaining the returned content of the request interface, the access side uses the interface returned content key DesSecret distributed by the system to decrypt Des, and the returned content is obtained.
Further, the step 2.1 is further specifically: the access party transmits an application code AppID, a current timestamp Ticket and a Sign request to acquire a token interface, wherein the Sign is a value obtained by performing MD5 encryption by splicing 3 parameters of AppID+Ticket+AppSercet; the Token is valid for a preset time, that is, the Token is not required to be repeatedly requested for the preset time, and the Token is considered valid.
Further, the step 2.1 further includes the following steps:
step 2.1.1: after receiving the request of the step 2, the system firstly obtains a corresponding application key AppSercet according to an application code AppID and checks whether the Sign signature is legal and effective;
step 2.1.2: secondly, the system checks whether the Ticket is within a time threshold range of server errors, and the out-of-range is regarded as an expiration request;
step 2.1.3: finally, the system checks whether the request IP is in an IP white list allowed by an application code AppID;
step 2.1.4: if all the steps 2.1.1 to 2.1.3 are legal, the system organization token value is returned to the access party; the Token is a Json string consisting of an application code AppID, an expiration time ExpireTime, and a random string, and is encrypted by the DES of the system to obtain a value, which is stored in the Redis cache for verifying validity before being returned to the access party.
Further, the signature rule organizes a service signature SdkSign specifically as follows: according to the unified signature rule, the parameters required by the service interface are sequenced from small to large according to the parameter names ASCII, the parameters required by the service interface are combined together to obtain text1, the text1 is converted into small text to obtain text2, and the text2+AppSecret is subjected to MD5 encryption to obtain a 32-bit MD5 value, namely SdkSign.
Further, the step 2.3 further includes the following steps:
step 2.3.1: after receiving the service interface request, the system firstly decrypts the Token and analyzes the contained application code AppID information, and if the analysis fails, the system is regarded as an illegal request;
step 2.3.2: after analyzing the application code AppID, obtaining a Redis cache key according to the application code AppID, reading a Token, checking whether the Token exists or not, and if not, considering the Token as an illegal request;
step 2.3.3: acquiring AppSercet according to the resolved application code AppID, organizing a signature according to a signature rule, and comparing whether SdkSign is legal or not;
step 2.3.4: checking whether the request IP is in an IP white list allowed by an application code AppID;
step 2.3.5: judging whether the system has excessive requests in the current hour, namely running a planning task by the system, counting the request amount of each application interface system in the current hour every 5 minutes, and storing the request amount in a Redis cache if the request amount is larger than a maximum request frequency threshold value, wherein the request amount represents that the request amount is excessive;
step 2.3.6: if all the steps 2.3.1 to 2.3.5 are passed, the request is legal, and the step 3 is entered; otherwise, the flow is ended for illegal request.
The invention has the beneficial effects that: 1. the access is simple and convenient: providing unified signature rules and multi-language universal encryption rules; 2. interface security: the account token, the service parameter signature, the IP limit, the interface authority, the interface request limit, the return information encryption and the like are used for protecting the interface security.
Drawings
FIG. 1 is a schematic flow chart of the method of the present invention.
FIG. 2 is a block diagram of a method embodiment of the present invention.
Detailed Description
The invention is further described below with reference to the accompanying drawings.
Referring to fig. 1, a method for implementing Api interface security according to the present invention includes the following steps:
step 1: the system application with the Api interface in the access direction;
step 2: after obtaining an application code AppID and an application key AppSercet of an application, an access party starts to organize a request to a system interface; the step 2 specifically comprises the following steps:
step 2.1: the access party requests to acquire a Token interface to acquire a Token; the step 2.1 is further specifically as follows: the access party transmits an application code AppID, a current timestamp Ticket and a Sign request to acquire a token interface, wherein the Sign is a value obtained by performing MD5 encryption by splicing 3 parameters of AppID+Ticket+AppSercet; the Token is valid for a preset time, that is, the Token is not required to be repeatedly requested for the preset time, and the Token is considered valid.
Step 2.2: after obtaining Token, the access party has the right to request a service interface with specific function from the system, and obtains the parameters required by the service interface and the signature rules to organize the service signature SdkSign; the signature rule organizes a service signature SdkSign specifically as follows: according to the unified signature rule, the parameters required by the service interface are sequenced from small to large according to the parameter names ASCII, the parameters required by the service interface are combined together to obtain text1, the text1 is converted into small text to obtain text2, and the text2+AppSecret is subjected to MD5 encryption to obtain a 32-bit MD5 value, namely SdkSign.
Step 2.3: requesting a service interface according to the Token and the service signature SdkSign, and adding parameters required by the service interface;
step 3: the system returns the data information to be returned to the access party after carrying out Des encryption on the content key DesSecret returned by the interface corresponding to the application code AppID according to the service interface request;
step 4: after obtaining the returned content of the request interface, the access side uses the interface returned content key DesSecret distributed by the system to decrypt Des, and the returned content is obtained.
Wherein, the step 2.1 further comprises the following steps:
step 2.1.1: after receiving the request of the step 2, the system firstly obtains a corresponding application key AppSercet according to an application code AppID and checks whether the Sign signature is legal and effective;
step 2.1.2: secondly, the system checks whether the Ticket is within a time threshold range of server errors, and the out-of-range is regarded as an expiration request;
step 2.1.3: finally, the system checks whether the request IP is in an IP white list allowed by an application code AppID;
step 2.1.4: if all the steps 2.1.1 to 2.1.3 are legal, the system organization token value is returned to the access party; the Token is a Json string consisting of an application code AppID, an expiration time ExpireTime, and a random string, and is encrypted by the DES of the system to obtain a value, which is stored in the Redis cache for verifying validity before being returned to the access party.
Further, the step 2.3 further includes the following steps:
step 2.3.1: after receiving the service interface request, the system firstly decrypts the Token and analyzes the contained application code AppID information, and if the analysis fails, the system is regarded as an illegal request;
step 2.3.2: after analyzing the application code AppID, obtaining a Redis cache key according to the application code AppID, reading a Token, checking whether the Token exists or not, and if not, considering the Token as an illegal request;
step 2.3.3: acquiring AppSercet according to the resolved application code AppID, organizing a signature according to a signature rule, and comparing whether SdkSign is legal or not;
step 2.3.4: checking whether the request IP is in an IP white list allowed by an application code AppID;
step 2.3.5: judging whether the system has excessive requests in the current hour, namely running a planning task by the system, counting the request amount of each application interface system in the current hour every 5 minutes, and storing the request amount in a Redis cache if the request amount is larger than a maximum request frequency threshold value, wherein the request amount represents that the request amount is excessive;
step 2.3.6: if all the steps 2.3.1 to 2.3.5 are passed, the request is legal, and the step 3 is entered; otherwise, the flow is ended for illegal request.
The invention is further described with reference to the following specific examples:
as shown in fig. 2, a method for implementing Api interface security according to the present invention includes the following steps:
step 1: the system application with the Api interface in the access direction;
step 1.1: after the system administrator allocates an application, an AppID (application code), an appserset (application key), and a desserset (interface return content key) belonging to the application are provided to the access party, and an interface request frequency is set, the interface request frequency unit: times/hour;
step 2: after the access party obtains the AppID and the AppSercet, the access party can start to organize the request to the system interface; an example AppID is uLJqf20200113, appSercet is TLnkJRtFTVjdTnYBKvTw for use in the following steps as examples.
Step 2.1: the access party first requests a "get Token" interface to get a Token. The access party transmits AppID, ticket, sign a request for 'obtaining token' interface, wherein Ticket is the current timestamp, and Sign is the value obtained by splicing MD5 by AppID+Ticket+AppSercet 3 parameters. The Token has a validity period of 2 hours, and the Token does not need to be repeatedly requested within 2 hours, and is considered valid.
Step 2.1.1: after receiving the request of 2.1, the system firstly obtains a corresponding AppSercet according to the AppID and checks whether the Sign signature is legal and effective;
step 2.1.2: the system then checks if the Ticket is within 5 minutes of the server error, and if it is out of range, it is considered as an expiration request.
Step 2.1.3: and finally, the system checks whether the request IP is in an IP white list allowed by the AppID.
Step 2.1.4: if all 2.1.1 through 2.1.3 are legal, the system organization token value is returned to the access party. Token is a value obtained by encrypting a Json string consisting of AppID, expireTime expiration time and a random string by the DES of the system. This value is stored in the Redis cache for verification of legitimacy before being returned to the access party. An example Redis cache Key is "ApiToken_uLJqf20200113".
Step 2.2: after obtaining Token, the access party will have the right to request the service interface with specific function to the system, and the SdkSign service signature is organized according to the parameters and signature rules required by the actual service interface to request together. For example, a service interface is requested, and parameters required by the interface are as follows: type recharge Type, amountrecharge Amount, body recharge header. According to the unified signature rule, the parameters are ordered from small to large according to the parameter names ASCII, namely, amount+body+type is obtained to obtain text1, text1 is converted into small text to obtain text2, and text 2+AppSecretMD 5 is encrypted to obtain a 32-bit MD5 value, namely SdkSign.
Step 2.3: and requesting the service interface according to the Token obtained in 2.1 and the SdkSign obtained in 2.2, and the parameters required by the service interface.
Step 2.3.1: after receiving the request of 2.3, the system first decrypts the Token and parses out the contained AppID information. If the parsing fails, the illegal request is considered.
Step 2.3.2: after the AppID is analyzed, a Redis cache key ApiToken_uLJqf20200113 is obtained according to the AppID to read the Token, and whether the Token exists or not is checked. If not, an illegal request is considered.
Step 2.3.3: and acquiring AppSercet according to the analyzed AppID, organizing the signature according to the signature rule, and comparing whether SdkSign is legal or not.
Step 2.3.4: and checking whether the request IP is in an IP white list allowed by the AppID, if so, legal requests exist, and if not, illegal requests exist.
Step 2.3.5: judging whether the system has an excessive request in the hour, and adding the AppID and the hour yyyMMddHH of the current time to serve as a cache key, for example, uLJqf20200113_2019011310, reading a Redis cache, and checking whether the period is 1 month 13 and 10 hours is excessive. The system will run a scheduled task, counting once every 5 minutes the requested amount per application interface per hour (i.e. 10 hours period), and if it is greater than the threshold (set maximum requested frequency) storing in dis, representing that it has been exceeded. This step does not check synchronously in real time, since a proper excess is allowed, and the performance of the system can be improved by an asynchronous check mode.
Step 3: if step 2.3.5 passes, then the request is represented as legitimate. The system encrypts the data information to be returned by DesSecret corresponding to the AppID and returns the data information to the access party.
Step 4: after obtaining the returned content of the request interface, the access side uses the DesSecret distributed by the system to decrypt the Des to obtain the returned content.
The foregoing description is only of the preferred embodiments of the invention, and all changes and modifications that come within the meaning and range of equivalency of the claims are therefore intended to be embraced therein.
Claims (2)
1. A method for implementing Api interface security, characterized by: the method comprises the following steps:
step 1: the system application with the Api interface in the access direction;
step 2: after obtaining an application code AppID and an application key AppSercet of an application, an access party starts to organize a request to a system interface; the step 2 specifically comprises the following steps:
step 2.1: the access party requests to acquire a Token interface to acquire a Token;
the step 2.1 further comprises the steps of:
step 2.1.1: after receiving the request of the step 2, the system firstly obtains a corresponding application key AppSercet according to an application code AppID and checks whether the Sign signature is legal and effective;
step 2.1.2: secondly, the system checks whether the current timestamp Ticket is within a range of a time threshold value of server errors, and the out-of-range timestamp Ticket is regarded as an expiration request;
step 2.1.3: finally, the system checks whether the request IP is in an IP white list allowed by an application code AppID;
step 2.1.4: if all the steps 2.1.1 to 2.1.3 are legal, the system organization token value is returned to the access party; the Token is a Json character string composed of an application code AppID, an expiration time Expirietime and a random character string, and a value obtained by DES encryption of the system is stored in a Redis cache before being returned to an access party for verifying the validity;
the step 2.1 is further specifically as follows: the access party transmits an application code AppID, a current timestamp Ticket and a Sign request to acquire a token interface, wherein the Sign is a value obtained by performing MD5 encryption by splicing 3 parameters of AppID+Ticket+AppSercet; the Token is valid for a preset time, namely the Token is not required to be repeatedly requested in the preset time, and the Token is considered valid;
step 2.2: after obtaining Token, the access party has the right to request a service interface with specific function from the system, and obtains the parameters required by the service interface and the signature rules to organize the service signature SdkSign;
step 2.3: requesting a service interface according to the Token and the service signature SdkSign, and adding parameters required by the service interface;
the step 2.3 further comprises the steps of:
step 2.3.1: after receiving the service interface request, the system firstly decrypts the Token and analyzes the contained application code AppID information, and if the analysis fails, the system is regarded as an illegal request;
step 2.3.2: after analyzing the application code AppID, obtaining a Redis cache key according to the application code AppID, reading a Token, checking whether the Token exists or not, and if not, considering the Token as an illegal request;
step 2.3.3: acquiring AppSercet according to the resolved application code AppID, organizing a signature according to a signature rule, and comparing whether SdkSign is legal or not;
step 2.3.4: checking whether the request IP is in an IP white list allowed by an application code AppID;
step 2.3.5: judging whether the system has excessive requests in the current hour, namely running a planning task by the system, counting the request amount of each application interface system in the current hour every 5 minutes, and storing the request amount in a Redis cache if the request amount is larger than a maximum request frequency threshold value, wherein the request amount represents that the request amount is excessive;
step 2.3.6: if all the steps 2.3.1 to 2.3.5 are passed, the request is legal, and the step 3 is entered; otherwise, the flow is ended for illegal request;
step 3: the system returns the data information to be returned to the access party after carrying out Des encryption on the content key DesSecret returned by the interface corresponding to the application code AppID according to the service interface request;
step 4: after obtaining the returned content of the request interface, the access side uses the interface returned content key DesSecret distributed by the system to decrypt Des, and the returned content is obtained.
2. The method for implementing Api interface security of claim 1, wherein: the signature rule organizes a service signature SdkSign specifically as follows: according to the unified signature rule, the parameters required by the service interface are sequenced from small to large according to the parameter names ASCII, the parameters required by the service interface are combined together to obtain text1, the text1 is converted into small text to obtain text2, and the text2+AppSecret is subjected to MD5 encryption to obtain a 32-bit MD5 value, namely SdkSign.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202010097133.0A CN111277418B (en) | 2020-02-17 | 2020-02-17 | Method for realizing Api interface security |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202010097133.0A CN111277418B (en) | 2020-02-17 | 2020-02-17 | Method for realizing Api interface security |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| CN111277418A CN111277418A (en) | 2020-06-12 |
| CN111277418B true CN111277418B (en) | 2023-05-12 |
Family
ID=71003601
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN202010097133.0A Active CN111277418B (en) | 2020-02-17 | 2020-02-17 | Method for realizing Api interface security |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN111277418B (en) |
Families Citing this family (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN111897721B (en) * | 2020-07-14 | 2024-04-30 | 重庆长安汽车股份有限公司 | Automatic testing method of API (application program interface) and storage medium |
| CN111931159B (en) * | 2020-08-11 | 2023-04-07 | 福建天晴在线互动科技有限公司 | Method and system for verifying validity of webpage data interface |
| CN113938328A (en) * | 2021-12-18 | 2022-01-14 | 中建电子商务有限责任公司 | Interface label checking method and system |
Citations (4)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN107135073A (en) * | 2016-02-26 | 2017-09-05 | 北京京东尚科信息技术有限公司 | Interface interchange method and apparatus |
| CN107705088A (en) * | 2017-09-15 | 2018-02-16 | 深圳前海微众银行股份有限公司 | Method for processing business, open platform and computer-readable recording medium |
| CN108183907A (en) * | 2017-12-29 | 2018-06-19 | 浪潮通用软件有限公司 | A kind of authentication method, server and Verification System |
| CN110071806A (en) * | 2019-03-13 | 2019-07-30 | 平安科技（深圳）有限公司 | The method and system of data processing based on interface check |
Family Cites Families (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US10044701B2 (en) * | 2016-05-24 | 2018-08-07 | Vantiv, Llc | Technologies for token-based authentication and authorization of distributed computing resources |
-
2020
- 2020-02-17 CN CN202010097133.0A patent/CN111277418B/en active Active
Patent Citations (4)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN107135073A (en) * | 2016-02-26 | 2017-09-05 | 北京京东尚科信息技术有限公司 | Interface interchange method and apparatus |
| CN107705088A (en) * | 2017-09-15 | 2018-02-16 | 深圳前海微众银行股份有限公司 | Method for processing business, open platform and computer-readable recording medium |
| CN108183907A (en) * | 2017-12-29 | 2018-06-19 | 浪潮通用软件有限公司 | A kind of authentication method, server and Verification System |
| CN110071806A (en) * | 2019-03-13 | 2019-07-30 | 平安科技（深圳）有限公司 | The method and system of data processing based on interface check |
Also Published As
| Publication number | Publication date |
|---|---|
| CN111277418A (en) | 2020-06-12 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CN112333198B (en) | Secure cross-domain login method, system and server | |
| CN111277418B (en) | Method for realizing Api interface security | |
| US7058971B1 (en) | Access privilege transferring method | |
| US20070136202A1 (en) | Personal-information managing apparatus, method of providing personal information, computer product, and personal-information-providing system | |
| US20130004027A1 (en) | Checking revocation status of a biometric reference template | |
| EP1241826A2 (en) | Cryptographic key management method | |
| JP5160205B2 (en) | Method and system for file transfer management | |
| US20080294896A1 (en) | Method and System for Transmitting and Receiving User's Personal Information Using Agent | |
| CN105978855B (en) | Personal information safety protection system and method under a kind of system of real name | |
| EP1227613A2 (en) | Method and apparatus for attaching electronic signature to document having structure | |
| CN112699353B (en) | Financial information transmission method and financial information transmission system | |
| CN109242481A (en) | Information approach, device and computer equipment are pledged based on block chain query | |
| CN114372276A (en) | Data security protection method and device, electronic equipment and storage medium | |
| CN111814136A (en) | Android application signature and signature verification method and device, and signature verification system | |
| CN109992976A (en) | Access credentials verification method, device, computer equipment and storage medium | |
| JPWO2008096783A1 (en) | Personal information management device for preventing falsification of personal information and denial of distribution of personal information | |
| CN117056899A (en) | Electronic certificate generation method and device | |
| CN110493011B (en) | Block chain-based certificate issuing management method and device | |
| US20040250071A1 (en) | Electronic data storage system and method thereof | |
| CN109697368B (en) | Method, device and system for safe use of user information data and storage medium | |
| KR100609701B1 (en) | An transaction certification method and system to protect privacy on electronic transaction details | |
| CN117113392A (en) | Private data processing method, device, computer equipment and storage medium | |
| CN116361833A (en) | Verification method and device and terminal equipment | |
| KR100837754B1 (en) | Apparatus for Time and Contents Stamping for Electronic Notes and Method Thereof | |
| CN109948362B (en) | Data access processing method and system |
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 | ||
| GR01 | Patent grant | ||
| GR01 | Patent grant |