Method and device for calling API (Application Program Interface)

Abstract

The embodiment of the invention discloses a method and device for calling an API (Application Program Interface), and the method comprises the following steps: receiving an API calling request from a requester, and carrying out the identity verification of the requester; under the condition that the identity verification is passed, issuing and generating a calling pass for the API calling request, and forwarding the API calling request containing the calling pass to a requested party; and receiving a verification request from the requested party, verifying the calling pass in the verification request, and returning a verification result to the requested party, so that the requested party executes API service logic or refuses to provide service according to the verification result. According to the embodiment of the invention, the method achieves the effective management of the API call request through the verification of the identity of the requester and the verification of the call pass, enables the API to be safely authorized and accessed, and resists the unauthorized illegal access.

Description

Technical Field

[0001] The present application relates to the field of computer technology, and specifically to a method and device for calling an API. Background Art

[0002] In a microservices architecture, backend microservices are registered with a central registry. Based on service discovery, microservices directly call each other's APIs through the Feign component, a common practice that is relatively easy to implement. However, these direct calling relationships between backend microservices create a dense, spider-web-like network of inter-service calling relationships within the entire SaaS system, making it difficult to distinguish boundaries, clearly define distribution domains, and deny access. Furthermore, a SaaS system comprised entirely of microservices with direct calling relationships between them faces numerous challenges in ongoing operations and upgrades. Before upgrading or changing the specification of an API interface, how can one identify the affected callers? Which microservices are currently calling an API interface? Business security requires preventing API interfaces from being abused. These questions and tasks remain difficult to answer accurately or to implement precise measures.

[0003] Currently, some technology platform-like shared-center microservices provide APIs whose execution results can significantly impact the behavior of the entire SaaS system. These include APIs for adding and deleting scheduled tasks, adjusting tax rate configuration values, adding invoice return recipients, adding and updating organizations, and returning business summary data. These important APIs are generally only accessible to one or a few specific microservices responsible for management. However, because the entire SaaS system is deployed within the company's intranet, backend microservices are trusted by default. Important API providers are unable to detect and effectively reject unexpected, unverified misrouting that could have adverse effects, unexpected high-frequency or large-scale calls that could negatively impact the called microservice, and exploratory calls manually initiated using curl tools within the intranet environment.

[0004] Application Contents

[0005] The purpose of the embodiments of the present application is to provide a method and device for calling an API to address the defect that the existing technology cannot effectively manage API calls.

[0006] In order to solve the above technical problems, this application is implemented as follows:

[0007] In a first aspect, a method for calling an API is provided, comprising the following steps:

[0008] Receive an API call request from a requester and verify the identity of the requester;

[0009] If the identity verification is passed, a call pass is issued for the API call request, and the API call request containing the call pass is forwarded to the requested party;

[0010] Receive a verification request from the requested party, verify the call pass in the verification request, and return a verification result to the requested party, so that the requested party executes API business logic or refuses to provide services based on the verification result.

[0011] In a second aspect, a device for calling an API is provided, comprising:

[0012] An identity verification module is used to receive an API call request from a requester and perform identity verification on the requester;

[0013] A generating module, configured to issue a call pass for the API call request if the identity verification passes, and forward the API call request including the call pass to the requested party;

[0014] The verification module is used to receive a verification request from the requested party, verify the call pass in the verification request, and return the verification result to the requested party so that the requested party can execute API business logic or refuse to provide services based on the verification result.

[0015] The embodiment of the present application implements effective management of API call requests by verifying the identity of the requesting party and authenticating the call pass, so that the API is securely authorized for access and unauthorized illegal access is resisted. BRIEF DESCRIPTION OF THE DRAWINGS

[0016] Figure 1 This is a flow chart of a method for calling an API provided in an embodiment of the present application;

[0017] Figure 2 This is a schematic diagram of the architecture of the east-west gateway provided in an embodiment of the present application;

[0018] Figure 3 This is a specific implementation diagram of the method for calling an API provided in an embodiment of the present application;

[0019] Figure 4 This is a specific implementation diagram of generating a call pass provided in an embodiment of the present application;

[0020] Figure 5 This is a schematic diagram of a character arrangement algorithm for calling a pass provided in an embodiment of the present application;

[0021] Figure 6 This is a specific implementation diagram of the verification call pass provided in the embodiment of the present application;

[0022] Figure 7 This is a structural diagram of a device for calling an API provided in an embodiment of the present application. DETAILED DESCRIPTION

[0023] The following will be combined with the drawings in the embodiments of this application to clearly and completely describe the technical solutions in the embodiments of this application. Obviously, the embodiments described are part of the embodiments of this application, not all of them. Based on the embodiments in this application, all other embodiments obtained by ordinary technicians in this field without making creative efforts are within the scope of protection of this application.

[0024] To protect the important APIs of the backend microservices of the SaaS platform, when they are called, it is necessary to verify that the requester has the calling permission and not the mistaken call. There are some implementation methods, some of which verify the permission directly at the requester, some of which verify directly at the destination, some of which verify only at the gateway through the east-west API gateway, and some of which verify only at the called party through the east-west API gateway.

[0025] Among them, the implementation method of the requesting party's microservice directly calling the requested party's important API and performing API callability verification on the requesting party has obvious disadvantages: the verification is actively implemented by the requesting party, and the called party has no participation. The called party cannot identify and block API call requests sent by the requesting party that does not perform verification. There are also two implementation methods for the requesting party's microservice directly calling the requested party's important API and performing API callability verification on the requested party:

[0026] 1. The verification method for the requested party in direct dispatch without the participation of dynamic token issuance and verification has obvious disadvantages: it is impossible to accurately determine whether the identity of the requesting party is the real identity or a tampered identity because there is no token endorsement.

[0027] 2. The requestee verification method for direct dispatch involving dynamic token issuance and verification has significant drawbacks: Token generation is performed by the requester through the authority center, and the requestee then verifies the token with the authority center. While security and legitimacy are guaranteed, direct dispatch limits controllability and reusability. This is reflected in the fact that log queries, monitoring, and alerting for both the requester and the callee require separate aggregation and processing by each microservice, resulting in a lack of a unified view for traffic regulation and increased complexity in operational upgrade management. Furthermore, the authority center typically issues a token only after identity and callability authorization verification. Without information related to the request, token issuance cannot guarantee a one-time token. However, the requestee verification method, which uses an east-west API gateway for call forwarding, offers several advantages. For example, the use of HTTP isolates differences in programming languages ​​and technical architectures. Control measures such as unified logging, monitoring, alerting, and emergency throttling can all be centrally implemented on a single east-west gateway platform. Request traffic passing through the east-west gateway also enables the issuance of a request identifier representing the request, achieving a one-time token.

[0028] Furthermore, the implementation method of verifying API callability only at the gateway via an east-west API gateway has a significant drawback: microservice providers providing important APIs cannot identify and block request traffic that is not forwarded through the east-west gateway. Common implementation methods for forwarding through an east-west API gateway and verifying API callability at the called microservice include the following: These methods offer a certain degree of security and usability, but each has its own advantages and disadvantages that warrant improvement:

[0029] 1. Mutual TLS authentication (mTLS) issues mutually trusted certificates to the east-west gateway and each backend service, configuring each backend service to only accept connections from clients holding a specific certificate. The advantage is network-layer authentication, eliminating the need for application-layer processing. However, the disadvantages are coarse granularity, making it difficult to perform differentiated API callability authorization, rigid certificate configuration affecting all microservices, and certificate configuration and activation requiring manipulation of Nginx configuration files, making it unfriendly for application-layer developers.

[0030] 2. Static API call keys: Configure a fixed public API call key for the east-west gateway, and each backend service verifies the public API call key in the request header. The advantage is simplicity, but the disadvantage is that it cannot distinguish between different requesters or individual requests. Non-dynamic fixed API call keys are easily misused.

[0031] 3. JWT Verification: The east-west gateway uses a private key to issue JWTs, and the backend service uses a public key to verify the JWT signature and claims (such as issuer, audience, and expiration). The advantages are security and reliability, and the ability to distinguish each request. However, the disadvantages are also obvious: the public key must be distributed to each backend microservice, the JWT token itself has a long base64 encoding length, requiring longer network transmission bytes, and the issuance and verification process is time-consuming.

[0032] In order to ensure that the backend microservice API can be safely and authorized to access in the intranet environment and resist all unauthorized and illegal access, the embodiment of the present application performs identity verification and API call authorization verification through the east-west gateway, and verifies the call pass token issued by the east-west gateway. Based on this implementation method, API requests with illegal requester identities and legal requester identities but no call authorization can be intercepted at the east-west gateway, and API requests without call passes that reach the requested party can be directly rejected by the backend microservice with confidence, so that the API of the called microservice can only be called when the requester identity is legal and the requester has API call authorization, and will not be called by mistake or indiscriminately.

[0033] Specifically, the embodiments of the present application have the following objectives:

[0034] a. Verify the legitimacy of the requesting party's identity.

[0035] b. Check the callability of the API to ensure that the requesting party has the legal right to call the API.

[0036] After both a and b are verified, a dynamic call pass token can be issued for each request.

[0037] c. The requested party performs a request-to-token verification on the legitimacy of the call passtoken by calling the verification interface of the east-west gateway.

[0038] d. Call the timestamp validity check of the passtoken to avoid the time validity check of a token being repeatedly overdue;

[0039] e. The generation and verification of passtoken is efficient;

[0040] f. The pass token is tamper-proof and contains redundant check bits.

[0041] g. The call pass token is anti-forgery. The pass token contains the east-west gateway signature. The secret key and algorithm used for the signature are confidential and not public, so the pass token is anti-forgery.

[0042] h. Calling passtoken does not require server-side storage and can be self-verified;

[0043] It can be seen that the embodiments of the present application focus on the intranet environment, starting from a series of methods in which the API call initiator needs to first obtain API call authorization, the east-west gateway authenticates the API callability of the initiator and issues a call pass, and the API provider, that is, the called party, reversely verifies the call pass, so as to make the east-west API calls between microservices safer, more traceable, and more verifiable.

[0044] First, issue an identity. Issue identity for business domains, such as business domain A, business domain B, and business domain C. In addition, register the callable API on the East-West Gateway. The business domain needs to register the callable API for the business domain with the East-West Gateway. When business domain B registers the API with the East-West Gateway, it needs to provide the East-West Gateway with its identity, which is issued by the East-West Gateway. The East-West Gateway knows that this API belongs to business domain B. Further, apply for API callable authorization. Before business domain A calls the API of business domain B, it needs to first apply for API callable authorization, which will be reviewed and approved by the API manager of business domain B on the system.

[0045] Accordingly, API calls are initiated through the east-west gateway during runtime. Microservices across business domains do not directly call each other using Feign; instead, calls are forwarded through the east-west gateway. When a microservice in business domain A calls the API of a microservice in business domain B via the east-west gateway, it must present the identity of business domain A to the east-west gateway. The east-west gateway verifies authorization for the call and intercepts the call if it is not authorized.

[0046] If the verification passes, the East-West Gateway allows the API call and issues a call pass for the call. Before forwarding the API request to the destination microservice, the East-West Gateway issues a call pass for the request, which means that the request has passed the East-West Gateway's callability verification, that is, it issues a token generated by the East-West Gateway.

[0047] Specifically, the east-west gateway uses five attributes to generate a pass token for each request. The callee proactively verifies the pass token's authenticity with the east-west gateway. If the pass token verifies successfully, the API logic is executed. If it fails, the API logic is rejected and the call is intercepted.

[0048] Through the above solution, the API provided by the service provider mounted on the East-West Gateway can only be accessed by authorized users. Furthermore, it is a zero-trust authorized access with a quasi-single-pass effect, with one token per request. This is achieved by the East-West Gateway issuing a 32-bit passtoken value and the microservice actively verifying the passtoken. This passtoken is generated by the East-West Gateway based on five important core information related to this request that have been verified after the East-West Gateway verifies that the requester has a legitimate identity and legally callable authorization: the requester's identity A, the unique request ID, the requester's identity B, the API path of the requested party's API, and the timestamp. This passtoken is authoritative, legal, and secure.

[0049] In summary, the embodiments of the present application have the following advantages:

[0050] Security: No access without authorization. Calls not forwarded through the east-west gateway will be intercepted, and only one link, the east-west gateway, will be allowed. Access authentication must be passed through the east-west gateway.

[0051] Traceability: The origin of requests is clear. The east-west gateway has logging and monitoring statistics to answer who called the API, and the API provider's server also has logging.

[0052] Governability: The east-west gateway becomes an API request distribution platform. As a control plane, it can perform governance operations such as access authentication, request frequency limiting, and emergency request freezing for API requests.

[0053] The following describes in detail a method for calling an API provided by an embodiment of the present application through specific embodiments and application scenarios in conjunction with the accompanying drawings.

[0054] like Figure 1 FIG. 1 is a flow chart of a method for calling an API provided in an embodiment of the present application, the method comprising the following steps:

[0055] Step 101: Receive an API call request from a requester and perform identity verification on the requester.

[0056] Specifically, the identity of the requesting party may be verified based on the identity identifier of the requesting party carried in the API call request.

[0057] Step 102: If the identity verification is passed, a call pass is generated for the API call request, and the API call request including the call pass is forwarded to the requested party.

[0058] Specifically, if the identity verification is passed, the identity of the requested party and the forwarding destination information of the requested party's API can be queried; a call pass can be generated based on the identity of the requesting party, the request ID, the identity of the requested party, the forwarding destination information of the requested party's API, and the timestamp information.

[0059] In this embodiment, an N0 value can be generated based on the identity identifier of the requesting party and the identity identifier of the requested party; an S value can be generated based on the identity identifier and timestamp information of the requesting party; a D value can be generated based on the identity identifier and timestamp information of the requested party; a T value can be generated based on the request identifier ID and timestamp information; a P value can be generated based on the forwarding destination information and timestamp information of the requested party API; the first 27 bits of the call pass can be generated based on the timestamp information and the N0 value, the S value, the D value, the T value and the P value; a 4-bit signature bit can be generated using the first 27 bits of the call pass and the built-in signature key of the east-west gateway; a 1-bit redundant check bit can be generated based on the 4-bit signature bit and the first 27 bits of the call pass; the 1-bit redundant check bit, the 4-bit signature bit and the first 27 bits of the call pass can be merged into the call pass.

[0060] Step 103: Receive a verification request from the requested party, verify the call pass in the verification request, and return the verification result to the requested party, so that the requested party executes API business logic or refuses to provide services based on the verification result.

[0061] Specifically, each component of the call pass in the verification request can be verified. If the verification passes, verification success information is returned to the requested party, so that the requested party executes the API business logic according to the verification success information; if the verification fails, verification failure information is returned to the requested party, so that the requested party refuses to provide services according to the verification failure information.

[0062] In this embodiment, identity identification may be issued to each business domain, and the callable API of each business domain may be registered.

[0063] Accordingly, it is possible to verify whether the identity identifier of the requesting party is a legal identity identifier that has been issued. If so, it is determined that the identity authentication is passed; otherwise, it is determined that the identity is not authenticated;

[0064] After verifying the identity of the requester carried in the API call request, it is also possible to determine whether the requested API is a callable API.

[0065] Furthermore, a 1-bit redundant check bit can be regenerated to determine whether the regenerated 1-bit redundant check bit is the same as the 1-bit redundant check bit in the call pass; if different, it is determined that the verification has failed; if they are the same, the identity of the requesting party and the regenerated N0 value of the requested party are used to determine whether the regenerated N0 value is the same as the N0 value in the call pass; if different, it is determined that the verification has failed; if they are the same, the S value, D value, T value, P value and timestamp information are decoded from the call pass according to the N0 value, and the S value, D value, T value, P value and timestamp information are used to regenerate a 4-bit signature value to determine whether the regenerated 4-bit signature value is the same as the 4-bit signature value in the call pass; if different, it is determined that the verification has failed; if they are the same, the identity of the requesting party and the decoded timestamp information are used to regenerate the S value to determine whether the regenerated S value is the same as the The S value in the calling pass is the same; if different, it is determined that the verification has failed; if the same, the identity identification information of the requested party and the decoded timestamp information are used to regenerate the D value, and it is determined whether the regenerated D value is the same as the D value in the calling pass; if different, it is determined that the verification has failed; if the same, the request identification ID and the decoded timestamp information are used to regenerate the T value, and it is determined whether the regenerated T value is the same as the T value in the calling pass; if different, it is determined that the verification has failed; if the same, the forwarding destination information of the requested party API and the decoded timestamp information are used to regenerate the P value, and it is determined whether the regenerated P value is the same as the P value in the calling pass; if different, it is determined that the verification has failed; if the same, whether the timestamp is within the validity period is determined based on the decoded timestamp information, and if so, it is determined that the verification has passed; otherwise, it is determined that the verification has failed.

[0066] The embodiment of the present application implements effective management of API call requests by verifying the identity of the requesting party and authenticating the call pass, so that the API is securely authorized for access and unauthorized illegal access is resisted.

[0067] In the embodiment of the present application, the architecture of the east-west gateway is as follows: Figure 2 Based on this architecture, the specific implementation process of calling the API through the east-west gateway is as follows: Figure 3 As shown, the following steps are included:

[0068] Step 1: Register the callable authorization information that manages who can call whose API on the East-West Gateway configuration management tool.

[0069] Among them, step 1-1: the east-west gateway administrator issues an identity identifier for the business domain microservice;

[0070] Step 1-2: The business domain administrator registers the callable API of the microservice on the east-west gateway for other relevant parties to call;

[0071] Steps 1-3: Business domain administrators apply for API call permissions for other business domains;

[0072] Steps 1-4: The business domain administrator reviews and approves or rejects the application for calling its API;

[0073] Step 2: The requesting party initiates an API call request to the east-west gateway. After verification, the east-west gateway forwards the API call request to the requested party.

[0074] Among them, step 2-1: the identity verification component of the east-west gateway running state verifies whether the requester's identity is legal;

[0075] Step 2-2: The API routing component in the running state of the east-west gateway queries to obtain the API of the requested party and the forwarding destination API path information of the requested party's API;

[0076] Step 2-3: The API callability verification component in the running state of the east-west gateway verifies whether the requester's identity can call the API callability authorization of the requested party's identity;

[0077] Step 2-4: The API call pass issuance component in the running state of the east-west gateway issues a call pass token for this API request;

[0078] Step 2-5: The API request forwarding component in the running state of the east-west gateway appends the call pass token information to the HTTP request header and forwards the API request to the requested party.

[0079] Step 3: After receiving the incoming API request, the requested party takes the passtoken to the API of the east-west gateway to call the pass verification component to verify the legitimacy of the passtoken, and then executes the API business logic or refuses service.

[0080] Among them, step 3-1: the requested party encapsulates the call pass token and related necessary information received when the API request arrives into the request body information, and initiates an HTTP request to the API call pass verification component in the running state of the east-west gateway;

[0081] Step 3-2: The API call pass verification component of the east-west gateway in running state verifies the various components of the passtoken after receiving the passtoken verification request. Based on different verification results, it finally returns the results such as verification passed, verification failed (passtoken invalid), verification failed (passtoken invalid), and verification failed (passtoken expired).

[0082] Step 3-3: The requested party executes the API business logic after obtaining the result of the passtoken verification. The requested party refuses to provide services after obtaining the result of the passtoken verification failure.

[0083] Among them, the business information required for generating a call pass is obtained in the following order: the requester identity verification component in the east-west gateway running state verifies the legal issuance of the identity information of the identity accesskeyA carried by the request initiator, and obtains the requester identity acesskeyA, one of the business information required for generating a call pass after the verification is passed; the api call entry component in the east-west gateway running state determines the request identification ID information, one of the business information required for generating a call pass, which can generally be obtained as traceid; the api route query component in the east-west gateway running state obtains the requested party identity information accesskeyB, one of the business information required for generating a call pass, and the apipath for forwarding the requested api after querying the api route; the api request forwarding component in the east-west gateway running state determines the timestamp information, one of the business information required for generating a call pass, before forwarding the api to the requested party.

[0084] Correspondingly, the API call pass forwarding component generates a call pass in the following steps: the API call pass issuing component of the east-west gateway uses five core business semantic information as input parameters, including the requester's identity A, requester ID, requested party's identity B, requested party's API forwarding apipath, and timestamp. It first generates each component based on each passtoken component generator, then generates the east-west gateway signature value based on the component, and finally generates a 1-bit tamper-proof redundant check bit to generate a complete passtoken.

[0085] like Figure 4As shown, the specific steps of generating a call pass are as follows: the api call pass issuance component uses the requester identity and the requested party identity as input parameters, calls the N0 value generator, and generates the N0 value based on the N0 value generation algorithm as the algorithm identifier; the api call pass issuance component uses the requester identity and timestamp information as input parameters, calls the S value generator, and generates the S value based on the S value generation algorithm; the api call pass issuance component uses the requested party identity and timestamp information as input parameters, calls the D value generator, and generates the D value based on the D value generation algorithm; the api call pass issuance component uses the requester identity and timestamp information as input parameters, calls the D value generator, and generates the D value based on the D value generation algorithm; the api call pass issuance component uses the requester identity ( The API calls the pass issuance component and uses the apipath and timestamp information of the requested API as input parameters, calls the P value generator, and generates the P value based on the P value generation algorithm; the API calls the pass issuance component and uses the timestamp and the previous step to generate the N0 value, S value, D value, T value, P value, as input parameters to call the passtoken27 generator, and generates the first 27 bits of the passtoken based on the passtoken character arrangement algorithm. The passtoken character arrangement algorithm is as follows: Figure 5As shown, N0 represents the algorithm identifier, N1-N13 represents the timestamp, S0-S2 represents the S value, D0-D2 represents the D value, T0-T3 represents the T value, P0-P2 represents the P value, Sig0-Sig3 represents the signature value, and CRC represents the redundancy check digit. The API call pass issuance component uses the first 27 bits of the passtoken and the east-west gateway's built-in signature key as input parameters to call the passtoken4 generator. Based on the signature value generation algorithm, it generates 4 signature bits, and then the first 31 bits of the passtoken. The API call pass issuance component uses the first 31 bits of the passtoken as input parameters to call the passtoken1 generator. Based on the redundancy check digit generation algorithm, it generates 1 redundancy check digit, and finally generates a 32-bit passtoken. Accordingly, the requested party initiates the pass verification operation and executes business logic or denies service based on the verification result in the following steps: The requested microservice receives the API call request and obtains the HTTP request header information. The requested party determines whether the API requires passtoken verification based on its own configuration decisions based on the API's characteristics. If the configuration decision is that this API does not need to verify the passtoken, the API business logic will be executed directly and the result will be returned. The configuration decision can be made based on the microservice configuration file or in the code based on the @ annotation. All APIs can be configured to verify the passtoken, or only important APIs can be configured to verify the passtoken. If the passtoken is required, the HTTP request header information will be checked to see if it contains important information such as the passtoken, the requester identity, and the request ID. If not, a 403 error will be returned directly and the service will be refused. If the three important information of passtoken, requester identity, and request ID are present at the same time, the API path information of the request held by the requested party and its own identity information will be used as the requested party identity information as input parameters, and a passtoken verification request will be initiated to the east-west gateway. If the passtoken verification is successful, the API business logic will be executed and the result will be returned. If the passtoken verification fails, the service will be refused.

[0086] like Figure 6As shown, the API call pass verification component verifies the legitimacy of the call pass in the following steps: The API call pass verification component of the east-west gateway uses the five core semantic information, including the requester's identity A, request identifier ID, called API path, requested party identity, and passtoken, sent when verifying the interface through the passtoken, as input parameters to carry out verification activities. First, the passtoken1 generator is called with the passtoken as input to regenerate a single check digit and verify their identity. The N0 generator is then called with the requester's identity A and the requested party's identity as input to regenerate the N0 value and verify their identity. The passtoken's character arrangement algorithm, represented by the N0 value, is then used to decode the S, D, T, P, and time stamp values ​​from the passtoken. The passtoken's signature is then regenerated using the passtoken4 generator and verified for identity. Finally, the S, D, T, and P values ​​are regenerated using the requester's identity A, the request ID, the called API path (the forwarding API path used by the east-west gateway to forward API requests), the requested party's identity, and the decoded timestamp as input to verify their identity. Finally, the decoded timestamp is verified to be within the permitted validity period. If all verifications pass, a verification success is returned. If the timestamp expires, a verification failure is returned. Otherwise, a verification failure is returned, indicating the passtoken is invalid.

[0087] The specific steps are as follows: call the passtoken1 generator to regenerate a 1-bit redundant check bit, verify whether the redundant check bit is the same, if not, return the verification failure passtoken illegal; use the requesting party identity and the requested party identity as input, call the N0 value generator to regenerate the N0 value, verify whether the N0 values ​​are the same, if not, return the verification failure passtoken illegal; decode the S value, D value, T value, P value and time stamp information from the passtoken according to the passtoken character arrangement algorithm represented by the N0 value; use the S value, D value, T value, P value and time stamp information as input parameters, call the passtoken4 generator to regenerate a 4-bit signature value, verify whether the 4-bit signature values ​​are the same, if not, return the verification failure passtoken illegal; use the requesting party identity information and the decoded timestamp information as input parameters, call the S value generator to regenerate the S value, and verify whether the S value is the same If they are not the same, the return code indicates that the verification failed and the passtoken is invalid. Use the requested party's identity information and the decoded timestamp information as input parameters, call the D value generator to regenerate the D value, and check whether the D values ​​are the same. If they are not the same, the return code indicates that the verification failed and the passtoken is invalid. Use the request identification ID information and the decoded timestamp information as input parameters, call the T value generator to regenerate the T value, and check whether the T values ​​are the same. If they are not the same, the return code indicates that the verification failed and the passtoken is invalid. Use the apipath information and the decoded timestamp information as input parameters, call the P value generator to regenerate the P value, and check whether the P values ​​are the same. If they are not the same, the return code indicates that the verification failed and the passtoken is invalid. Use the decoded timestamp information as input parameters, call the timestamp validity verifier to check whether the timestamp is within the validity period. If the timestamp is within the validity period, the return code indicates that the verification is successful. If the timestamp is not within the validity period, the return code indicates that the timestamp is expired.

[0088] In summary, the embodiment of the present application designs and implements a method and apparatus for an intranet east-west API to only accept legitimate call requests from legitimate identities with callable authorization and holding call passes issued by an east-west gateway. Through the implementation of meticulous steps such as identity registration in the configuration state, API callable authorization application review, and API callable permission verification in the operation state, API call pass issuance, and API call pass verification, the purpose of protected authorized access to important back-end APIs in the intranet environment is achieved. The embodiment of the present application also designs and implements a method and apparatus for an intranet east-west gateway to efficiently issue and verify call passes. The generation and verification algorithm of the call pass token has many advantages such as simple anti-tampering, server-side signature anti-counterfeiting, short token character length to save network byte transmission, one request for one pass, support for strong verification on the server side, support for client self-verification with a high level of security even without distributing secret keys, and high efficiency in generating verification algorithms. The embodiment of the present application also designs and implements a method and apparatus for an intranet east-west gateway to perform east-west API callable authorization. Manual management actions such as identity registration management for requesters and requested parties, API registration management, and application and review of API call authorization are performed at the east-west gateway. Identity legitimacy verification and API call authorization verification are also completed at the east-west gateway. With centralized management and verification, cross-domain microservice calls on the SASS platform require only one additional hop through the east-west gateway, ensuring enhanced security.

[0089] Compared with the prior art, the embodiment of the present application does not need to send any secret key to the backend microservice. When the signature key of the east-west gateway changes, it is only necessary to verify the signature of the old and new keys at the same time in a short time, and the backend microservices of the SaaS platform are unaware of it. The call passpoken generated by the embodiment of the present application is a fixed 32-character length, which saves network transmission bytes. The method disclosed in the embodiment of the present application is that the east-west API only accepts legal call requests from legal identities with callable authorization and holding call passes issued by the east-west gateway, which has the characteristics of simple operation and maintenance, and the combination of distributed verification and centralized verification. In the method disclosed by the present invention, the identity of the requester is legal, and the requester has the legal authority to call the API. These two points of verification are uniformly completed at the east-west gateway. The backend microservices of the SaaS platform only need to verify whether the call passtoken is legal. The verification is distributed and shared. The backend microservices only need to verify the passtoken, and do not need to pay attention to the identity of the requester and the callable authorization, which is simple to implement and operate.

[0090] like Figure 7 FIG. 1 is a schematic diagram of a structure of a device for calling an API provided in an embodiment of the present application, including:

[0091] The identity verification module 710 is used to receive an API call request from a requester and perform identity verification on the requester.

[0092] Specifically, the identity verification module 710 is specifically configured to perform identity verification on the requesting party based on the identity identifier of the requesting party carried in the API call request.

[0093] The generation module 720 is used to issue a call pass for the API call request if the identity verification is passed, and forward the API call request containing the call pass to the requested party.

[0094] Specifically, the generation module 720 is specifically used to query the identity of the requested party and the forwarding destination information of the requested party's API when the identity verification is passed; and generate a call pass based on the identity of the requesting party, the request identification ID, the identity of the requested party, the forwarding destination information of the requested party's API, and the timestamp information.

[0095] In this embodiment, the generation module 720 is specifically used to generate an N0 value based on the identity identifier of the requesting party and the identity identifier of the requested party; generate an S value based on the identity identifier and timestamp information of the requesting party; generate a D value based on the identity identifier and timestamp information of the requested party; generate a T value based on the request identifier ID and timestamp information; generate a P value based on the forwarding destination information and timestamp information of the requested party API; generate the first 27 bits of the call pass based on the timestamp information and the N0 value, the S value, the D value, the T value and the P value; use the first 27 bits of the call pass and the built-in signature key of the east-west gateway to generate a 4-bit signature bit; generate a 1-bit redundant check bit based on the 4-bit signature bit and the first 27 bits of the call pass; merge the 1-bit redundant check bit, the 4-bit signature bit and the first 27 bits of the call pass into the call pass.

[0096] The verification module 730 is used to receive a verification request from the requested party, verify the call pass in the verification request, and return the verification result to the requested party so that the requested party can execute API business logic or refuse to provide services based on the verification result.

[0097] Specifically, the verification module 730 is specifically used to verify the various components of the call pass in the verification request. If the verification is successful, a verification success message is returned to the requested party so that the requested party executes the API business logic according to the verification success message; if the verification fails, a verification failure message is returned to the requested party so that the requested party refuses to provide services according to the verification failure message.

[0098] In this embodiment, the verification module 730 is specifically used to regenerate a 1-bit redundant check bit, and determine whether the regenerated 1-bit redundant check bit is the same as the 1-bit redundant check bit in the call pass; if different, it is determined that the verification has failed; if they are the same, the identity identifier of the requesting party and the regenerated N0 value of the requested party are used to determine whether the regenerated N0 value is the same as the N0 value in the call pass; if different, it is determined that the verification has failed; if they are the same, the S value, D value, T value, P value and timestamp information are decoded from the call pass according to the N0 value, and the S value, D value, T value, P value and timestamp information are used to regenerate a 4-bit signature value, and determine whether the regenerated 4-bit signature value is the same as the 4-bit signature value in the call pass; if different, it is determined that the verification has failed; if they are the same, the identity identifier of the requesting party and the decoded timestamp information are used to regenerate the S value, and determine whether the regenerated Whether the S value is the same as the S value in the call pass; if different, it is determined that the verification has failed; if they are the same, the identity identification information of the requested party and the decoded timestamp information are used to regenerate the D value, and determine whether the regenerated D value is the same as the D value in the call pass; if different, it is determined that the verification has failed; if they are the same, the request identification ID and the decoded timestamp information are used to regenerate the T value, and determine whether the regenerated T value is the same as the T value in the call pass; if different, it is determined that the verification has failed; if they are the same, the forwarding destination information of the requested party API and the decoded timestamp information are used to regenerate the P value, and determine whether the regenerated P value is the same as the P value in the call pass; if different, it is determined that the verification has failed; if they are the same, then according to the decoded timestamp information, it is determined whether the timestamp is within the validity period, and if so, it is determined that the verification has passed; otherwise, it is determined that the verification has failed.

[0099] In this embodiment, the above-mentioned device further includes:

[0100] Issuing module, used to issue identity tags for each business area;

[0101] The registration module is used to register callable APIs in various business areas.

[0102] Accordingly, the identity verification module 710 is specifically configured to verify whether the identity identifier of the requesting party is a legal identity identifier that has been issued. If so, it is determined that the identity verification is successful; otherwise, it is determined that the identity is not verified.

[0103] The above device further includes:

[0104] The judgment module is used to judge whether the requested API is a callable API.

[0105] The embodiment of the present application implements effective management of API call requests by verifying the identity of the requesting party and authenticating the call pass, so that the API is securely authorized for access and unauthorized illegal access is resisted.

[0106] The present application also provides a computer-readable storage medium having a computer program stored thereon. When the computer program is executed by a processor, the computer program implements the various processes of the above-mentioned method embodiment of calling an API and can achieve the same technical effect. To avoid repetition, the details are not described here. The computer-readable storage medium is, for example, a read-only memory (ROM), a random access memory (RAM), a magnetic disk, or an optical disk.

[0107] It should be noted that, in this document, the terms "comprises," "includes," or any other variations thereof are intended to encompass non-exclusive inclusion, such that a process, method, article, or apparatus comprising a series of elements includes not only those elements but also other elements not explicitly listed, or elements inherent to such process, method, article, or apparatus. In the absence of further limitations, an element defined by the phrase "comprising a ..." does not exclude the presence of other identical elements in the process, method, article, or apparatus comprising the element.

[0108] Through the description of the above implementation methods, those skilled in the art can clearly understand that the above-mentioned embodiment methods can be implemented by means of software plus the necessary general hardware platform, and of course can also be implemented by hardware, but in many cases the former is a better implementation method. Based on this understanding, the technical solution of the present application, or the part that contributes to the prior art, can be embodied in the form of a software product, which is stored in a storage medium (such as ROM / RAM, magnetic disk, optical disk), and includes a number of instructions for enabling a terminal (which can be a mobile phone, computer, server, air conditioner, or network device, etc.) to execute the methods described in each embodiment of the present application.

[0109] The embodiments of the present application are described above in conjunction with the accompanying drawings, but the present application is not limited to the above-mentioned specific implementation methods. The above-mentioned specific implementation methods are merely illustrative and not restrictive. Under the guidance of this application, ordinary technicians in this field can also make many forms without departing from the purpose of this application and the scope of protection of the claims, all of which are within the protection of this application.

Claims

1. A method for calling an API, characterized in that: The following steps are involved: Receive an API call request from a requester and verify the identity of the requester; If the identity verification is passed, a call pass is issued for the API call request, and the API call request containing the call pass is forwarded to the requested party; Receive a verification request from the requested party, verify the call pass in the verification request, and return a verification result to the requested party, so that the requested party executes API business logic or refuses to provide services based on the verification result.

2. The method according to claim 1, characterized in that The identity verification of the requesting party specifically includes: Performing identity verification on the requester based on the identity identifier of the requester carried in the API call request; If the identity verification is passed, issuing a call pass for the API call request specifically includes: If the identity verification is successful, query the identity of the requested party and the forwarding destination information of the requested party's API; Generate a call pass based on the identity of the requester, the request ID, the identity of the requested party, the forwarding destination information of the requested party's API, and the timestamp information; The verifying the calling pass in the verification request and returning the verification result to the requested party so that the requested party executes the API business logic or refuses to provide services according to the verification result specifically includes: Verify the various components of the call pass in the verification request. If the verification passes, return verification success information to the requested party, so that the requested party executes the API business logic according to the verification success information; if the verification fails, return verification failure information to the requested party, so that the requested party refuses to provide services according to the verification failure information.

3. The method according to claim 2, characterized in that Also includes: Issue identity tags for each business area and register the callable APIs for each business area; The identity verification of the requesting party carried in the API call request specifically includes: Verify whether the identity of the requesting party is a valid identity that has been issued. If so, the identity verification is determined to be successful; otherwise, the identity is determined to be unverified. After verifying the identity of the requester carried in the API call request, the method further includes: Determine whether the requested API is a callable API.

4. The method according to claim 2, characterized in that The generating of the call pass according to the identity of the requesting party, the requesting ID, the identity of the requested party, the forwarding destination information of the requested party's API, and the timestamp information specifically includes: Generate an N0 value according to the identity identifier of the requesting party and the identity identifier of the requested party; Generate an S value based on the identity identifier and timestamp information of the requesting party; Generate D value based on the identity and timestamp information of the requested party; Generate T value based on request identification ID and timestamp information; Generate a P value based on the forwarding destination information and timestamp information of the requested API; Generate the first 27 bits of the call pass according to the timestamp information and the N0 value, the S value, the D value, the T value, and the P value; Use the first 27 bits of the call pass and the built-in signature key of the east-west gateway to generate a 4-bit signature bit; Generate a 1-bit redundant check bit based on the 4-bit signature bit and the first 27 bits of the call pass; The 1-bit redundant check bit, the 4-bit signature bit and the first 27 bits of the call pass are combined into the call pass.

5. The method according to claim 4, characterized in that The verification of each component of the call pass in the verification request specifically includes: Regenerate a 1-bit redundant check bit, and determine whether the regenerated 1-bit redundant check bit is the same as the 1-bit redundant check bit in the call pass; if different, determine that the verification has failed; if they are the same, use the identity of the requesting party and the regenerated N0 value of the requested party to determine whether the regenerated N0 value is the same as the N0 value in the call pass; if different, determine that the verification has failed; if they are the same, decode the S value, D value, T value, P value and timestamp information from the call pass according to the N0 value, and use the S value, D value, T value, P value and timestamp information to regenerate a 4-bit signature value, and determine whether the regenerated 4-bit signature value is the same as the 4-bit signature value in the call pass; if different, determine that the verification has failed; if they are the same, use the identity of the requesting party and the decoded timestamp information to regenerate the S value, and determine whether the regenerated S value is the same as the The S value in the pass is the same; if different, it is determined that the verification has failed; if the same, the identity identification information of the requested party and the decoded timestamp information are used to regenerate the D value, and determine whether the regenerated D value is the same as the D value in the calling pass; if different, it is determined that the verification has failed; if the same, the request identification ID and the decoded timestamp information are used to regenerate the T value, and determine whether the regenerated T value is the same as the T value in the calling pass; if different, it is determined that the verification has failed; if the same, the forwarding destination information of the requested party API and the decoded timestamp information are used to regenerate the P value, and determine whether the regenerated P value is the same as the P value in the calling pass; if different, it is determined that the verification has failed; if the same, the timestamp is determined to be within the validity period based on the decoded timestamp information, and if so, it is determined that the verification has passed; otherwise, it is determined that the verification has failed.

6. A device for calling an API, characterized in that: include: An identity verification module is used to receive an API call request from a requester and perform identity verification on the requester; A generating module, configured to issue a call pass for the API call request if the identity verification passes, and forward the API call request including the call pass to the requested party; The verification module is used to receive a verification request from the requested party, verify the call pass in the verification request, and return the verification result to the requested party so that the requested party can execute API business logic or refuse to provide services based on the verification result.

7. The device according to claim 6, characterized in that The identity verification module is specifically configured to verify the identity of the requester based on the identity identifier of the requester carried in the API call request; The generating module is specifically used to query the identity identifier of the requested party and the forwarding destination information of the requested party's API when the identity verification passes; Generate a call pass based on the identity of the requester, the request ID, the identity of the requested party, the forwarding destination information of the requested party's API, and the timestamp information; The verification module is specifically configured to verify the various components of the call pass in the verification request, and if the verification succeeds, return a verification success message to the requested party, so that the requested party executes the API business logic according to the verification success message; If the verification fails, verification failure information is returned to the requested party, so that the requested party refuses to provide services based on the verification failure information.

8. The device according to claim 7, characterized in that Also includes: Issuing module, used to issue identity tags for each business area; The registration module is used to register the callable APIs in various business areas; The identity verification module is specifically used to verify whether the identity identifier of the requesting party is a legal identity identifier that has been issued. If so, it is determined that the identity verification is passed; otherwise, it is determined that the identity is not verified; The device is characterized in that it further comprises: The judgment module is used to judge whether the requested API is a callable API.

9. The device according to claim 7, characterized in that The generating module is specifically configured to generate an N0 value according to the identity identifier of the requesting party and the identity identifier of the requested party; and generate an S value according to the identity identifier and timestamp information of the requesting party; Generate D value based on the identity and timestamp information of the requested party; Generate T value based on request identification ID and timestamp information; Generate a P value based on the forwarding destination information and timestamp information of the requested API; Generate the first 27 bits of the call pass based on the timestamp information and the N0 value, the S value, the D value, the T value and the P value; use the first 27 bits of the call pass and the east-west gateway built-in signature key to generate a 4-bit signature bit; generate a 1-bit redundant check bit based on the 4-bit signature bit and the first 27 bits of the call pass; merge the 1-bit redundant check bit, the 4-bit signature bit and the first 27 bits of the call pass into the call pass.

10. The device according to claim 9, characterized in that The verification module is specifically configured to regenerate a 1-bit redundant check digit and determine whether the regenerated 1-bit redundant check digit is the same as the 1-bit redundant check digit in the call pass; if they are different, determining that the verification has failed; If they are the same, then using the identity identifier of the requesting party and the regenerated N0 value of the requested party to determine whether the regenerated N0 value is the same as the N0 value in the call pass; if they are different, determining that the verification has failed; If they are the same, decode the S value, D value, T value, P value and timestamp information from the call pass according to the N0 value, and use the S value, D value, T value, P value and timestamp information to regenerate a 4-bit signature value, and determine whether the regenerated 4-bit signature value is the same as the 4-bit signature value in the call pass; if they are different, determine that the verification fails; If they are the same, regenerate the S value using the identity identifier of the requesting party and the decoded timestamp information, and determine whether the regenerated S value is the same as the S value in the call pass; if they are different, determine that the verification fails; If they are the same, the D value is regenerated using the identity information of the requested party and the decoded timestamp information, and it is determined whether the regenerated D value is the same as the D value in the call pass; if they are different, it is determined that the verification has failed; If they are the same, the T value is regenerated using the request identification ID and the decoded timestamp information, and it is determined whether the regenerated T value is the same as the T value in the call pass; if they are different, it is determined that the verification has failed; If they are the same, regenerate the P value using the forwarding destination information of the requested party API and the decoded timestamp information, and determine whether the regenerated P value is the same as the P value in the call pass; if they are different, determine that the verification fails; If they are the same, it is determined whether the timestamp is within the validity period based on the decoded timestamp information. If so, it is determined that the verification is successful; otherwise, it is determined that the verification is unsuccessful.

Images