Business request interaction method and device, medium and program product

Abstract

The invention discloses a service request interaction method and device, a medium and a program product, and relates to the technical field of computers. The method comprises the following steps: a non-semantic random dynamic path is generated by using a gateway, a client initiates a request based on the path, and the path does not directly expose a service interface, so that an attacker can be prevented from initiating a targeted attack on the service interface path, and the interface exposure risk is reduced. A dual-stage token mechanism of a pre-authorization token and an execution token is adopted, full-process protection of operation parameters is realized through two-layer verification, and the breakthrough difficulty of an attacker is increased; and the token aims at different stages, so that access control with finer granularity can be realized. The pre-authorization token is used for verifying identity legality; and the execution token is used for verifying the legality of the operation parameters in the request, so that the operation intention verification is realized, the problem of separation of identity verification and operation authorization in a single-token scheme is avoided, and the operation parameters in the service request are protected, so that unauthorized access caused by token leakage can be effectively prevented.

Description

Technical Field

[0001] The present invention relates to the field of computer technology, and in particular to a service request interaction method, device, medium and program product. Background Art

[0002] In modern web service architectures, the RESTful (Representational State Transfer) architecture has become a mainstream API (Application Programming Interface) implementation due to its simplicity and scalability. It intuitively exposes resource structures through semantic URL (Uniform Resource Locator) paths, implements resource operations using HTTP (Hypertext Transfer Protocol), and relies on authentication protocols for access control. However, the RESTful architecture's semantic URL paths and sequential numeric parameters can expose business logic. Related technologies also employ the GraphQL architecture, which receives structured query requests through a single endpoint and encapsulates resource operations as JSON-formatted query statements, mitigating the risk of semantic URL path exposure. However, deeply nested queries can lead to server-side resource exhaustion. Furthermore, attackers can still reverse engineer business logic by analyzing field correlations in query responses. Summary of the Invention

[0003] In view of this, the purpose of the present invention is to provide a service request interaction method, device, medium, and program product that can reduce the risk of interface exposure and prevent unauthorized access caused by token leakage. The specific solution is as follows:

[0004] This application discloses a service request interaction method, which is applied to a gateway and includes:

[0005] Obtaining a service request sent by a client; the path in the service request is a non-semantic random dynamic path, and the random dynamic path is generated by the gateway and sent to the client;

[0006] Extracting a pre-authorization token from the service request; the pre-authorization token is a token including a validity period that the client requests from the server;

[0007] The pre-authorization token is verified. If the verification is successful, the service request is sent to the corresponding server so that the server can generate an execution token according to the operation parameters in the service request and verify the execution token before executing the service operation according to the operation parameters.

[0008] This application also discloses a service request interaction method, which is applied to the server and includes:

[0009] Obtaining a pre-authorization token application request sent by a client, generating a pre-authorization token including a validity period and feeding it back to the client, so that the client can generate a service request based on the pre-authorization token;

[0010] Obtain the service request forwarded by the gateway after verifying the pre-authorization token; the path in the service request is a non-semantic random dynamic path, which is generated by the gateway and sent to the client;

[0011] Generate an execution token according to the operation parameters in the business request;

[0012] The execution token is verified before executing the business operation, and after the execution token is verified, the business operation is executed according to the operation parameters.

[0013] The present application also discloses an electronic device, comprising:

[0014] Memory, used to store computer programs;

[0015] The processor is configured to execute the computer program to implement the aforementioned service request interaction method.

[0016] The present application also discloses a computer-readable storage medium for storing a computer program; wherein the computer program implements the aforementioned service request interaction method when executed by a processor.

[0017] The present application also discloses a computer program product, including a computer program, which implements the aforementioned service request interaction method when executed by a processor.

[0018] In this application, a business request sent by a client is obtained; the path in the business request is a non-semantic random dynamic path, and the random dynamic path is generated by the gateway and sent to the client; a pre-authorization token is extracted from the business request; the pre-authorization token is a token with a validity period applied by the client to the server; the pre-authorization token is verified, and if the verification is successful, the business request is sent to the corresponding server, so that the server generates an execution token according to the operation parameters in the business request, and verifies the execution token before executing the business operation according to the operation parameters.

[0019] It can be seen that by using the gateway to generate a non-semantic random dynamic path, the client initiates a request based on this path. This path does not directly expose the business interface, which can prevent attackers from launching targeted attacks on the business interface path and reduce the risk of interface exposure. A two-stage token mechanism using pre-authorization tokens and execution tokens is used to achieve full-process protection of operation parameters through two-layer verification, increasing the difficulty for attackers to break through. In addition, the different stages targeted by the tokens can achieve more fine-grained access control. The pre-authorization token is used to verify the legitimacy of the identity; while the execution token is used to verify the legitimacy of the operation parameters in the request, realizing the verification of the operation intention, avoiding the problem of separation between identity authentication and operation authorization in the single-token solution, and protecting the operation parameters in the business request can effectively prevent unauthorized access caused by token leakage. BRIEF DESCRIPTION OF THE DRAWINGS

[0020] In order to more clearly illustrate the embodiments of the present invention or the technical solutions in the prior art, the following briefly introduces the drawings required for use in the embodiments or the description of the prior art. Obviously, the drawings described below are merely embodiments of the present invention. For ordinary technicians in this field, other drawings can be obtained based on the provided drawings without paying any creative work.

[0021] Figure 1 A flow chart of a service request interaction method provided by this application;

[0022] Figure 2 A specific token generation sequence diagram provided for this application;

[0023] Figure 3 A schematic diagram of the business request interaction system structure provided in this application. DETAILED DESCRIPTION

[0024] The following will be combined with the accompanying 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 only 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.

[0025] It should be noted that, in the description of this application, the terms "comprises," "includes," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or device 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 device. The terms "first," "second," etc., in this application are used to distinguish similar objects, and are not used to describe a particular order or sequence.

[0026] In the related art, the semantic URL path and continuous numeric parameters of the RESTful architecture will cause the business logic to be exposed, and the legitimacy of the operation intention cannot be verified. In the related art, the GraphQL architecture is also used to receive structured query requests through a single endpoint, and the resource operations are encapsulated as query statements in JSON format, which can eliminate the risk of semantic URL path exposure; however, deeply nested queries may lead to exhaustion of server-side resources; and attackers can still reversely deduce the business logic by analyzing the field correlation in the query response. In the related art, the access token short-termization strategy is also used to shorten the token validity period to a few minutes, and the refresh token mechanism is used to maintain session continuity, reducing the attack window after the token is leaked; however, the token still only verifies the legitimacy of the identity, and the attacker can still call unauthorized interfaces through legal tokens. In order to overcome the above technical problems, the present application proposes a business request interaction method that can reduce the risk of interface exposure and prevent unauthorized access caused by token leakage.

[0027] The embodiment of the present application discloses a service request interaction method applied to a gateway, see Figure 1 As shown, the method may include the following steps:

[0028] Step S11: obtaining a service request sent by the client; the path in the service request is a non-semantic random dynamic path, and the random dynamic path is generated by the gateway and sent to the client.

[0029] The client initiates a service request (HTTP (Hypertext Transfer Protocol) request), submitting a request containing the actual service operation parameters to the gateway. The path in the service request is a random, dynamic path and is non-semantic. A non-semantic path does not contain any direct information about the resource type, such as a dynamic Universally Unique Identifier (UUID) path. This path is generated by the gateway and sent to the client. After receiving the random, dynamic path, the client sends a service request to that path.

[0030] Understandably, traditional semantic endpoints (such as / users / {id}) directly expose the resource type (user) and hierarchical relationships (user resources are located under the users path). For example, for an API with user resources, a traditional semantic path might be: GET / users / 12345, where 12345 is the user ID. An attacker could attempt to access other users' data by enumerating IDs (such as 12346, 12347, and so on). In contrast, semantic-free paths (such as / resources / {uuid}) do not contain any direct information about the resource type. {uuid} is simply a randomly generated unique identifier, and the specific type or structure of the resource cannot be inferred from the path. By hiding the resource's structure and logic, API security is enhanced.

[0031] The gateway layer is responsible for generating random UUID paths. When the client initiates a request, the gateway layer dynamically generates a unique UUID and maps the UUID path to a specific backend service path. The client initiates a request through the dynamic path provided by the gateway layer. The client only needs to know how to send the request through the dynamic path of the gateway layer without having to worry about the specific path mapping logic. The gateway layer is responsible for path mapping. The gateway layer maintains a mapping table that maps the dynamically generated UUID path to a specific backend service path; for example, the dynamic path / 9a7b1c may be mapped to the actual backend path / user / register. The client only needs to initiate a request based on the dynamic path provided by the gateway layer and carry a pre-authorization token in the request header. The gateway layer then searches the mapping table based on the UUID path in the request and forwards the request to the corresponding backend service. This dynamic routing mechanism enables the gateway layer to flexibly manage and control the flow of requests.

[0032] By generating and managing UUID paths at the gateway layer, the true path structure of the backend service is hidden. Even if an attacker obtains the dynamic path, they cannot directly infer the logical structure of the backend service. Furthermore, the randomness and uniqueness of the dynamic path make path traversal attacks very difficult. At the same time, the gateway layer can dynamically adjust path mappings as needed, flexibly managing the flow of requests. It also centrally manages the routing logic of all requests, facilitating the implementation of global security policies and monitoring. This enhances security while improving the flexibility and manageability of the system.

[0033] In this embodiment, before obtaining the service request sent by the client, it also includes: obtaining the initial service request sent by the client; the path corresponding to the initial service request is a semantic path; using a universal unique identifier to generate a non-semantic random dynamic path corresponding to the semantic path, and sending the random dynamic path to the client, so that the client initiates the service request according to the random dynamic path. That is, the client first generates an API request and sends the request to the gateway. The path in the request is a semantic path. The gateway does not forward the request, but generates a dynamic UUID path and feeds it back to the client. The client re-initiates the request according to the dynamic path and sends the encrypted request to the gateway.

[0034] Step S12: extracting a pre-authorization token from the service request; the pre-authorization token is a token including a validity period that the client applies for from the server.

[0035] Before sending a service request, the client asks the server for a pre-authorization token. After obtaining the pre-authorization token, it adds it to the service request and sends it to the gateway. This pre-authorization token is used to verify the legitimacy of the user's identity, ensuring that the request comes from a legitimate client and is within the valid time window. The service request also includes encrypted operation parameters. The client sends the encrypted request to a random dynamic path and carries the pre-authorization token in the request header.

[0036] In some specific embodiments, before obtaining the service request sent by the client, the method further includes: obtaining a pre-authorization token request sent by the client; the pre-authorization token request includes a device fingerprint and a current timestamp; forwarding the pre-authorization token request to the server, so that the server generates a pre-authorization token through hashing based on a random universal unique identifier, the device fingerprint, and the current timestamp, and configures a validity period for the pre-authorization token; receiving the pre-authorization token and validity period information sent by the server, and forwarding the pre-authorization token and validity period information to the client. The gateway layer receives the request, extracts the pre-authorization token from the request header, and extracts the encrypted data packet from the request body.

[0037] That is, the client generates a device fingerprint (such as a device hardware hash value) for subsequent authentication. The client initiates a pre-authorization token application, submits the device fingerprint and the current timestamp, and requests a pre-authorization token. The server receives the client's device fingerprint and timestamp and generates a pre-authorization token. A specific pre-authorization token (Pre-Token) format is: PT- <uuid>-<timestamp hash>, where <uuid>The <timestamp hash> is a randomly generated UUID. The timestamp hash is the hash of the timestamp and device fingerprint using an algorithm such as SHA-256. The pre-authorization token is stored in a temporary database on the server and has a short validity period (such as 30 seconds or 1 second). The server returns the pre-authorization token to the client with a time window restriction based on the validity period, such as requiring the request to be submitted within 2 seconds.

[0038] Step S13: Verify the pre-authorization token. If the verification is successful, send the business request to the corresponding server; so that the server generates an execution token according to the operation parameters in the business request and verifies the execution token before executing the business operation according to the operation parameters.

[0039] After receiving the pre-authorization token, the server can also perform secondary verification and generate an execution token based on the operation parameters. That is, the execution token is bound to the operation parameters, so that the token can verify whether it is the operation intention of the bound operation parameters. In this way, the use of the token to perform other business will not be allowed.

[0040] The specific operations of the gateway to verify the pre-authorization token include but are not limited to: verifying the device fingerprint, checking whether the device fingerprint in the request is consistent with the device fingerprint bound to the pre-authorization token; verifying the time window, checking whether the request is within the validity period of the pre-authorization token; verifying the IP address, checking whether the IP address of the request is consistent with the IP address bound to the pre-authorization token; verifying the validity of the pre-authorization token, checking whether the pre-authorization token exists in the temporary database and whether it has not been marked as invalid. After the verification is passed, the request is forwarded to the server. If the pre-authorization token verification fails, the business request will not be processed, that is, the gateway directly intercepts the request and does not forward the request to the server.

[0041] After receiving the request forwarded by the gateway, the server can further decrypt the encrypted operation parameters and verify the integrity and legitimacy of the data. It also creates an execution token based on the operation parameters. The execution token is used to verify the legitimacy of the operation. By combining the pre-authorization token and the execution token, not only can the legitimacy of the user's identity be verified, but also the legitimacy of the operation, preventing unauthorized operations. The server executes the specific business logic based on the decrypted operation parameters and returns the processing results to the gateway. The gateway receives the response from the server and forwards it to the client, completing the business request.

[0042] Specifically, for example Figure 2 In the token management process shown, the client applies for a pre-authorization token, which the gateway forwards to the server. The client sends a service request to the gateway based on the pre-authorization token and encrypted operation parameters. The gateway verifies the pre-authorization token and forwards it to the server. The server generates an execution token and returns it to the gateway. The server's return of the execution token to the gateway enhances system security and flexibility. The gateway centrally manages request verification and auditing, enhancing security and auditing capabilities. Furthermore, the gateway can dynamically adjust security policies based on the execution token status and request context, enabling dynamic policy adjustment.

[0043] The server is used to generate an execution token based on the operation parameters and to establish a binding relationship between the execution token and the operation parameters; the execution token becomes invalid immediately after use. Specifically, the server generates an execution token based on a random universal unique identifier and the type of business operation corresponding to the business request, and configures the execution token to become invalid immediately after use. The server generates an execution token after verification. A specific execution token format is: ET- <uuid>- <operation type hash>, where <operation type hash> is the result of hashing the operation type using an algorithm. The execution token is bound to the encryption parameters and forwarded to the business interface. The execution token is strictly single-use and expires immediately after use, regardless of whether the business transaction is successful or not.

[0044] As can be seen from the above, in this embodiment, the business request sent by the client is obtained; the path in the business request is a non-semantic random dynamic path, and the random dynamic path is generated by the gateway and sent to the client; a pre-authorization token is extracted from the business request; the pre-authorization token is a token containing an expiration date that the client applies for from the server; the pre-authorization token is verified, and if the verification is successful, the business request is sent to the corresponding server, so that the server generates an execution token according to the operation parameters in the business request, and verifies the execution token before executing the business operation according to the operation parameters. By using the gateway to generate a non-semantic random dynamic path, the client initiates a request based on the path. The path will not directly expose the business interface, which can prevent attackers from launching targeted attacks on the business interface path and reduce the risk of interface exposure. A two-stage token mechanism of pre-authorization token and execution token is adopted to achieve full-process protection of operation parameters through two-layer verification, which increases the difficulty for attackers to break through; and the tokens target different stages, which can achieve more fine-grained access control. The pre-authorization token is used to verify the legitimacy of the identity; the execution token is used to verify the legitimacy of the operation parameters in the request, realize the operation intention verification, avoid the problem of separation of identity authentication and operation authorization in the single token solution, and protect the operation parameters in the business request, which can effectively prevent unauthorized access caused by token leakage.

[0045] In some specific embodiments, the verification of the pre-authorization token includes determining whether the pre-authorization token has expired and whether it is being used for the first time. If the pre-authorization token has expired and / or it is not being used for the first time, the pre-authorization token verification fails. This means that the pre-authorization token is not only valid but also can only be used once, preventing reuse. This further prevents attackers from illegally obtaining the token and launching attacks.

[0046] Furthermore, after the pre-authorization token verification fails, the system further includes: triggering a request cooling-off period for the client based on the cooling-off period, and not processing any service request from the client during the request cooling-off period. It is understandable that by triggering a request cooling-off period after the pre-authorization token verification fails, malicious users or attackers are effectively prevented from frequently attempting to bypass the verification mechanism, such as brute force attacks, and the frequency of attacks is reduced. By forcing cooling, the system burden is reduced, protecting the system from the threat of high-frequency attacks. Frequent invalid requests may lead to excessive consumption of system resources, and the cooling-off period can limit these invalid requests and protect system resources.

[0047] In some specific embodiments, the operation parameters are data pre-processed by the client, including but not limited to data serialization, parameter fingerprint generation, session key generation, and data encryption. Specifically, the client pre-processes the initial parameters to obtain the operation parameters and generates a service request based on the pre-authorization token and the operation parameters; the pre-processing includes data serialization, parameter fingerprint generation, session key generation, and data encryption; and the server decrypts and verifies the operation parameters.

[0048] The client first serializes the data, converting the original operation parameters into a binary stream for subsequent processing. To prevent replay attacks, a random salt value is added to the data, resulting in a binary stream containing the operation parameters and the random salt value. An operation fingerprint is then generated, creating a unique fingerprint for the serialized data for subsequent signature verification. Specifically, the client calculates the hash value of the serialized binary stream (for example, using the SHA3-256 algorithm) and signs the hash value and the random salt value (using the device's private key, such as the ECDSA algorithm). This signature is used to verify the integrity and origin of the request. Session key negotiation then occurs, generating a temporary session key used to encrypt the data and ensure confidentiality during transmission. Specifically, the X25519 algorithm is used to generate a temporary session key, which is then encapsulated with the public key provided by the server. The encapsulated key is appended to the packet header, resulting in the encapsulated session key. Finally, data encryption is performed, using the AES-GCM algorithm to encrypt the serialized binary stream and the session key to encrypt the serialized data, ensuring confidentiality and integrity during transmission. This results in an encrypted packet. That is, the business request includes: encrypted operation parameters, encapsulated session key, signature and salt value, etc.

[0049] Accordingly, the server performs decryption, first decrypting the session key, extracting the encapsulated session key from the request, and decapsulating the session key using the server's private key to obtain the actual session key. It then decrypts the operation parameters, extracting the encrypted operation parameters from the request, and decrypting the ciphertext using the decapsulated session key to obtain the original binary stream. The server then extracts the random salt value provided by the client from the decrypted data. The server then recalculates the hash value for the decrypted binary stream (operation parameters), using the client's public key to verify that the signature matches the calculated hash value. The server also verifies that the salt value matches the salt provided in the request to ensure the data has not been tampered with. If the signature verification passes and the salt value matches, the operation parameters have not been tampered with during transmission and are from a legitimate client. The server can then proceed with its business logic. The client ensures the integrity and confidentiality of the request parameters during transmission through operations such as data serialization, parameter fingerprint generation, session key generation, and data encryption. After decryption, the server verifies the fingerprint to further ensure that the data has not been tampered with, thereby enhancing communication security, preventing data leakage and man-in-the-middle attacks, and ensuring the legitimacy and reliability of business operations.

[0050] In some specific embodiments, after obtaining a service request sent by a client, the process further includes: comparing the address of the client requesting the pre-authorization token with the address of the client requesting the service; and based on the comparison result, determining whether there is an address discrepancy. If so, intercepting the service request. This address comparison prevents token hijacking and replay attacks. Specifically, by comparing the client address (e.g., IP address) of the pre-authorization token request with the client address of the service request, it is possible to verify whether the requests originate from the same client. If the two addresses are inconsistent, the pre-authorization token may have been hijacked and used for requests initiated by other clients. Intercepting such requests effectively prevents the token from being used illegally. Replay attacks are also prevented. Address consistency verification ensures that even if an attacker obtains the pre-authorization token, they cannot initiate requests from other addresses (such as a proxy server or malicious device). The token is valid only from the original client address. Furthermore, even if an attacker obtains the token, they cannot use it to launch attacks from other devices or network locations, significantly limiting the potential for attacks.

[0051] In some specific embodiments, the server is configured to check the business logic of the operation parameters in the service request before executing the service operation based on the operation parameters. Specifically, the server performs a business logic check on the decrypted parameters, such as to ensure that the transfer amount cannot be a negative value. This check further prevents malicious users or attackers from tampering with request parameters to perform illegal operations, such as attempting to transfer a negative amount. It also allows for timely correction of user errors, reducing errors and anomalies that occur when the system executes business logic, and improving system stability and reliability.

[0052] In some specific implementations, the access frequency of the client to the target business interface can be further counted to obtain the access frequency threshold corresponding to the target business interface; if the access frequency is greater than the access frequency threshold, the business request of the client is intercepted. In related technologies, scattered API endpoints make it difficult to uniformly implement policies such as rate limiting and input verification. This application manages requests uniformly through UUID endpoints, and the access frequency can be the number of visits per minute. If the access frequency is greater than the access frequency threshold, the client may be conducting an attack, brute force cracking, or other malicious behavior. By counting the access frequency of the client to the target business interface and comparing it with the preset access frequency threshold, if the access frequency exceeds the threshold, the system will intercept the client's business request, which can effectively protect system resources.

[0053] In some specific implementations, the request frequency of the client can be further counted, and the request frequency threshold can be determined based on the credit rating of the client; if the request frequency is greater than the request frequency threshold, the service request is intercepted. The request frequency can be the number of accesses per minute. A request frequency greater than the request frequency threshold may be due to a program error or malicious exploitation, or abuse of interface resources, resulting in excessive system load, which can pose a threat to system stability. Therefore, by counting the frequency of client accesses to the target service interface and comparing it with a preset access frequency threshold, if the access frequency exceeds the threshold, the system will intercept the client's service request, which can effectively limit the client's request rate, thereby protecting system resources and ensuring service stability and availability.

[0054] Furthermore, after obtaining the execution result corresponding to the business request; if the execution result is an abnormal result of failure to decrypt the business request, the request frequency threshold is lowered. Decryption failure means that the server cannot successfully decrypt the operation parameters in multiple attempts. The reasons for this phenomenon may be tampering with the encrypted data, the client using the wrong encryption key, malicious attack attempts, and device fingerprint or signature verification failure. When abnormal behaviors such as continuous decryption failures are detected, the request rate of the client can be immediately reduced, for example, from 100 requests / minute to 10 requests / minute; at the same time, the blacklist is recorded. If the abnormal behavior of the client continues to occur, its IP address or device fingerprint is recorded in the blacklist to restrict its access rights. The HTTP 429 status code (Too Many Requests) is returned to the client that exceeds the threshold, informing the client that the request is too frequent.

[0055] The semantic-free HTTP request secure interaction method based on a random dynamic universal unique identifier disclosed in this application mainly includes the following designs: a dynamic token system and a semantic-free request protocol, strong cryptographic binding of request intent, and centralized defense and lifecycle management of a unified security pipeline.

[0056] The dynamic UUID token system and semantic-free request protocol aim to build a new HTTP interaction protocol based on dynamic UUIDs, completely eliminating the business logic exposure risks of traditional semantic interfaces. For example, the UUID uses the version 4 random generation algorithm (RFC 4122), ensuring that attackers cannot deduce resource relationships from the URL structure. A two-phase token negotiation mechanism involves applying for a one-time pre-authorization token during the pre-authorization phase. During the execution phase, the server issues an execution token bound to the operation intent. The execution token's validity period is longer than the pre-authorization token's, but it can be reduced, thereby reducing the success rate of abnormal attacks. This means that replacing semantic paths with random paths eliminates the risk of interface resource exposure. The two-phase token negotiation (pre-authorization + execution phases) dynamically binds access tokens to specific operation requests, ensuring that the path and permissions for each request are independently generated and unpredictable.

[0057] Among them, the cryptographic strong binding of operation intent is to solve the problem of disconnection between token mechanism and operation intent, bind operation parameters and execution token, and the client uses a temporarily generated key pair to encrypt the original operation parameters into an irreversible ciphertext payload, and generates the intent summary together with the device fingerprint (such as IP + hardware ID) hash value. The server performs token validity verification and intent Figure 1 Consistency verification triggers an alert if the intent discrepancy rate exceeds a preset threshold. Encrypting the client's original request parameters into irreversible ciphertext and combining it with the device fingerprint to generate a unique hash digest ensures that the token is only valid when it matches the preset encrypted intent, solving the problem of disconnecting identity authentication and operation authorization at a cryptographic level.

[0058] Centralized defense within a unified security pipeline addresses the fragmentation of security policies by building a global security control pipeline. This involves unified ingress traffic control, forcing all requests to be routed to the / {uuid} endpoint. This allows for dynamic rate limiting, such as elastic throttling based on client reputation scores (historical request compliance rates and IP threat intelligence), reducing the request rate for abnormal clients to 1 / 50 of the normal rate. Context-aware authentication, for example, verifies the consistency of device geolocation and request time windows with historical behavior patterns in real time, triggering secondary authentication when deviations from baseline values exceed 15%. Furthermore, full-chain audit tracking, such as the use of blockchain technology to create an immutable audit log that records the complete lifecycle of each UUID token (generation, use, and destruction), meets compliance traceability requirements. Centralized implementation of defense strategies such as dynamic rate limiting and context-aware authentication eliminates the fragmentation of multi-endpoint protection through unified traffic management, achieving complete security policy coverage.

[0059] Lifecycle management is a multi-layered defense mechanism designed to address the risks of long-lived tokens and future security threats. For example, a configurable validity period allows for automatic expiration upon timeout, and immediate self-destruction after a successful call, prohibiting reuse (server-side memory uses a LRU eviction policy with a maximum residency time of ≤180 seconds).

[0060] Quantum-safe encryption can also be employed. For example, token signatures employ a hybrid encryption mode combining elliptic curve algorithms and post-quantum cryptography. Furthermore, the keys for encryption operation parameters are dynamically generated using a quantum random number generator. This hybrid encryption mode leverages not only the efficiency of elliptic curve algorithms but also the quantum-resistant nature of post-quantum cryptography, ensuring data security even in the quantum computing era. The keys generated by the quantum random number generator are more random and unpredictable, further enhancing the security of encryption operations and effectively preventing key cracking and data tampering. Quantum-resistant encryption can protect against future quantum threats from automated attacks.

[0061] Through the synergy of the above four directions, the key defects of traditional API security mechanisms are systematically addressed: First, the dynamic token and path decoupling mechanism eliminates the risks of interface semantic exposure and token replay attacks, ensuring that the path and permissions of each request are unpredictable; second, the cryptographic mandatory binding of operation intentions realizes the atomic association between identity authentication and operation authorization from the algorithm level, completely eliminating the possibility of middleman tampering and unauthorized operations; third, the global security policy entry eliminates logical vulnerabilities caused by inconsistent multi-endpoint protection through traffic normalization and centralized policy control; finally, the quantum-safe micro-lifecycle system uses ultra-short token lifetime and quantum-resistant encryption to provide dual defense against the efficiency dependence of automated attack tools and future quantum threats.

[0062] The present application discloses a specific service request interaction method, which is applied to a client. The method may include the following steps:

[0063] Sending a service request to the gateway; the path in the service request is a non-semantic random dynamic path, and the random dynamic path is generated by the gateway and sent to the client;

[0064] So that the gateway can extract the pre-authorization token from the business request, verify the pre-authorization token, and if the verification is successful, send the business request to the corresponding server; the pre-authorization token is a token with an expiration date applied by the client to the server; the server is used to generate an execution token according to the business request, and verify the execution token before executing the business operation according to the operation parameters in the business request.

[0065] Specifically, the above-mentioned client is also used to preprocess the initial parameters to obtain the operation parameters, and generate a business request based on the pre-authorization token and the operation parameters; and send a pre-authorization token request to the server and receive the pre-authorization token sent by the server; the pre-authorization token request includes the device fingerprint and the current timestamp.

[0066] For the specific process of the above method, please refer to the corresponding content disclosed in the above embodiment, which will not be repeated here.

[0067] The present application also discloses a specific service request interaction method, which is applied to a server. The method may include the following steps:

[0068] Obtaining a pre-authorization token application request sent by a client, generating a pre-authorization token including a validity period and feeding it back to the client, so that the client can generate a service request based on the pre-authorization token;

[0069] Obtain the service request forwarded by the gateway after verifying the pre-authorization token; the path in the service request is a non-semantic random dynamic path, which is generated by the gateway and sent to the client;

[0070] Generate an execution token according to the operation parameters in the business request;

[0071] The execution token is verified before executing the business operation, and after the execution token is verified, the business operation is executed according to the operation parameters.

[0072] In some specific embodiments, generating an execution token based on the operation parameters in the business request includes: generating an execution token based on a hash value of the operation parameters in the business request and a universally unique identification code; and configuring the validity period of the execution token to expire immediately after execution.

[0073] In some specific embodiments, before executing the business operation according to the operation parameters, it also includes: checking the business logic of the operation parameters; the business logic includes any one or more of data format check, data range check, logical relationship check between data, and business sequence check. That is, the server is used to check the business logic of the operation parameters before executing the business operation according to the operation parameters in the business request. That is, the server will perform a business logic check on the decrypted parameters, such as the transfer amount cannot be a negative value. Through this check, it can further prevent malicious users or attackers from performing illegal operations by tampering with the request parameters, such as attempting to transfer a negative amount. It can also correct the user's erroneous operations in a timely manner, reduce errors and anomalies that occur when the system executes business logic, and improve the stability and reliability of the system.

[0074] For the specific process of the above method, please refer to the corresponding content disclosed in the above embodiment, which will not be repeated here.

[0075] Correspondingly, the embodiment of the present application also discloses a service request interaction system, such as Figure 3 , including the above-mentioned gateway (dynamic entry gateway), client and server. The client is mainly responsible for generating device fingerprints, applying for pre-authorization tokens, encrypting operation parameters, submitting execution requests, and initiating requests using dynamic UUID paths. The gateway is responsible for generating dynamic UUID paths, resolving requests, routing distribution, traffic cleaning, and global security policy management. The server is responsible for generating pre-authorization tokens, verifying execution tokens, decrypting request parameters, executing business logic, and managing token lifecycles and security policies. The dynamic entry gateway can adapt to multiple API protocols and can integrate existing systems without modifying business code. It also supports flexible expansion of encryption algorithms or verification strategies.

[0076] Accordingly, an embodiment of the present application further discloses a service request interaction device, which is applied to a gateway and includes:

[0077] A request acquisition module is used to acquire a service request sent by a client; the path in the service request is a non-semantic random dynamic path, and the random dynamic path is generated by the gateway and sent to the client;

[0078] A token extraction module is used to extract a pre-authorization token from the service request; the pre-authorization token is a token including a validity period requested by the client from the server;

[0079] The verification module is used to verify the pre-authorization token. If the verification is successful, the service request is sent to the corresponding server so that the server can generate an execution token according to the operation parameters in the service request and verify the execution token before executing the service operation according to the operation parameters.

[0080] Through the description of the above implementation methods, those skilled in the art can clearly understand that the method according to the above embodiment can be implemented by means of software plus the necessary general hardware platform, and of course it can also be implemented by hardware, but in many cases the former is a better implementation method.

[0081] An embodiment of the present application further provides an electronic device, comprising a memory and a processor, wherein the memory stores a computer program, and the processor is configured to run the computer program to execute the steps in any of the above-mentioned service request interaction method embodiments.

[0082] An embodiment of the present application further provides a computer-readable storage medium, in which a computer program is stored. The computer program is configured to execute the steps of any of the above-mentioned service request interaction method embodiments when running.

[0083] In an exemplary embodiment, the computer-readable storage medium may include, but is not limited to, various media that can store computer programs, such as a USB flash drive, a read-only memory (ROM), a random access memory (RAM), a mobile hard disk, a magnetic disk, or an optical disk.

[0084] An embodiment of the present application further provides a computer program product, which includes a computer program. When the computer program is executed by a processor, the steps in any of the above-mentioned service request interaction method embodiments are implemented.

[0085] An embodiment of the present application further provides another computer program product, including a non-volatile computer-readable storage medium, wherein the non-volatile computer-readable storage medium stores a computer program, and when the computer program is executed by a processor, the steps of any of the above-mentioned service request interaction method embodiments are implemented.

[0086] Professionals may further appreciate that the units and algorithm steps of each example described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, computer software, or a combination of the two. In order to clearly illustrate the interchangeability of hardware and software, the above description has generally described the components and steps of each example according to their functions. Whether these functions are performed in hardware or software depends on the specific application and design constraints of the technical solution. Professionals and technicians may use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.

[0087] The above is a detailed introduction to a service request interaction method provided by this application. Specific examples are used herein to illustrate the principles and implementation methods of this application. The description of the above embodiments is only intended to help understand the method and core ideas of this application. It should be noted that, for those skilled in the art, without departing from the principles of this application, several improvements and modifications can be made to this application, and these improvements and modifications also fall within the scope of protection of this application.< / uuid> < / uuid> < / uuid>

Claims

1. A service request interaction method, characterized in that: Applied to gateways, including: Obtaining a service request sent by a client; the path in the service request is a non-semantic random dynamic path, and the random dynamic path is generated by the gateway and sent to the client; Extracting a pre-authorization token from the service request; the pre-authorization token is a token including a validity period that the client requests from the server; The pre-authorization token is verified. If the verification is successful, the service request is sent to the corresponding server so that the server can generate an execution token according to the operation parameters in the service request and verify the execution token before executing the service operation according to the operation parameters.

2. The service request interaction method according to claim 1, characterized in that: Before obtaining the service request sent by the client, it also includes: Obtaining an initial service request sent by the client; the path corresponding to the initial service request is a semantic path; A non-semantic random dynamic path corresponding to the semantic path is generated using a universal unique identifier, and the random dynamic path is sent to the client, so that the client initiates the service request according to the random dynamic path.

3. The service request interaction method according to claim 1, characterized in that: Verifying the pre-authorization token includes: Determine whether the pre-authorization token has expired and whether the pre-authorization token is used for the first time; If the pre-authorization token has expired and / or it is not the first time the pre-authorization token is used, the pre-authorization token verification fails.

4. The service request interaction method according to claim 3, characterized in that: After the pre-authorization token verification fails, the method further includes: A request cooling period for the client is triggered according to the cooling period, and no service request from the client is processed during the request cooling period.

5. The service request interaction method according to claim 1, characterized in that: Before obtaining the service request sent by the client, it also includes: Obtaining a pre-authorization token request sent by the client; the pre-authorization token request includes a device fingerprint and a current timestamp; Forwarding the pre-authorization token request to the server, so that the server generates a pre-authorization token based on the random universal unique identifier, the device fingerprint and the current timestamp through hashing, and configures a validity period for the pre-authorization token; Receive the pre-authorization token and validity period information sent by the server, and forward the pre-authorization token and validity period information to the client.

6. The service request interaction method according to claim 5, characterized in that: After obtaining the business request sent by the client, it also includes: Comparing the address of the client requesting the pre-authorization token with the address of the client requesting the service; Determine whether there is an address deviation anomaly based on the comparison result, and if so, intercept the service request.

7. The service request interaction method according to claim 1, characterized in that: Also includes: Counting the access frequency of the client to the target service interface, and obtaining the access frequency threshold corresponding to the target service interface; If the access frequency is greater than the access frequency threshold, the service request of the client is intercepted.

8. The service request interaction method according to any one of claims 1 to 7, characterized in that: Also includes: Counting the request frequency of the client and determining a request frequency threshold according to the credit rating of the client; If the request frequency is greater than the request frequency threshold, the service request is intercepted.

9. The service request interaction method according to claim 8, characterized in that: Also includes: Obtaining the execution result corresponding to the business request; If the execution result is an abnormal result of failure in decryption of the service request, the request frequency threshold is lowered.

10. A service request interaction method, characterized in that: Applied to the server, including: Obtaining a pre-authorization token application request sent by a client, generating a pre-authorization token including a validity period and feeding it back to the client, so that the client can generate a service request based on the pre-authorization token; Obtain the service request forwarded by the gateway after verifying the pre-authorization token; the path in the service request is a non-semantic random dynamic path, which is generated by the gateway and sent to the client; Generate an execution token according to the operation parameters in the business request; The execution token is verified before executing the business operation, and after the execution token is verified, the business operation is executed according to the operation parameters.

11. The service request interaction method according to claim 10, characterized in that: Generating an execution token according to the operation parameters in the service request includes: Generate an execution token based on a hash value of the operation parameter in the business request and a universally unique identifier; The validity period of the execution token is configured to expire immediately after execution.

12. The service request interaction method according to claim 10, characterized in that: Before executing the business operation according to the operation parameters, the method further includes: Check the business logic of the operation parameters; the business logic includes any one or more of data format check, data range check, logical relationship check between data, and business sequence check.

13. An electronic device, characterized in that: include: Memory, used to store computer programs; A processor is configured to execute the computer program to implement the service request interaction method according to any one of claims 1 to 9, or the service request interaction method according to any one of claims 10 to 12.

14. A computer-readable storage medium, characterized in that Used to store computer programs; wherein when the computer program is executed by the processor, it implements the service request interaction method described in any one of claims 1 to 9, or the service request interaction method described in any one of claims 10 to 12.

15. A computer program product, characterized in that The invention comprises a computer program, which, when executed by a processor, implements the service request interaction method according to any one of claims 1 to 9, or the service request interaction method according to any one of claims 10 to 12.

Images