Protocol authentication method, device, equipment, storage medium and program product

Abstract

This application provides a protocol authentication method applicable to the field of financial technology. The method includes: in response to receiving a Model Context Protocol (MCP) request, extracting information from the MCP request to obtain the request path and Internet Protocol (IP) address; if the request path is not in a preset path whitelist but the IP address is in a preset address whitelist, performing type identification based on the request features indicated by the MCP request and preset identification rules to obtain the request type, wherein the identification rules indicate the correspondence between multiple request types and their respective matching request features; and invoking an authentication method matching the request type to authenticate the MCP request, obtaining an authentication result. This application also provides a protocol authentication device, equipment, storage medium, and program product.

Description

Technical Field

[0001] This application relates to the field of financial technology, and more specifically to a protocol authentication method, apparatus, device, medium, and program product. Background Technology

[0002] Protocol authentication is an authentication mechanism embedded in a specific communication protocol. It is a core means of ensuring the security of data transmission. Model context protocol is an application layer communication protocol designed specifically for the interaction between large model agents and external tools. It features data transmission, asynchronous tool callbacks, and context dependencies.

[0003] Traditional protocol authentication technologies include single authentication schemes, multi-factor authentication schemes, and long-connection authentication schemes. However, they are not well adapted to long-connection authentication for model context protocols, have excessive overhead for repeated authentication, and suffer from significant authentication delays. Summary of the Invention

[0004] In view of the above problems, this application provides a protocol authentication method, apparatus, device, storage medium, and program product.

[0005] According to a first aspect of this application, a protocol authentication method is provided, comprising: in response to receiving a Model Context Protocol (MTP) request, extracting information from the MTP request to obtain a request path and an Internet Protocol (IP) address; if the request path is not in a preset path whitelist but the IP address is in a preset address whitelist, performing type identification based on the request features indicated by the MTP request and preset identification rules to obtain a request type, wherein the identification rules indicate the correspondence between multiple request types and their respective matching request features; and invoking an authentication method matching the request type to authenticate the MTP request to obtain an authentication result.

[0006] According to an embodiment of this application, when the request type is a tool callback, the authentication method matching the request type is invoked to authenticate the Model Context Protocol request, and the authentication result includes: decrypting the callback token in the Model Context Protocol request, extracting the authentication key, timestamp, and random number; performing timeliness verification based on the difference between the timestamp and the current time; if the timeliness verification passes, performing anti-replay verification on the random number based on pre-stored historical random numbers; if the anti-replay verification passes, invoking the standard key authentication process to verify the validity of the authentication key; if the validity verification passes, performing authorization verification on the calling tool indicated by the Model Context Protocol request based on a pre-stored list of authorized tools, and obtaining the authentication result, wherein the list of authorized tools indicates the scope of tool authorization.

[0007] According to an embodiment of this application, when the request type is a request to establish, the authentication method matching the request type is invoked to authenticate the Model Context Protocol request, and the authentication result includes: if the authentication key indicated by the Model Context Protocol request is not in a pre-stored invalid key cache but is in a pre-stored valid key cache, validity verification is performed based on the activation status and usage time of the authentication key; if the validity verification passes, service permission verification is performed based on the service identifier matching the authentication key and the target service identifier indicated by the Model Context Protocol request; if the authentication key is not in an invalid key cache or not in a valid key cache, the authentication key is stored in the invalid key cache.

[0008] According to an embodiment of this application, when the request type is data transmission, the authentication method matching the request type is invoked to authenticate the Model Context Protocol request, and the authentication result includes: extracting session information from the Model Context Protocol request, the session information including the session validity period; and verifying the session validity based on the current time and the session validity period.

[0009] According to an embodiment of this application, if the authentication result is successful, the method further includes: extracting the authentication information indicated by the request header in the Model Context Protocol request and removing the authentication information; generating encrypted authentication information for service node authentication through a gateway, wherein the encrypted authentication information includes at least one of user identifier, service identifier, request timestamp, and signature; and converting the request path indicated by the Model Context Protocol request into a backend service path through a gateway based on a preset protocol format.

[0010] According to an embodiment of this application, when the authentication result is passed and the request type is data transmission, the method further includes: when the difference between the current time and the last active time indicated by the model context protocol request is less than a preset threshold, using an asynchronous processing thread to update the last active time to the current time, and extending the session validity period under the constraint of the maximum valid time.

[0011] According to an embodiment of this application, the method further includes: storing access logs to a database using an asynchronous log channel, wherein the access logs include at least one of user identifier, service identifier, request path, client address, request type, and authentication method.

[0012] According to embodiments of this application, the request features include at least one of authentication key, session identifier, callback token, and request path identifier.

[0013] A second aspect of this application provides a protocol authentication apparatus, comprising: an extraction module, configured to extract information from a Model Context Protocol (MCP) request in response to receiving such a MCP request, to obtain a request path and an Internet Protocol (IP) address; a first authentication module, configured to perform type identification based on request features indicated by the MCP request and preset identification rules, to obtain a request type, wherein the identification rules indicate the correspondence between multiple request types and their respective matching request features; and a second authentication module, configured to invoke an authentication method matching the request type to authenticate the MCP request, and obtain an authentication result.

[0014] A third aspect of this application provides an electronic device comprising: one or more processors; and a memory for storing one or more computer programs, wherein the one or more processors execute the one or more computer programs to implement the steps of the method described above.

[0015] A fourth aspect of this application also provides a computer-readable storage medium having a computer program or instructions stored thereon, which, when executed by a processor, implement the steps of the above-described method.

[0016] The fifth aspect of this application also provides a computer program product, including a computer program or instructions that, when executed by a processor, implement the steps of the above-described method.

[0017] The above one or more embodiments have the following beneficial effects: In long-connection and high-concurrency scenarios of Model Context Protocol (MGP), in view of the problem that existing authentication technologies cannot be directly used for MGP, this application provides a multi-layer authentication method for MGP, which can receive and identify request types, select appropriate authentication paths according to request types to authenticate MGP requests, and effectively achieve efficient authentication of MGP. Attached Figure Description

[0018] The above-mentioned contents, other objects, features and advantages of this application will become clearer from the following description of embodiments with reference to the accompanying drawings, in which:

[0019] Figure 1 The illustrations depict application scenarios of protocol authentication methods, apparatuses, devices, media, and program products according to embodiments of this application.

[0020] Figure 2 A flowchart illustrating a protocol authentication method according to an embodiment of this application is shown schematically.

[0021] Figure 3This illustration schematically shows a multi-layer authentication flowchart of a protocol authentication method according to an embodiment of this application;

[0022] Figure 4 This illustration schematically shows another specific flowchart of a protocol authentication method according to an embodiment of this application;

[0023] Figure 5 This illustration schematically depicts a real-world application scenario of the protocol authentication method according to an embodiment of this application.

[0024] Figure 6 This schematically illustrates a structural block diagram of a protocol authentication device according to an embodiment of this application;

[0025] Figure 7 A block diagram schematically illustrates an electronic device suitable for implementing a protocol authentication method according to an embodiment of this application. Detailed Implementation

[0026] The embodiments of this application will now be described with reference to the accompanying drawings. However, it should be understood that these descriptions are exemplary only and are not intended to limit the scope of this application. In the following detailed description, numerous specific details are set forth to provide a thorough understanding of the embodiments of this application for ease of explanation. However, it will be apparent that one or more embodiments may be implemented without these specific details. Furthermore, descriptions of well-known structures and technologies are omitted in the following description to avoid unnecessarily obscuring the concepts of this application.

[0027] The terminology used herein is for the purpose of describing particular embodiments only and is not intended to limit the scope of this application. The terms “comprising,” “including,” etc., as used herein indicate the presence of the stated features, steps, operations, and / or components, but do not exclude the presence or addition of one or more other features, steps, operations, or components.

[0028] All terms used herein (including technical and scientific terms) have the meanings commonly understood by those skilled in the art, unless otherwise defined. It should be noted that the terms used herein are to be interpreted in a manner consistent with the context of this specification, and not in an idealized or overly rigid way.

[0029] When using expressions such as "at least one of A, B and C", they should generally be interpreted in accordance with the meaning that is commonly understood by those skilled in the art (e.g., "a system having at least one of A, B and C" should include, but is not limited to, a system having A alone, a system having B alone, a system having C alone, a system having A and B, a system having A and C, a system having B and C, and / or a system having A, B and C, etc.).

[0030] The difficulties in applying traditional authentication technologies to the Model Context Protocol (MCP) can be summarized as follows:

[0031] (1) Insufficient adaptability to long connections of the model context protocol. If the complete authentication process (such as database query and key verification) is executed every time a tool is called, the frequent tool calls during data transmission will lead to huge server overhead and authentication delay. Furthermore, since traditional authentication schemes are usually stateless, while MCP's SSE long connection is essentially stateful, traditional schemes cannot efficiently and securely manage the lifecycle of these data transmissions.

[0032] (2) The callback authentication mechanism is missing or inefficient. The existing solution cannot effectively bind the callback to the original request context. If an independent authorization mechanism is designed for the callback, it will greatly increase the complexity of the system.

[0033] (3) Traditional synchronous, single sign-on authentication mode cannot handle the problems of massive first connection requests and continuous session verification.

[0034] The embodiments of this application provide a protocol authentication method that performs multi-layer authentication for the Model Context Protocol. It achieves multi-layer protection and prevents unauthorized access through layered authentication, improves concurrency performance through asynchronous authentication processing, and provides a security enhancement mechanism for the MCP protocol to ensure the security and traceability of the entire authentication chain, thus providing an efficient authentication mechanism for the Model Context Protocol.

[0035] Figure 1 The diagram illustrates an application scenario of the protocol authentication method according to an embodiment of this application.

[0036] like Figure 1 As shown, application scenario 100 according to this embodiment may include a first terminal device 101, a second terminal device 102, a third terminal device 103, a network 104, and a server 105. The network 104 serves as a medium for providing a communication link between the first terminal device 101, the second terminal device 102, the third terminal device 103, and the server 105. The network 104 may include various connection types, such as wired or wireless communication links, or fiber optic cables, etc.

[0037] Users can use the first terminal device 101, the second terminal device 102, and the third terminal device 103 to interact with the server 105 via the network 104 to receive or send messages, etc. Various communication client applications can be installed on the first terminal device 101, the second terminal device 102, and the third terminal device 103, such as shopping applications, web browser applications, search applications, instant messaging tools, email clients, social media platform software, etc. (for example only).

[0038] The first terminal device 101, the second terminal device 102, and the third terminal device 103 can be various electronic devices with displays and support web browsing, including but not limited to smartphones, tablets, laptops, and desktop computers.

[0039] Server 105 can be a server that provides various services, such as a backend management server that supports websites browsed by users using the first terminal device 101, the second terminal device 102, and the third terminal device 103 (this is just an example). The backend management server can analyze and process data such as received user requests, and feed back the processing results (such as web pages, information, or data obtained or generated according to user requests) to the terminal devices.

[0040] It should be noted that the protocol authentication method provided in this application embodiment can generally be executed by server 105. Correspondingly, the protocol authentication device provided in this application embodiment can generally be located in server 105. The protocol authentication method provided in this application embodiment can also be executed by a server or server cluster that is different from server 105 and capable of communicating with the first terminal device 101, the second terminal device 102, the third terminal device 103, and / or server 105. Correspondingly, the protocol authentication device provided in this application embodiment can also be located in a server or server cluster that is different from server 105 and capable of communicating with the first terminal device 101, the second terminal device 102, the third terminal device 103, and / or server 105.

[0041] It should be understood that Figure 1 The number of terminal devices, networks, and servers shown is merely illustrative. Depending on implementation needs, any number of terminal devices, networks, and servers can be included.

[0042] The following will be based on Figure 1 The described scene, through Figures 2-5 The protocol authentication method according to the embodiments of this application will be described in detail.

[0043] Figure 2 A flowchart illustrating a protocol authentication method according to an embodiment of this application is shown schematically. Figure 3 This schematically illustrates a multi-layered authentication flowchart of a protocol authentication method according to an embodiment of this application. Figure 4 This illustration shows another specific flowchart of a protocol authentication method according to an embodiment of the present application.

[0044] Combination Figures 2-4 The protocol authentication method in this embodiment includes operations S210 to S230.

[0045] In operation S210, in response to receiving a Model Context Protocol (MCP) request, information is extracted from the MCP request to obtain the request path and Internet Protocol (IP) address.

[0046] According to embodiments of this application, the Model Context Protocol (MCP) is a standardized protocol for secure communication between AI (Artificial Intelligence) models and external tools and data sources. It defines how models request tools to execute, obtain context information, and process callback results. The MCP protocol specification is a standard format that defines communication between AI models and external tools.

[0047] An Internet Protocol address (IP address) is a network identifier for each device on the Internet, used to locate network devices and enable data transmission between devices.

[0048] For example, operation S210 may include: receiving an MCP protocol request sent by a client, parsing the request header and request body in the MCP protocol request, and extracting the request path and IP address respectively. For example, the request path is extracted from the request header using regular expressions, and the IP address is extracted from the “X-Forwarded-For”, “X-Real-IP header”, or connection information. The request path is used for path whitelist checking and service discovery, and the IP address is used for address whitelist checking.

[0049] The extracted information may include at least one of the following: request path, client IP address, authentication key, session identifier, callback token, connection identifier, and request feature identifier.

[0050] In operation 220, if the request path is not in the preset path whitelist and the IP address is in the preset address whitelist, the request type is identified based on the request characteristics indicated by the MCP request and the preset identification rules.

[0051] According to embodiments of this application, the identification rules indicate the correspondence between multiple request types and their respective matching request features. The request features include at least one of authentication keys, session identifiers, callback tokens, and request path identifiers, so as to provide a comprehensive basis for request type identification and improve the accuracy of request type identification.

[0052] For example, the authentication key can be extracted from the "key" field in the URL request parameters of the MCP protocol request, such as "123456" in / mcp / device01 / query?key=123456; if there is no key field in the request parameters of the MCP protocol request, it is extracted from the "Authorization" header of the MCP protocol request header; if there is no valid authentication key in the "Authorization" header, it is extracted from the custom request header "X-Auth-Key", which is an authentication header customized for the MCP protocol scenario; if no valid key is extracted, an authentication failure response is returned directly.

[0053] A URL (Uniform Resource Locator) is a unique access address for a resource (such as an interface or file) on the Internet. Clients use URLs to accurately locate the target resource of a gateway / backend service and initiate a request.

[0054] The session identifier is extracted from the request parameter "sessionId (user identifier)" or "X-Session-Id" header; the callback token is extracted from the "X-Callback-Token" header; only tool callback requests carry the callback token; the connection identifier is a unique identifier generated based on the client IP and timestamp; the request path identifier is used to check if the request header contains "text / event-stream" and to check if the path contains the " / sse" suffix.

[0055] For example, if the request path is in the preset path whitelist, authentication is returned directly; if the request path is not in the preset path whitelist and the IP address is not in the preset address whitelist, authentication is returned directly and the reason for failure is recorded.

[0056] For example, the identification rules include: if the extracted information contains an authentication key (authKey), but does not contain a session identifier (sessionId) or callback token, and the request header does not contain "text / event-stream", the request type is a normal HTTP request; if the extracted information contains an authentication key (authKey), the request header contains "text / event-stream" or the path contains the " / sse" suffix, and the session identifier (sessionId) does not exist, the request type is an establishment request; if the extracted information contains a session identifier (sessionId) but does not contain an authentication key (authKey), the request type is a data transfer request; if the extracted information contains a callback token, and may also contain an authentication key (authKey) or a session identifier (sessionId), the request type is a tool callback request; if the extracted information does not contain an authentication key (authKey), a session identifier (sessionId), and a callback token (callbackToken), or is invalid, then the request type is an invalid request, i.e., there are no valid credentials.

[0057] In operation 230, the authentication method matching the request type is invoked to authenticate the Model Context Protocol request, and the authentication result is obtained.

[0058] According to embodiments of this application, the request type characterizes different communication characteristics of MCP protocol requests, including ordinary HTTP requests or request establishment, data transmission requests, tool callback requests, and invalid requests.

[0059] For example, when the request type is a normal HTTP request or a request establishment, the standard key authentication method is invoked to authenticate the Model Context Protocol request; when the request type is a data transfer request, the session authentication method is invoked to authenticate the Model Context Protocol request; when the request type is a tool callback request, the callback token authentication method is invoked to authenticate the Model Context Protocol request; and when the request type is an invalid request, authentication failure is returned.

[0060] In long-connection and high-concurrency scenarios of the Model Context Protocol (MCP), to address the issues of traditional authentication technologies being unusable directly for MCP, having high authentication overhead, and exhibiting significant authentication latency, a multi-layered authentication method is provided for MCP through operations S210-S230. This method executes a layered authentication strategy, sequentially performing path whitelist checks, IP whitelist checks, and credential verification according to a preset priority order, employing a short-circuit strategy to improve efficiency. By receiving MCP requests and identifying the request type, and selecting an appropriate authentication path based on the request type to adaptively authenticate MCP requests, efficient authentication of MCP requests can be effectively achieved.

[0061] In the technical solution of this application, the user information (including but not limited to user personal information, user image information, user device information, such as location information) and data (including but not limited to data used for analysis, stored data, and displayed data) involved are all information and data authorized by the user or fully authorized by all parties. Furthermore, the collection, storage, use, processing, transmission, provision, disclosure, and application of related data all comply with relevant laws, regulations, and standards, take necessary confidentiality measures, do not violate public order and good morals, and provide corresponding operation entry points for users to choose to authorize or refuse.

[0062] In scenarios involving automated decision-making using personal information, the methods, devices, and systems provided in this application all offer users corresponding entry points for choosing to agree to or reject the automated decision-making results. If the user chooses to reject, the process proceeds to the expert decision-making stage. Here, "automated decision-making" refers to the activity of automatically analyzing and evaluating an individual's behavioral habits, interests, or economic, health, and credit status through computer programs, and then making a decision. Here, "expert decision-making" refers to the activity of making decisions by personnel who specialize in a particular field, possess specialized experience, knowledge, and skills, and have reached a certain level of professional expertise.

[0063] Combination Figure 3 In some embodiments, when the request type is a tool callback, the authentication method matching the request type is invoked to authenticate the model context protocol request, and the authentication result includes:

[0064] First, decrypt the callback token in the model context protocol request to extract the authentication key, timestamp, and random number.

[0065] According to an embodiment of this application, the authentication key can be the authentication key of the original request that initiates the tool callback, the timestamp can be the token generation timestamp, and the random number can be used to prevent replay attacks.

[0066] For example, when the tool callback request arrives at the gateway, the callback token is extracted from the request header, the token is decrypted using the system global key, and the original authentication information in the model context protocol request is extracted. The extracted information includes: the authentication key of the original request that initiated the tool callback, the service identifier accessed by the original request, the token generation timestamp, and the random number.

[0067] Then, timeliness verification is performed based on the difference between the obtained timestamp and the current time. If the timeliness verification passes, the random number is verified against replay based on the pre-stored historical random number. If the replay verification passes, the standard key authentication process is invoked to verify the validity of the authentication key.

[0068] For example, if the difference between the current time and the callback token timestamp exceeds 60 seconds, the request is rejected, and the timeliness verification is considered to have failed, preventing the token from being used after it expires. If the timeliness verification fails and / or the anti-replay verification fails, authentication failure is returned. If the timeliness verification passes, the random number is used to perform anti-replay verification based on the pre-stored historical random number, including: checking whether the random number has been recorded in the memory-type key-value pair database used to store historical random numbers. If it has been recorded, it means that the token has been used, and the request is rejected, i.e., the anti-replay verification has failed. If it has not been recorded, the random number is recorded and the verification continues.

[0069] For example, the validity period of the token can be configured as needed; for instance, it can be set to 60 seconds.

[0070] In some embodiments, when an MCP client requests to perform an operation that requires a tool callback (such as calling an external API or performing a database query), the callback token can be a one-time callback token generated by the gateway after the original request has been authenticated by a preset path whitelist and a preset address whitelist.

[0071] For example, the token generation algorithm includes: assembling plaintext data, which can be concatenated in a fixed format as "authKey+serviceId+timestamp+nonce", where authKey is the client's original authentication key, serviceId is the target service identifier, timestamp is the system timestamp when the token is generated, and nonce is a 32-byte random number; then, generating a callback token by encrypting the plaintext data, wherein the algorithm used to encrypt the plaintext data can be AES-256-GCM or other encryption algorithms, and the decryption result is Base64 encoded to generate the final token string as the callback token.

[0072] For example, the token validity period can be set to 60 seconds as needed, which is sufficient to cover the execution time of the tool callback, while limiting the time window for token abuse; the callback token in the Model Context Protocol request can be decrypted using the system key, which can be obtained from the configuration file or the key management service; the token can be added to the response header or response body of the Model Context Protocol request and returned to the MCP client.

[0073] Tool callback authentication refers to a dedicated authentication mechanism for tool callback scenarios in the MCP protocol. Through one-time callback tokens and context binding technology, it ensures that callback requests can be traced back to the original authentication information and inherit its scope of permissions.

[0074] If the timeliness verification and replay protection verification pass, the standard key authentication process is invoked to verify the validity of the authentication key; the standard key authentication process includes the following steps:

[0075] Step 1: Check the invalid key cache in the memory-based key-value pair database. The key format is auth:invalid:{keyHash}. If a match is found, return an authentication failure directly.

[0076] Step 2: Check the valid key cache in the memory-based key-value pair database. The key format is auth:key:{keyHash}. If a match is found, verify the key's validity. Verification methods include, but are not limited to, checking if the key is active or expired. If the key is valid, asynchronously update the last used time and the database record. If the key is invalid, add it to the invalid key cache.

[0077] According to embodiments of this application, asynchronous authentication processing refers to a non-blocking processing method that decouples the main authentication process from auxiliary operations (such as cache updates, log recording, and usage time updates), and the main authentication process can return the authentication result without waiting for the auxiliary operations to complete; reactive programming model refers to a programming paradigm based on data flow and change propagation.

[0078] For example, the last use time of asynchronous updates includes the main authentication process not waiting for the update operation to complete, and non-blocking updates are achieved through a reactive programming model; the reactive programming model can be implemented using a reactive non-blocking web framework, which supports backpressure control and non-blocking I / O operations.

[0079] Step 3: If the cache misses, query the database to retrieve the key information. If the key information does not exist in the database, the key is asynchronously cached as invalid; if the key information exists in the database, the validity of the key is verified and asynchronously cached in an in-memory key-value pair database.

[0080] Reduce latency during cold starts by loading authentication information for active users and frequently accessed services from the database into the cache.

[0081] For example, when an administrator modifies authentication information (such as revoking a key or updating permissions) through the management interface, the relevant cache is immediately cleared to ensure that the changes take effect instantly.

[0082] Step 4: Verify whether the service ID associated with the key matches the target service ID of the request to ensure service-level permission isolation.

[0083] Then, if the validity verification passes, the calling tool indicated by the Model Context Protocol request is authorized based on a pre-stored list of authorized tools to obtain the authentication result.

[0084] According to embodiments of this application, the list of licensed tools indicates the scope of tool licensing.

[0085] For example, if the requested tool is in the authorized tool list of the original service, authorization and authentication are performed, and an authentication result is obtained; if the requested tool is not in the authorized tool list of the original service, authentication failure is returned to prevent unauthorized access.

[0086] For example, if the validity verification fails, an authentication failure is returned.

[0087] For example, the original authentication key, user identifier, and service identifier are set into the current request context to ensure that the callback operation is executed within the original user's permissions; the tool list is stored in a database or configuration file, and the tool list contains the tool name and parameter restrictions allowed for callbacks for each service.

[0088] In the embodiments of this application, by performing timeliness verification, anti-replay verification, and validity verification on the callback token, business anomalies caused by token security issues are avoided, and the security, reliability, and compliance of communication interactions in callback scenarios are ensured; the one-time token and anti-replay mechanism of the tool callback prevent the callback request from being spoofed or replayed.

[0089] In some embodiments, when the request type is a request to establish, the authentication method matching the request type is invoked to authenticate the Model Context Protocol request, and the authentication result includes the following steps:

[0090] First, if the authentication key indicated by the Model Context Protocol request is not in the pre-stored invalid key cache but in the pre-stored valid key cache, validity verification is performed based on the activation status and usage time of the authentication key.

[0091] For example, when the request type is a request to establish a connection, that is, when the request is a normal HTTP request or an SSE connection establishment request; the format of the invalid key is "auth:invalid:{keyHash}", and the format of the valid key is "auth:key:{keyHash}"; if the authentication key indicated by the model context protocol request is not in the pre-stored invalid key cache but is in the pre-stored valid key cache, verify whether the key is active and whether it has expired. If it is active and has not expired, asynchronously update the last used time and the database record; otherwise, add the authentication key to the invalid key cache.

[0092] The SSE (Server-SentEvents) technical specification is a W3C standard that defines a one-way communication protocol for servers to push real-time data to clients. The MCP protocol is based on SSE to implement long-connection communication.

[0093] For example, if the authentication key indicated by the Model Context Protocol request is in a pre-stored invalid key cache, authentication failure is returned directly.

[0094] Then, if the validity verification passes, service authorization verification is performed based on the service identifier matched by the authentication key and the target service identifier indicated by the model context protocol request.

[0095] For example, during the service permission verification phase, the system checks whether the target service extracted from the request path matches the service identifier bound to the authentication key; if they do not match, the request is rejected and a "403 Forbidden" is returned to prevent the user from accessing service B using the key applied for for service A; if they match, the service permission verification is deemed successful, and the request is allowed to enter the subsequent business processing flow; if the user needs to access multiple services, a key must be applied for separately for each service.

[0096] For example, service permission verification includes, but is not limited to, verifying whether the service identifier associated with the verification key matches the target service identifier of the request, to ensure service-level permission isolation.

[0097] Then, if the authentication key is not in the invalid key cache or the valid key cache, the authentication key is stored in the invalid key cache.

[0098] For example, if the authentication key is not in the invalid key cache or the valid key cache, the database is further queried to obtain the authentication key information indicated by the Model Context Protocol Request; if the authentication key information indicated by the Model Context Protocol Request does not exist in the database, this key is asynchronously cached as an invalid key; if the authentication key information indicated by the Model Context Protocol Request exists in the database, the validity of the key information is verified and asynchronously cached in the in-memory key-value pair database.

[0099] In the embodiments of this application, by checking whether the requested target service matches the service identifier bound to the authentication key, fine-grained service access control can be achieved, realizing a one-to-one binding between the authentication key and the service identifier, eliminating the risk of unauthorized access, and ensuring the security and compliance of service access.

[0100] In some embodiments, when the request type is data transfer, the steps for authenticating the Model Context Protocol request by invoking an authentication method matching the request type and obtaining the authentication result are as follows:

[0101] First, extract the session information from the model context protocol request.

[0102] According to an embodiment of this application, when the request type is data transmission, that is, the request is an SSE data transmission request; the session information includes the session validity period.

[0103] SSE data transmission refers to a persistent connection session established based on server push event technology, used for continuous bidirectional communication between the client and server in the MCP protocol. The session includes information such as a unique session identifier, associated authentication key, creation time, expiration time, and last active time. For example, session information from a Model Context Protocol request can be queried from an in-memory key-value database. The session information is in the format "session:auth:{sessionId}". The session information may also include at least one of the following: associated authentication key, user identifier, service identifier, creation time, expiration time, and last active time.

[0104] Then, session validity is verified based on the current time and session validity period.

[0105] For example, session validity is verified based on the current time and session validity period to check whether the current time is within the session validity period.

[0106] In some embodiments, if the session validity verification result is passed, the method further includes: if the difference between the current time and the last active time indicated by the model context protocol request is less than a preset threshold, using an asynchronous processing thread to update the last active time to the current time, and extending the session validity period under the constraint of the maximum validity period.

[0107] For example, if the SSE session request is valid and auto-renewal is enabled, the following steps are performed:

[0108] Step 1: Check if the difference between the current time and the active time of the last session exceeds the threshold. The threshold can be set as needed, and the default value of the threshold can be set to 5 minutes.

[0109] Step 2: If the difference between the current time and the last active time of the session exceeds the threshold, then the last active time and expiration time of the session are updated asynchronously.

[0110] The extension of the expiration time is determined by the automatic renewal duration parameter. The default value of the automatic renewal duration parameter can be set to 1 hour, and it is ensured that the extended expiration time does not exceed the maximum TTL (maxTtlHours, maximum survival time). The default value of the maximum TTL can be set to 24 hours.

[0111] For example, it also includes an automatic session renewal mechanism. If the request type is SSE data transmission, the automatic renewal logic is triggered each time the connection is detected to automatically extend the session TTL and avoid the session expiring during the connection. Detecting connection activity includes: if the interval between the current time and the active time of the last session exceeds a threshold, it is determined that the connection is still active and the automatic renewal logic is triggered.

[0112] For example, the above renewal operation is executed asynchronously, without blocking the main authentication process, ensuring low latency for SSE data transmission.

[0113] For example, if the current time exceeds the session expiration timestamp, i.e. the session has expired, the system rejects subsequent data transmission requests and returns a 401 Unauthorized status code. The client needs to re-establish data transmission and authenticate using the original authentication key to obtain a new session ID.

[0114] For example, the system periodically cleans up expired session caches to free up storage space in the memory-based key-value database.

[0115] For example, the extension amount is controlled by configuration parameters. The default value of the extension amount can be set to 1 hour, but it cannot exceed the maximum TTL. The maximum TTL is 24 hours by default to prevent the session from being extended indefinitely.

[0116] Step 3: If the threshold is not exceeded, there is no need to update the last active time and expiration time of the session. Keep the original last active time and expiration time of the session unchanged, and determine that the session verification is successful.

[0117] For example, if the session is invalid or does not exist, an authentication failure is returned, requiring the client to re-establish the connection.

[0118] In the embodiments of this application, for the SSE long connection scenario of MCP method call, the above-mentioned session authentication mechanism can reduce the authentication overhead of each SSE data transmission, improve connection stability by 90%, and avoid connection interruption due to authentication expiration; at the same time, it has trusted interaction capability, and prevents session hijacking and man-in-the-middle attacks through session encryption storage and automatic renewal.

[0119] In some embodiments, if the authentication result is successful, the method further includes:

[0120] First, extract the authentication information indicated in the request header of the Model Context Protocol request and remove the authentication information.

[0121] According to embodiments of this application, authentication information may include at least one of authentication key, user identifier, service identifier, and connection identifier.

[0122] For example, the authentication key can be removed from the Model Context Protocol (MCP) request. For instance, if the MCP request URL is ` / mcp / device01 / query?key=123456&type=temp`, where the `key` carried in the URL is the plaintext authentication key for the client accessing the gateway, then the `key=123456` part needs to be removed, retaining only the business-related parameters. This ensures that authentication information is not transmitted in plaintext during the forwarding process, preventing it from being recorded or intercepted by intermediate nodes.

[0123] Then, based on the preset protocol format, the request path indicated by the model context protocol request is converted into the backend service path through the gateway.

[0124] For example, for SSE connection requests, ensure that the session identifier remains valid after path rewriting and is correctly returned to the client in the response.

[0125] For example, the request path is rewritten from the client-side format ( / mcp / {serviceId} / path) to the backend service format ( / path). For instance, assuming the URL for a model context protocol request is / mcp / device01 / query?key=123456&type=temp, after removing the plaintext authentication key, the request path is further rewritten, changing / mcp / device01 / query containing the service identifier to the backend service standard format / query. The final request forwarded to the backend is / query?type=temp, which simplifies the request format and adapts to the backend service interface specification.

[0126] The process by which the MCP gateway transforms the client request path into the backend service path when proxying requests is called dynamic path rewriting.

[0127] For example, for tool callback requests, the callback token is restricted to be transmitted via the request header and is prohibited from appearing in the URL to prevent the token from being cached or logged, thus preventing leakage.

[0128] Then, encrypted authentication information for service node authentication is generated through the gateway.

[0129] According to embodiments of this application, the encrypted authentication information includes at least one of a user identifier, a service identifier, a request timestamp, and a signature.

[0130] For example, after removing the original authentication information, an internal authentication header is generated through the gateway. The internal authentication header contains the following encrypted information: user identifier, service identifier, request timestamp, and signature. The encryption algorithm can be HMAC-SHA256 or other encryption algorithms. The key is a key shared between the gateway and the backend service. The internal authentication header adopts JWT format or a custom format. The backend MCP service can choose to verify the internal authentication header.

[0131] For example, encrypted authentication information is added to the internal request header of the Model Context Protocol for verification by the backend service.

[0132] In some embodiments, an "X-Internal-Auth" header field can be added to the internal request header to store encrypted authentication information, which is used by the backend service to verify the client's identity and the legitimacy of the request.

[0133] Then, access logs are recorded asynchronously and stored in the database.

[0134] For example, the access log includes at least one of the following: user identifier, service identifier, request path, client address, request type, and authentication method.

[0135] Based on this, asynchronous recording of access information is implemented, which facilitates data retention and traceability.

[0136] Finally, the request is allowed to proceed to the corresponding MCP backend service, where a reactive HTTP client is used for non-blocking forwarding.

[0137] For example, for a callback token request, after successful verification, the system restores the original authentication information, including the authentication key, user identifier, and service identifier, to the context of the current request; using the Context mechanism of the reactive programming model, it ensures that the context information is accessible throughout the entire request processing chain. Subsequent business logic such as access control and logging is executed based on the restored context, ensuring that the callback operation is within the original user's permission scope.

[0138] For example, the Context mechanism of the reactive programming model can be implemented based on the context mechanism of the reactive programming framework. This mechanism is a context passing capability unique to the reactive programming framework, which can safely and transparently pass the context information bound to the request in an asynchronous non-blocking data flow chain.

[0139] Meanwhile, all database and cache operations in this embodiment are implemented using non-blocking I / O, avoiding the thread blocking problem of synchronous I / O. For log processing scenarios, an asynchronous log channel is built through the merge mechanism of the reactive programming framework. The main request process only needs to send log events to the channel to continue execution, without waiting for the logs to be written to the disk. In addition, the framework's built-in backpressure control mechanism can automatically adjust the data flow rate and dynamically match the upstream and downstream processing capabilities in high-concurrency scenarios, effectively preventing system overload.

[0140] In the embodiments of this application, authentication information removal and encryption injection mechanisms are used during the dynamic path rewriting process to prevent credential leakage; non-blocking and high-concurrency support are ensured through reactive data stream collaborative communication.

[0141] According to embodiments of this application, when the SSE connection establishment request authentication is successful, the process for handling the successful authentication result of the Model Context Protocol request requires the following additional steps: generating a unique session identifier in UUID format to ensure global uniqueness and unpredictability; ensuring that the session identifier (sessionId) remains valid after path rewriting and is correctly returned to the client in the response.

[0142] A session identifier is bound to a specific service identifier when it is created. In a data transmission request, the system verifies whether the service identifier associated with the session identifier matches the target service of the request, so as to prevent attackers from accessing service B by using a session created for service A by spoofing the request path.

[0143] Create a session mapping in an in-memory key-value database with the following storage structure: KEY:sessionIdVALUE:{authKey (original authentication key),userId (user ID),serviceId (service ID),createdAt (creation time),expiresAt (expiration time),lastActivityAt (last active time)}. The core fields in the session mapping include the original authentication key, user ID, service ID, session creation time, session expiration time, and last active time. The initial value of the session expiration time is the current time plus the default TTL (Time-To-Live, effective lifespan), with a default TTL of 2 hours. The initial value of the last active time is the current time.

[0144] For example, the TTL of the session cache can be configured as needed, with a default value of 2 hours;

[0145] For example, a session identifier can be added to the response to notify the client to use the session identifier for authentication in subsequent requests.

[0146] According to an embodiment of this application, the session identifier is bound to a specific service identifier when it is created; in the data transmission request, the system verifies whether the service identifier associated with the session identifier matches the target service of the request, so as to prevent attackers from spoofing the request path.

[0147] In some embodiments, when the tool callback request is successfully authenticated, the process of processing the successful authentication result of the model context protocol request also needs to perform the following additional steps: record the original authentication context to the audit log; record the tool call information, including the tool name, call parameters, call time, etc., for subsequent auditing and tracing.

[0148] For example, for tool callback requests, complete information about the callback request is recorded in the audit log, including the original authentication key, user identifier, service identifier, callback tool name, callback parameters, execution result, etc.

[0149] In some embodiments, if the authentication request fails, a JSON response containing error codes and error information is generated; an HTTP status code is set according to the reason for failure; an authentication failure log is asynchronously recorded, containing detailed information such as the reason for failure, client IP, and request path, for security auditing and attack detection; and an error response is returned to the client.

[0150] According to the embodiments of this application, the system verifies whether the service identifier associated with the session identifier matches the target service of the request, which can prevent attackers from spoofing the request path; through log analysis tools, each tool callback can be traced back to the original MCP request that initiated it, which facilitates security auditing and problem investigation.

[0151] Figure 5 The diagram illustrates a real-world application scenario of the protocol authentication method according to an embodiment of this application, demonstrating the complete process of an MCP request being initiated by the client, authenticated via a gateway, and finally distributed to the corresponding backend service.

[0152] For example, the client layer defines three types of MCP request initiators and their corresponding authentication credentials supported by this application: ordinary HTTP requests initiated from AI clients, SSE connection requests initiated from long-connection clients, and tool callback requests initiated from tool callback clients. The MCP gateway layer is the core unit for request processing. Request types carry authentication information to the gateway, which sequentially performs authentication information extraction, request type identification, multi-layer authentication decision-making, asynchronous authentication, cache management, and security enhancement operations. Specifically, based on the request's protocol format and authentication credential type, the request type is determined; a multi-layer authentication decision-making strategy is adopted; the corresponding authentication path is selected according to the request type; based on the selected authentication path, authentication logic is executed asynchronously to avoid blocking the main request link during the authentication process and improve the gateway's concurrent processing capabilities; an intelligent caching strategy is used to manage cached data in the memory-based key-value pair database to reduce database access pressure; after authentication is completed, security enhancement operations such as session management, key cleanup, and path rewriting are performed to ensure the security of the request in the forwarding link.

[0153] Authentication credentials include two forms of authentication information: authentication keys and session identifiers. Authentication keys are long-term valid user identity identifiers, while session identifiers are short-term valid temporary access tokens.

[0154] The infrastructure layer is the basic support unit of the gateway, providing data storage and status monitoring capabilities for the authentication and processing process: the monitoring system monitors the gateway's request processing performance, authentication results, service load and other indicators, and triggers alarms when anomalies occur to ensure the stability of the gateway's operation; the in-memory key-value database cache cluster serves as an L2-level cache to store session data, valid / invalid keys and other information, and persistently stores authentication information, request logs and other data through the database for security auditing, problem tracing and data backup.

[0155] The MCP service layer is the final processing node for MCP requests. After the gateway completes the request processing through the security enhancement module and the request is successfully authenticated, it distributes the request to the corresponding backend service. For example, the weather query service (:8081) handles weather-related MCP business requests, the human resources service (:8082) handles human resources-related MCP business requests, the file processing service (:8083) handles file upload, parsing, and other MCP business requests, and the tool callback service (:8084) receives and processes callback requests from backend tools and completes the result return.

[0156] Based on the above-described protocol authentication method, this application also provides a protocol authentication device. The following will be combined with... Figure 6 The device is described in detail.

[0157] Figure 6 A schematic block diagram of a protocol authentication device according to an embodiment of this application is shown.

[0158] like Figure 6 As shown, the protocol authentication device 600 of this embodiment includes an extraction module 610, a first authentication module 620, and a second authentication module 630.

[0159] The extraction module 610 is used to extract information from the received Model Context Protocol (MCP) request in response to obtaining the request path and Internet Protocol (IP) address. In one embodiment, the advance module 610 can be used to perform the operation S210 described above, which will not be repeated here.

[0160] The first authentication module 620 is used to identify the request type based on the request characteristics indicated by the Model Context Protocol request and preset identification rules when the request path is not in the preset path whitelist and the Internet Protocol address is in the preset address whitelist. The identification rules indicate the correspondence between multiple request types and their respective matching request characteristics. In one embodiment, the first authentication module 620 can be used to perform the operation S220 described above, which will not be repeated here.

[0161] The second authentication module 630 is used to invoke an authentication method that matches the request type to authenticate the model context protocol request and obtain an authentication result. In one embodiment, the second authentication module 630 can be used to perform the operation S230 described above, which will not be repeated here.

[0162] According to embodiments of this application, any multiple modules among the extraction module 610, the first authentication module 620, and the second authentication module 630 can be combined into one module, or any one of these modules can be split into multiple modules. Alternatively, at least some of the functions of one or more of these modules can be combined with at least some of the functions of other modules and implemented in one module.

[0163] According to embodiments of this application, at least one of the extraction module 610, the first authentication module 620, and the second authentication module 630 can be at least partially implemented as a hardware circuit, such as a field-programmable gate array (FPGA), a programmable logic array (PLA), a system-on-a-chip, a system-on-a-substrate, a system-on-package, an application-specific integrated circuit (ASIC), or any other reasonable method of integrating or packaging the circuit, or implemented in software, hardware, or firmware, or in any suitable combination of any of these three methods. Alternatively, at least one of the extraction module 610, the first authentication module 620, and the second authentication module 630 can be at least partially implemented as a computer program module, which can perform corresponding functions when the computer program module is run.

[0164] Figure 7 A block diagram schematically illustrates an electronic device suitable for implementing a protocol authentication method according to an embodiment of this application.

[0165] like Figure 7 As shown, an electronic device 700 according to an embodiment of this application includes a processor 701, which can perform various appropriate actions and processes according to a program stored in a read-only memory (ROM) 702 or a program loaded from a storage portion 708 into a random access memory (RAM) 703. The processor 701 may include, for example, a general-purpose microprocessor (e.g., a CPU), an instruction set processor and / or an associated chipset and / or a special-purpose microprocessor (e.g., an application-specific integrated circuit (ASIC)), etc. The processor 701 may also include onboard memory for caching purposes. The processor 701 may include a single processing unit or multiple processing units for performing different actions of the method flow according to an embodiment of this application.

[0166] RAM 703 stores various programs and data required for the operation of electronic device 700. Processor 701, ROM 702, and RAM 703 are interconnected via bus 704. Processor 701 executes various operations of the method flow according to embodiments of this application by executing programs in ROM 702 and / or RAM 703. It should be noted that the programs may also be stored in one or more memories other than ROM 702 and RAM 703. Processor 701 may also execute various operations of the method flow according to embodiments of this application by executing programs stored in said one or more memories.

[0167] According to embodiments of this application, the electronic device 700 may further include an input / output (I / O) interface 705, which is also connected to a bus 704. The electronic device 700 may also include one or more of the following components connected to the input / output (I / O) interface 705: an input section 706 including a keyboard, mouse, etc.; an output section 707 including a cathode ray tube (CRT), liquid crystal display (LCD), etc., and a speaker, etc.; a storage section 708 including a hard disk, etc.; and a communication section 709 including a network interface card such as a LAN card, modem, etc. The communication section 709 performs communication processing via a network such as the Internet. A drive 710 is also connected to the input / output (I / O) interface 705 as needed. A removable medium 711, such as a disk, optical disk, magneto-optical disk, semiconductor memory, etc., is installed on the drive 710 as needed so that computer programs read from it can be installed into the storage section 708 as needed.

[0168] This application also provides a computer-readable storage medium, which may be included in the device / apparatus / system described in the above embodiments; or it may exist independently and not assembled into the device / apparatus / system. The computer-readable storage medium carries one or more programs, which, when executed, implement the method according to the embodiments of this application.

[0169] According to embodiments of this application, the computer-readable storage medium can be a non-volatile computer-readable storage medium, such as including but not limited to: portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination thereof. In this application, the computer-readable storage medium can be any tangible medium containing or storing a program that can be used by or in conjunction with an instruction execution system, apparatus, or device. For example, according to embodiments of this application, the computer-readable storage medium may include ROM 702 and / or RAM 703 and / or one or more memories other than ROM 702 and RAM 703 described above.

[0170] Embodiments of this application also include a computer program product comprising a computer program containing program code for performing the methods shown in the flowchart. When the computer program product is run on a computer system, the program code is used to enable the computer system to implement the protocol authentication method provided in the embodiments of this application.

[0171] When the computer program is executed by the processor 701, it performs the functions defined in the system / apparatus of this application embodiment. According to the embodiments of this application, the systems, apparatuses, modules, units, etc., described above can be implemented by computer program modules.

[0172] In one embodiment, the computer program may rely on a tangible storage medium such as an optical storage device or a magnetic storage device. In another embodiment, the computer program may also be transmitted and distributed in the form of signals over a network medium, and may be downloaded and installed via the communication section 709, and / or installed from a removable medium 711. The program code contained in the computer program can be transmitted using any suitable network medium, including but not limited to: wireless, wired, etc., or any suitable combination thereof.

[0173] In such an embodiment, the computer program can be downloaded and installed from a network via the communication section 709, and / or installed from the removable medium 711. When the computer program is executed by the processor 701, it performs the functions defined in the system of this application embodiment. According to the embodiments of this application, the systems, devices, apparatuses, modules, units, etc., described above can be implemented by computer program modules.

[0174] According to embodiments of this application, program code for executing the computer programs provided in the embodiments of this application can be written in any combination of one or more programming languages. Specifically, these computational programs can be implemented using high-level procedural and / or object-oriented programming languages, and / or assembly / machine languages. Programming languages ​​include, but are not limited to, languages ​​such as Java, C++, Python, "C", or similar programming languages. The program code can be executed entirely on the user's computing device, partially on the user's device, partially on a remote computing device, or entirely on a remote computing device or server. In cases involving remote computing devices, the remote computing device can be connected to the user's computing device via any type of network, including a local area network (LAN) or a wide area network (WAN), or it can be connected to an external computing device (e.g., via the Internet using an Internet service provider).

[0175] The flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of this application. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of code containing one or more executable instructions for implementing a specified logical function. It should also be noted that in some alternative implementations, the functions indicated in the blocks may occur in a different order than those indicated in the drawings. For example, two consecutively indicated blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in a block diagram or flowchart, and combinations of blocks in a block diagram or flowchart, may be implemented using a dedicated hardware-based system that performs the specified function or operation, or using a combination of dedicated hardware and computer instructions.

[0176] Those skilled in the art will understand that the features described in the various embodiments of this application can be combined and / or combined in various ways, even if such combinations or combinations are not explicitly described in this application. In particular, the features described in the various embodiments of this application can be combined and / or combined in various ways without departing from the spirit and teachings of this application. All such combinations and / or combinations fall within the scope of this application.

Claims

1. A protocol authentication method, characterized in that, The method includes: In response to receiving a Model Context Protocol (MTP) request, information is extracted from the MTP request to obtain the request path and Internet Protocol (IP) address. When the request path is not in the preset path whitelist and the Internet Protocol address is in the preset address whitelist, type identification is performed based on the request features indicated by the model context protocol request and the preset identification rules to obtain the request type. The identification rules indicate the correspondence between multiple request types and their respective matching request features. The authentication method matching the request type is invoked to authenticate the Model Context Protocol request, and the authentication result is obtained.

2. The method according to claim 1, characterized in that, When the request type is a tool callback, the authentication method matching the request type is invoked to authenticate the model context protocol request, and the authentication result includes: Decrypt the callback token in the model context protocol request to extract the authentication key, timestamp, and random number; Timeliness verification is performed based on the difference between the timestamp and the current time. If the timeliness verification passes, the random number is verified against replay based on the pre-stored historical random number. If the replay verification passes, the standard key authentication process is invoked to verify the validity of the authentication key. If the validity verification passes, the invocation tool indicated by the model context protocol request is authorized based on a pre-stored list of authorized tools to obtain an authentication result. The list of authorized tools indicates the scope of tool authorization.

3. The method according to claim 1, characterized in that, When the request type is a request to establish, the authentication method matching the request type is invoked to authenticate the Model Context Protocol request, and the authentication result includes: If the authentication key indicated by the Model Context Protocol request is not in the pre-stored invalid key cache but in the pre-stored valid key cache, validity verification is performed based on the activation status and usage time of the authentication key. If the validity verification passes, service permission verification is performed based on the service identifier matched by the authentication key and the target service identifier indicated by the model context protocol request. If the authentication key is not in the invalid key cache or the valid key cache, the authentication key is stored in the invalid key cache.

4. The method according to claim 1, characterized in that, When the request type is data transmission, the authentication method matching the request type is invoked to authenticate the Model Context Protocol request, and the authentication result includes: Extract the session information from the Model Context Protocol Request, the session information including the session validity period; Session validity is verified based on the current time and the session validity period.

5. The method according to claim 1, characterized in that, If the authentication result is successful, the method further includes: Extract the authentication information indicated in the request header of the Model Context Protocol request, and remove the authentication information; The gateway generates encrypted authentication information for service node authentication, which includes at least one of user identifier, service identifier, request timestamp, and signature. Based on a preset protocol format, the request path indicated by the model context protocol request is converted into a backend service path through a gateway.

6. The method according to claim 1, characterized in that, If the authentication result is successful and the request type is data transfer, the method further includes: If the difference between the current time and the last active time indicated by the model context protocol request is less than a preset threshold, the last active time is updated to the current time using an asynchronous processing thread, thereby extending the session validity period under the constraint of the maximum valid time.

7. The method according to claim 1, characterized in that, The method further includes: Access logs are stored in a database using an asynchronous log channel. The access logs include at least one of the following: user identifier, service identifier, request path, client address, request type, and authentication method.

8. The method according to claim 1, characterized in that, The request features include at least one of the following: authentication key, session identifier, callback token, and request path identifier.

9. A protocol authentication device, characterized in that, The device includes: The extraction module is used to extract information from the received Model Context Protocol (MTP) request in response to the received MTP request, and obtain the request path and Internet Protocol (IP) address. The first authentication module is used to, when the request path is not in a preset path whitelist and the Internet Protocol address is in a preset address whitelist, perform type identification based on the request characteristics indicated by the model context protocol request and preset identification rules to obtain the request type. The identification rules indicate the correspondence between multiple request types and their respective matching request characteristics. The second authentication module is used to call the authentication method that matches the request type to authenticate the model context protocol request and obtain the authentication result.

10. An electronic device, comprising: One or more processors; Memory, used to store one or more computer programs. The characteristic feature is that the one or more processors execute the one or more computer programs to implement the steps of the method according to any one of claims 1 to 8.

11. A computer-readable storage medium having a computer program or instructions stored thereon, characterized in that, When the computer program or instructions are executed by a processor, they implement the steps of the method according to any one of claims 1 to 8.

12. A computer program product, comprising a computer program or instructions, characterized in that, When the computer program or instructions are executed by a processor, they implement the steps of the method according to any one of claims 1 to 8.

Images