A server tool access method, apparatus, device, and medium
By configuring privacy levels and trust score calculations for server-side tools, dynamically determining access permissions, and using restricted tokens for multi-dimensional verification, the problem of coarse MCP authorization granularity and abnormal access identification is solved, achieving precise adaptation of risks and permissions and improved security.
Patent Information
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- PENG CHENG LAB
- Filing Date
- 2026-03-25
- Publication Date
- 2026-06-16
AI Technical Summary
The existing MCP authorization mechanism has problems such as coarse authorization granularity and mismatch between risks and permissions, which leads to the leakage of highly sensitive data or reduced usability of low-sensitivity tools, and makes it difficult to identify abnormal access behavior.
By configuring privacy levels and trust score calculations for server-side tools, access permissions are dynamically determined, and restricted tokens are used for multi-dimensional verification to limit client access permissions.
It achieves precise matching of risks and permissions, improves the security of user authorization and tool access, prevents abnormal access, and enhances user experience and system compatibility.
Smart Images
Figure CN122226408A_ABST
Abstract
Description
Technical Field
[0001] This invention relates to the field of communication technology, and in particular to a method, apparatus, device, and medium for accessing server-side tools. Background Technology
[0002] In the current MCP (Model Context Protocol) communication system, the authorization process generally follows a standard mechanism: after the client obtains a token from the authorization service, it sends an access request to the server-side tool with the token. The server verifies the token's validity and returns a normal response, thus allowing the client to access the server-side tool. This standard mechanism, based on static token verification, uses token validity as the sole criterion for access and is commonly used in scenarios such as intelligent agent interaction, cloud service API (Application Programming Interface) gateways, and cross-system resource calls.
[0003] However, existing MCP authorization has a coarse granularity, resulting in a mismatch between risks and permissions. Current MCP authorization employs an "all or nothing" logic, meaning that users who obtain a token have access to all tools on the server. For example, highly sensitive tools involving personal bank statements and medical health data share the same authorization verification rules as less sensitive tools providing book subscriptions and weather queries. This can easily lead to the leakage of highly sensitive data due to over-authorization, and may also reduce the usability of less sensitive tools due to uniformly strict authorization, failing to achieve a precise match between permissions and risks. Furthermore, the current authorization process only verifies identity credentials such as account passwords and token validity. If a token is stolen or an account is hijacked, attackers can use only a legitimate token to access server tools from different locations, at unusual times, and on unfamiliar devices. The system struggles to detect such abnormal access behavior, resulting in significant vulnerabilities in the protection. Summary of the Invention
[0004] In view of this, the purpose of this invention is to provide a method, apparatus, device, and medium for accessing server-side tools, which can improve the security of user authorization and tool access based on the privacy classification of server-side tools and the calculation of client trust scores. By restricting the access permissions carried by a limited token, it restricts the client's access permissions to server-side tools, preventing users who obtain tokens from arbitrarily and unrestrictedly accessing tools of arbitrary privacy levels, thus achieving precise matching of risk and permissions. The specific solution is as follows: Firstly, this application provides a server-side tool access method, applied to a client, including: After obtaining the target privacy level corresponding to the target tool from the server based on the unauthenticated access request, the user authorizes the login page of the authorization service so that the authorization service can determine the target trust score of the client based on the user environment of the login page. A token acquisition request carrying the target privacy level is sent to the authorization service so that the authorization service can determine the target trust threshold corresponding to the target privacy level. If the user authorization is determined to be successful based on the comparison result of the target trust score and the target trust threshold, a restricted token carrying the access permission range is issued to the client. The client sends a tool access request carrying the restricted token to the server, so that the server responds to the tool access request by performing a preset verification operation and determines whether to allow the client to access the target tool based on the verification result; the preset verification operation includes verifying the validity of the restricted token, the target trust score and the access permission range, or any combination of several of these.
[0005] Optionally, obtaining the target privacy level corresponding to the target tool from the server based on the unauthenticated access request includes: An unauthenticated access request for the target tool is sent to the server, so that the server returns an unauthenticated error containing header information to the client based on the unauthenticated access request; Extract the metadata retrieval address from the header information, and send the metadata document retrieval request to the server based on the metadata retrieval address, so that the server can determine the corresponding protected resource metadata document based on the metadata document retrieval request, add the target privacy level corresponding to the target tool to the protected resource metadata document, and return the added protected resource metadata document to the client; Obtain the target privacy level from the newly added protected resource metadata document; The target privacy level is a privacy level dynamically determined by the server based on the functional characteristics, data type, and historical call behavior of the target tool.
[0006] Optionally, the login page of the access authorization service authorizes the user so that the authorization service can determine the target trust score of the client based on the user environment of the login page, including: Extract the metadata retrieval address of the authorization service from the newly added protected resource metadata document, and send the metadata retrieval request to the authorization service based on the metadata retrieval address, so that the authorization service can return its own metadata to the client based on the metadata retrieval request; The authorization service obtains the login page of the authorization service based on the metadata of the authorization service, and accesses the login page to authorize the user, so that the authorization service can collect the user environment through the login page and determine the target trust score of the client based on the user environment; The user environment includes any one or a combination of several of the client's device information, location information, time information, and operation behavior information, and the authorization service dynamically adjusts the target trust score when it detects a change in the user environment.
[0007] Optionally, after determining the target trust threshold corresponding to the target privacy level, the authorization service further includes: Determine the comparison result between the target trust score and the target trust threshold; If the comparison result indicates that the target trust score is not less than the target trust threshold, then the user authorization is determined to be successful, and a restricted token carrying the access permission range corresponding to the target privacy level is issued to the client.
[0008] Optionally, after determining the comparison result between the target trust score and the target trust threshold, the method further includes: If the comparison result indicates that the target trust score is less than the target trust threshold, then other privacy levels lower than the target privacy level are determined from each privacy level, and it is determined whether there are candidate trust thresholds that are not greater than the target trust score among the trust thresholds corresponding to the other privacy levels. If it exists, then determine the maximum trust threshold from the candidate trust thresholds, determine the appropriate privacy level corresponding to the maximum trust threshold, and issue a restricted token carrying the access permission range corresponding to the appropriate privacy level to the client.
[0009] Optionally, after determining the comparison result between the target trust score and the target trust threshold, the method further includes: If the comparison result indicates that the target trust score is less than the target trust threshold, the client is triggered to perform secondary verification. After the secondary verification is passed, the target trust score is raised to a preset trust score, and a restricted token carrying the access permission range corresponding to the target privacy level is issued to the client. Wherein, the preset trust score is not less than the target trust threshold.
[0010] Optionally, after determining the comparison result between the target trust score and the target trust threshold, the method further includes: If the comparison result indicates that the target trust score is less than the target trust threshold, then it is determined that the user authorization has not been approved, and an abnormal prompt message of access denial is sent to the client.
[0011] Secondly, this application provides a server-side tool access device, applied to a client, comprising: The user authorization module is used to access the login page of the authorization service to authorize the user after obtaining the target privacy level corresponding to the target tool from the server based on the unauthenticated access request, so that the authorization service can determine the target trust score of the client based on the user environment of the login page. The first request sending module is used to send a token acquisition request carrying the target privacy level to the authorization service, so that the authorization service can determine the target trust threshold corresponding to the target privacy level. If the user authorization is determined to be successful based on the comparison result of the target trust score and the target trust threshold, a restricted token carrying the access permission range is issued to the client. The second request sending module is used to send a tool access request carrying the restricted token to the server, so that the server responds to the tool access request by performing a preset verification operation and determines whether to allow the client to access the target tool based on the verification result; the preset verification operation includes verifying the validity of the restricted token, the target trust score and the access permission range, or any combination of several of them.
[0012] Thirdly, this application provides an electronic device, comprising: Memory, used to store computer programs; A processor for executing the computer program to implement the aforementioned server-side tool access method.
[0013] Fourthly, this application provides a computer-readable storage medium for storing a computer program, which, when executed by a processor, implements the aforementioned server-side tool access method.
[0014] In this application, after obtaining the target privacy level corresponding to the target tool from the server based on an unauthenticated access request, the client accesses the login page of the authorization service to authorize the user. The authorization service then determines the client's target trust score based on the user environment on the login page. The client sends a token acquisition request carrying the target privacy level to the authorization service, which determines a target trust threshold corresponding to the target privacy level. If the authorization is successful based on a comparison between the target trust score and the target trust threshold, a restricted token carrying the access permission range is issued to the client. The client then sends a tool access request carrying the restricted token to the server, which performs a preset verification operation in response to the tool access request and determines whether to allow the client to access the target tool based on the verification result. The preset verification operation includes verifying the validity of the restricted token, the target trust score, and any one or a combination of the access permission range.
[0015] Therefore, this application establishes a hierarchical standard and management mechanism by configuring corresponding privacy levels for each tool on the server side, classifying tools according to their privacy levels, thus providing a foundation for subsequent fine-grained user authorization. Secondly, after a user accesses the login page, the authorization service determines the client's target trust score based on the user environment on the login page, calculates a trust score representing the client's level of trustworthiness, and thus constructs a corresponding user environment profile for the client. Subsequently, this application, through a pre-established mapping relationship between privacy levels and trust thresholds, configures different trust thresholds for different privacy levels. By comparing the client's target trust score with the target trust threshold corresponding to the target tool's privacy level, it determines whether user authorization is successful, thus improving the security of user authorization. If user authorization is successful, a restricted token carrying the access permission range is issued to the client. The client then sends a tool access request carrying the restricted token to the server. The server verifies the validity of the restricted token, the client's target trust score, and the access permission range carried by the restricted token to determine whether to allow the client to access the target tool. This solves the problem of existing technologies using only static tokens for verification. Multi-dimensional verification improves the security of tool access, and the access permission range carried by the restricted token restricts the client's access to server tools, allowing only access that meets the permissions. This prevents users who obtain tokens from arbitrarily and unrestrictedly accessing tools of any privacy level, achieving precise matching of risk and permissions. Attached Figure Description
[0016] To more clearly illustrate the technical solutions in the embodiments of the present invention or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on the provided drawings without creative effort.
[0017] Figure 1 A flowchart illustrating a server-side tool access method provided in this application embodiment; Figure 2 A specific server-side tool access flowchart is provided for an embodiment of this application; Figure 3 A schematic diagram of a server-side tool access device provided in an embodiment of this application; Figure 4 This is a structural diagram of an electronic device provided in an embodiment of this application. Detailed Implementation
[0018] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.
[0019] The existing MCP authorization is coarse-grained, resulting in a mismatch between risk and permissions. The current MCP authorization adopts an "all or nothing" logic, meaning that the user who obtains the token has access to all tools on the server. For example, highly sensitive tools involving personal bank statements and medical health data share the same authorization verification rules as less sensitive tools providing book subscriptions and weather queries. This is prone to over-authorization leading to the leakage of highly sensitive data, and may also reduce the usability of less sensitive tools due to uniformly strict authorization, failing to achieve a precise match between permissions and risks. Furthermore, the current authorization process only verifies identity credentials such as account passwords and token validity. If the token is stolen or the account is hijacked, attackers can use only a legitimate token to access server tools from different locations, at unusual times, and on unfamiliar devices. The system struggles to detect such abnormal access behavior, resulting in significant vulnerabilities in the protection.
[0020] In response, this application provides a method for accessing server-side tools, which can improve the security of user authorization and tool access based on the privacy classification of server-side tools and the calculation of client trust scores. By restricting the access permissions carried by the restricted token, the access permissions of the client to the server-side tools are limited, preventing users who obtain the token from arbitrarily and without restriction accessing tools of any privacy level, thus achieving precise matching of risk and permissions.
[0021] See Figure 1 As shown, this embodiment of the invention discloses a server-side tool access method, applied to a client, including: Step S11: After obtaining the target privacy level corresponding to the target tool from the server based on the unauthenticated access request, access the login page of the authorization service to authorize the user, so that the authorization service can determine the target trust score of the client based on the user environment of the login page.
[0022] In this embodiment, the client sends an unauthenticated access request for the target tool to the server, so that the server returns an unauthenticated error containing header information to the client based on the unauthenticated access request; the client extracts the metadata retrieval address from the header information and sends a metadata document retrieval request to the server based on the metadata retrieval address, so that the server determines the corresponding Protected Resource Metadata (PRM) document based on the metadata document retrieval request, adds a target privacy level (PL) corresponding to the target tool to the Protected Resource Metadata document, and returns the added Protected Resource Metadata document to the client; the client obtains the target privacy level from the added Protected Resource Metadata document.
[0023] Meanwhile, the client can also extract the metadata retrieval address of the authorization service from the newly added protected resource metadata document, and send the metadata retrieval request to the authorization service based on the metadata retrieval address, so that the authorization service can return its own metadata to the client based on the metadata retrieval request; the client can obtain the login page of the authorization service based on the metadata of the authorization service, and access the login page to authorize the user, so that the authorization service can collect the user environment through the login page and determine the target trust score of the client based on the user environment.
[0024] Among them, the unauthenticated access request is an access request for the target tool generated based on the MCP protocol that lacks user authentication information; correspondingly, the unauthentication error at this time is the HTTP 401 Unauthorized (Hypertext Transfer Protocol) error. The HTTP 401 Unauthorized error means that the user does not have access rights and needs to be authenticated.
[0025] The target privacy level is dynamically determined by the server based on the target tool's functional characteristics, data type, and historical call behavior.
[0026] It should be noted that the privacy level classification standard for server-side tools can adopt a preset three-level privacy level standard, and supports administrator customization and expansion. For example, high privacy level (PL-H): involves core privacy data such as financial accounts, medical health, and biometrics; medium privacy level (PL-M): involves general privacy data such as personal identity information and consumption records; low privacy level (PL-L): involves public information and tools without privacy attributes (such as weather queries and public information).
[0027] Furthermore, the privacy level of server-side tools can be comprehensively evaluated using a combination of static rules and machine learning classifiers. This involves a thorough analysis of the functional characteristics, data types, and historical call behavior of the MCP server-side tools to ultimately determine their corresponding privacy levels. The mapping between tools and privacy levels can be stored in a "tool level mapping table," and information standardization and synchronization can be achieved based on the MCP protocol standard. This can be done either through tools / list response extensions or through PRM (Protected Resource Metadata) document extensions. Both methods utilize JSON Schema (a specification for describing and validating JSON data structures) for secure extensions to ensure format consistency.
[0028] This system extends the Protected Resource Metadata (PRM) document based on the MCP protocol by adding custom extended fields. These fields centrally contain the tool's privacy level and basic control parameters—directly linking the specific tool identifier to its corresponding privacy level (e.g., PL-M), or including configuration information such as trust thresholds for the privacy level. The format, data type, and value constraints of these custom extended fields are standardized using JSON Schema (e.g., privacy level is a positive integer, PL-M=2, PL-H=1, PL-L=3, etc.) to ensure consistent parsing between the MCP server and client. Since the PRM document is publicly accessible, clients can directly obtain it without additional authorization and then read the target privacy level and related control parameters for the target tool from the extended fields.
[0029] It should be noted that this extension method relies entirely on the native response structure of the MCP protocol, without the need to introduce non-protocol components. It also supports flexible extensions, such as customizing the environmental factor type in required_context according to the privacy protection requirements of the tool, providing clear data collection basis for subsequent multi-dimensional trust assessment.
[0030] Furthermore, this application includes a dynamic update mechanism for the privacy level of the tool. That is, when the tool's functional characteristics, data scope, data type, or access behavior changes, a reassessment of the privacy level can be triggered. Additionally, this application allows administrators to manually adjust the tool's privacy level through a management interface to ensure that the tool's privacy level remains consistent with actual risks.
[0031] Furthermore, the login page of the authorization service integrates an environment factor collector, which is used to silently collect the user's environment in the background when the client accesses the login page to authorize the user, and determine the client's target trust score based on the user's environment.
[0032] The user environment includes any one or a combination of several of the client's device information, location information, time information, and operational behavior information, and the authorization service dynamically adjusts the target trust score when it detects changes in the user environment.
[0033] For example, device information includes, but is not limited to, device model, operating system, browser fingerprint, hardware identifier, etc.; location information includes, but is not limited to, IP (Internet Protocol) location, whether it is a frequently used city, etc.; time information includes, but is not limited to, whether it matches the user's historical active time period, etc.; operation behavior information includes, but is not limited to, login frequency, input speed, verification step time, etc.
[0034] According to one example, determining a target trust score for a client based on its user environment can specifically include: using a supervised learning model to weight and calculate the multi-dimensional user environment features based on collected data, thereby generating a target trust score that reflects the trustworthiness of the current client access. The feature weights corresponding to the multi-dimensional user environment features are obtained through model training, and the trust score is used to characterize the overall risk level of the current access request.
[0035] If abnormal behavior or changes in user environment characteristics are detected during a user session or access period, the trust score can be dynamically adjusted to achieve continuous awareness of access risks, rather than a one-time assessment only at the initial login stage.
[0036] Step S12: Send a token acquisition request carrying the target privacy level to the authorization service so that the authorization service can determine the target trust threshold corresponding to the target privacy level. If the user authorization is approved based on the comparison result of the target trust score and the target trust threshold, a restricted token carrying the access permission range is issued to the client.
[0037] In this embodiment, the client sends a token acquisition request carrying the target privacy level to the authorization service so that the authorization service can determine the target trust threshold corresponding to the target privacy level and compare the client's target trust score with the target trust threshold to obtain a comparison result. Based on the comparison result, it is determined whether the user authorization is successful. If the user authorization is unsuccessful, an access denial error message is sent to the client. If the user authorization is successful, a restricted token carrying the access permission range is sent to the client.
[0038] It should be noted that the authorization service pre-establishes a mapping relationship between privacy levels and trust thresholds. That is, different access trust thresholds are set according to different privacy levels; for example, the trust threshold for a high privacy level is 80, for a medium privacy level it is 70, and for a low privacy level it is 60. Furthermore, this application supports dynamic adjustment of the trust thresholds corresponding to privacy levels based on business needs or risk strategies.
[0039] It should also be noted that after determining the target trust threshold corresponding to the target privacy level based on the mapping relationship between privacy level and trust threshold, the authorization service first determines the comparison result between the target trust score and the target trust threshold; if the comparison result indicates that the target trust score is not less than the target trust threshold, then the user authorization is determined to be successful, and a restricted token carrying the access permission range corresponding to the target privacy level is issued to the client.
[0040] According to one example, if the comparison result indicates that the target trust score is less than the target trust threshold, then other privacy levels lower than the target privacy level are determined from each privacy level, and it is determined whether there are candidate trust thresholds that are not greater than the target trust score among the trust thresholds corresponding to other privacy levels; if so, the maximum trust threshold is determined from the candidate trust thresholds, and the appropriate privacy level corresponding to the maximum trust threshold is determined, and a restricted token carrying the access permission range corresponding to the appropriate privacy level is issued to the client.
[0041] For example, if the target privacy level is high privacy level, the target trust score is 72, and the target trust threshold is 80, since the target trust score is less than the target trust threshold, other privacy levels lower than high privacy level are determined from high privacy level, medium privacy level, and low privacy level, namely medium privacy level and low privacy level. It is then determined whether there are candidate trust thresholds no greater than the target trust score of 72 among the trust thresholds 70 corresponding to medium privacy level and trust thresholds 60 corresponding to low privacy level. If so, the maximum trust threshold 70 is determined from the candidate trust thresholds 70 and 60, and the appropriate privacy level corresponding to the maximum trust threshold is determined, namely medium privacy level. Then, a restricted token carrying the access permission range corresponding to medium privacy level is issued to the client.
[0042] It should be noted that if there are no other privacy levels lower than the target privacy level among the various privacy levels, or if there are no candidate trust thresholds less than or equal to the target trust score among the trust thresholds corresponding to other privacy levels, then it is determined that the user authorization has not been approved, and an abnormal prompt message of access denial is sent to the client.
[0043] According to another example, if the comparison result indicates that the target trust score is less than the target trust threshold and not less than the trust threshold corresponding to the lowest privacy level, then a restricted token carrying the access permission range corresponding to the lowest privacy level can be directly issued to the client.
[0044] According to another example, if the comparison result indicates that the target trust score is less than the target trust threshold, the client is triggered to perform secondary verification. After the secondary verification is passed, the target trust score is temporarily increased to the preset trust score, and a restricted token carrying the access permission range corresponding to the target privacy level is issued to the client; wherein, the preset trust score is not less than the target trust threshold.
[0045] It should be noted that secondary verification includes, but is not limited to, facial recognition, fingerprint recognition, iris recognition, and MFA (Multi-factor Authentication).
[0046] It should also be noted that if the secondary verification fails, it is determined that the user authorization has not been approved, and an access denied error message is sent to the client.
[0047] In another example, if the comparison result indicates that the target trust score is less than the target trust threshold, then it is directly determined that the user authorization has not been approved, and an abnormal message indicating that access is denied is sent to the client.
[0048] Step S13: Send a tool access request carrying the restricted token to the server so that the server responds to the tool access request by performing a preset verification operation and determines whether to allow the client to access the target tool based on the verification result; the preset verification operation includes verifying the validity of the restricted token, the target trust score and the access permission range, or any combination of several of them.
[0049] In this embodiment, the client sends a tool access request carrying a restricted token and a target privacy level to the server. The server responds to the tool access request by verifying the validity of the restricted token, verifying the target trust score (determining if the target trust score is greater than the target trust threshold corresponding to the target privacy level), and verifying the access permission range carried by the restricted token (determining if the access permission range carried by the restricted token matches the access permission range corresponding to the target privacy level). If any verification of the restricted token validity, target trust score, or access permission range fails, the client's access to the target tool is denied, and an error message indicating verification failure is returned to the client. If all verifications of the restricted token validity, target trust score, and access permission range are successful, the client is allowed to access the target tool within the access permission range carried by the restricted token, i.e., the client is allowed access that meets the permissions.
[0050] like Figure 2 As shown, taking a high-privacy-level server-side tool, such as a bank statement query tool, as an example, the client sends an unauthenticated access request (i.e., an MCP request without authentication information) to the server. The server then returns an HTTP 401 Unauthorized error with header information to the client based on the unauthenticated access request. The client extracts the metadata retrieval address from the header information and sends a metadata document retrieval request (i.e., a GET request) to the server based on the metadata retrieval address. The server then determines the corresponding protected resource metadata document based on the metadata document retrieval request, adds the target privacy level (e.g., PL-H) corresponding to the target tool, and the target trust threshold (e.g., 80 points) corresponding to the target privacy level to the protected resource metadata document, and then returns the newly added protected resource metadata document to the client. The client verifies the newly acquired protected resource metadata document. Upon successful verification, it retrieves the target privacy level from the newly acquired protected resource metadata document and extracts the metadata retrieval address of the authorization service. Based on the metadata retrieval address, it sends a metadata retrieval request (i.e., a GET request) to the authorization service, so that the authorization service can return its own metadata (i.e., all metadata or all endpoint information) to the client based on the metadata retrieval request. The client retrieves the authorization service's login page based on the metadata of the authorization service and accesses the login page to authorize the user. This allows the authorization service to collect the user's environment information through the login page, such as the client's device information, location information, time information, and operation behavior information. Then, based on the user environment, it uses a trust scoring model to calculate the client's target trust score, such as 75 points.
[0051] Furthermore, the client sends a token acquisition request carrying the target privacy level (e.g., PL-H) corresponding to the target tool to the authorization service, so that the authorization service can determine the target trust threshold corresponding to the target privacy level. Since the target trust score is less than the target trust threshold, the client is triggered to perform secondary verification, such as facial recognition. After the facial recognition is successful, the target trust score is temporarily increased to a preset trust score (e.g., 85 points), and a restricted token carrying the access permission range corresponding to the higher privacy level is issued to the client.
[0052] The client sends a tool access request (i.e., an MCP request carrying a restricted token) to the server, which then responds to the tool access request by verifying the validity of the restricted token, the client's target trust score, and the access permissions carried by the restricted token. If any of these verifications fail, the client is denied access to the target tool. If all verifications succeed, the client is allowed to access the target tool within the access permissions carried by the restricted token.
[0053] In this way, this application can achieve the following technical effects: 1. Significantly enhanced security: Through dynamic trust assessment based on user environment awareness, it effectively intercepts illegal calls from holders of legitimate tokens under abnormal conditions, filling the protection vulnerability of static single token verification. 2. Balancing compliance and flexibility: Fine-grained tool privacy classification and threshold dynamic access mechanism meet the fine-grained auditing and compliance requirements for privacy data in fields such as healthcare and finance, and adapt to business scenarios with different privacy levels. 3. Optimized user experience: It achieves "strong verification for high privacy levels and simplified processes for low privacy levels," eliminating the need for frequent secondary verification for low privacy levels, thus balancing security and operational efficiency. 4. Excellent compatibility: It adopts a plug-in integration and metadata extension mechanism, relying on the native architecture of the MCP protocol to achieve functional enhancements without modifying the core framework of the protocol, and can be quickly adapted to the existing MCP communication system.
[0054] See Figure 3 As shown, this embodiment of the invention provides a server-side tool access device, applied to a client, comprising: User authorization module 11 is used to access the login page of the authorization service to authorize the user after obtaining the target privacy level corresponding to the target tool from the server based on the unauthenticated access request, so that the authorization service can determine the target trust score of the client based on the user environment of the login page. The first request sending module 12 is used to send a token acquisition request carrying the target privacy level to the authorization service so that the authorization service can determine the target trust threshold corresponding to the target privacy level. If the user authorization is determined to be successful based on the comparison result of the target trust score and the target trust threshold, a restricted token carrying the access permission range is issued to the client. The second request sending module 13 is used to send a tool access request carrying the restricted token to the server, so that the server responds to the tool access request by performing a preset verification operation and determines whether to allow the client to access the target tool based on the verification result; the preset verification operation includes verifying the validity of the restricted token, the target trust score and the access permission range, or any combination of several of them.
[0055] Therefore, this application establishes a hierarchical standard and management mechanism by configuring corresponding privacy levels for each tool on the server side, classifying tools according to their privacy levels, thus providing a foundation for subsequent fine-grained user authorization. Secondly, after a user accesses the login page, the authorization service determines the client's target trust score based on the user environment on the login page, calculates a trust score representing the client's level of trustworthiness, and thus constructs a corresponding user environment profile for the client. Subsequently, this application, through a pre-established mapping relationship between privacy levels and trust thresholds, configures different trust thresholds for different privacy levels. By comparing the client's target trust score with the target trust threshold corresponding to the target tool's privacy level, it determines whether user authorization is successful, thus improving the security of user authorization. If user authorization is successful, a restricted token carrying the access permission range is issued to the client. The client then sends a tool access request carrying the restricted token to the server. The server verifies the validity of the restricted token, the client's target trust score, and the access permission range carried by the restricted token to determine whether to allow the client to access the target tool. This solves the problem of existing technologies using only static tokens for verification. Multi-dimensional verification improves the security of tool access, and the access permission range carried by the restricted token restricts the client's access to server tools, allowing only access that meets the permissions. This prevents users who obtain tokens from arbitrarily and unrestrictedly accessing tools of any privacy level, achieving precise matching of risk and permissions.
[0056] In some specific embodiments, the user authorization module 11 includes: The first request sending unit is used to send an unauthenticated access request for the target tool to the server, so that the server returns an unauthenticated error containing header information to the client based on the unauthenticated access request; The second request sending unit is used to extract the metadata retrieval address from the header information and send the metadata document retrieval request to the server based on the metadata retrieval address, so that the server determines the corresponding protected resource metadata document based on the metadata document retrieval request, adds the target privacy level corresponding to the target tool to the protected resource metadata document, and returns the added protected resource metadata document to the client. A privacy level acquisition unit is used to acquire the target privacy level from the newly added protected resource metadata document; The target privacy level is a privacy level dynamically determined by the server based on the functional characteristics, data type, and historical call behavior of the target tool.
[0057] In some specific embodiments, the user authorization module 11 includes: The third request sending unit is used to extract the metadata acquisition address of the authorization service from the newly added protected resource metadata document, and send the metadata acquisition request to the authorization service based on the metadata acquisition address, so that the authorization service returns its own metadata to the client based on the metadata acquisition request; The login page access unit is used to obtain the login page of the authorization service based on the metadata of the authorization service, and access the login page to authorize the user, so that the authorization service can collect the user environment through the login page and determine the target trust score of the client based on the user environment; The user environment includes any one or a combination of several of the client's device information, location information, time information, and operation behavior information, and the authorization service dynamically adjusts the target trust score when it detects a change in the user environment.
[0058] In some specific embodiments, the server-side tool access device further includes: The comparison result determination unit is used to determine the comparison result between the target trust score and the target trust threshold; The first token issuing unit is used to determine that user authorization is passed if the comparison result indicates that the target trust score is not less than the target trust threshold, and to issue a restricted token carrying the access permission range corresponding to the target privacy level to the client.
[0059] In some specific embodiments, the server-side tool access device further includes: The trust threshold determination unit is used to determine other privacy levels lower than the target privacy level from each privacy level if the comparison result indicates that the target trust score is less than the target trust threshold, and to determine whether there are candidate trust thresholds that are not greater than the target trust score among the trust thresholds corresponding to the other privacy levels. The second token issuing unit is used to determine, if present, the maximum trust threshold from the candidate trust thresholds, determine the appropriate privacy level corresponding to the maximum trust threshold, and issue a restricted token carrying the access permission range corresponding to the appropriate privacy level to the client.
[0060] In some specific embodiments, the server-side tool access device further includes: The third token issuing unit is used to trigger the client to perform secondary verification if the comparison result indicates that the target trust score is less than the target trust threshold. After the secondary verification is passed, the target trust score is raised to a preset trust score, and a restricted token carrying the access permission range corresponding to the target privacy level is issued to the client. Wherein, the preset trust score is not less than the target trust threshold.
[0061] In some specific embodiments, the server-side tool access device further includes: The access denial unit is used to determine that user authorization has failed if the comparison result indicates that the target trust score is less than the target trust threshold, and to send an access denial error message to the client.
[0062] Furthermore, embodiments of this application also disclose an electronic device, Figure 4 This is a structural diagram of an electronic device 20 according to an exemplary embodiment. The content of the diagram should not be construed as limiting the scope of this application.
[0063] Figure 4 This is a schematic diagram of the structure of an electronic device 20 provided in an embodiment of this application. Specifically, the electronic device 20 may include: at least one processor 21, at least one memory 22, a power supply 23, a communication interface 24, an input / output interface 25, and a communication bus 26. The memory 22 stores a computer program, which is loaded and executed by the processor 21 to implement the relevant steps in the server-side tool access method disclosed in any of the foregoing embodiments. Furthermore, the electronic device 20 in this embodiment may specifically be an electronic computer.
[0064] In this embodiment, the power supply 23 is used to provide operating voltage for each hardware device on the electronic device 20; the communication interface 24 can create a data transmission channel between the electronic device 20 and external devices, and the communication protocol it follows can be any communication protocol applicable to the technical solution of this application, and is not specifically limited here; the input / output interface 25 is used to acquire external input data or output data to the outside world, and its specific interface type can be selected according to specific application needs, and is not specifically limited here.
[0065] In addition, the memory 22, as a carrier for resource storage, can be a read-only memory, random access memory, disk or optical disk, etc. The resources stored thereon can include operating system 221, computer program 222, etc., and the storage method can be temporary storage or permanent storage.
[0066] The operating system 221 is used to manage and control the various hardware devices on the electronic device 20 and the computer program 222, which may be Windows Server, Netware, Unix, Linux, etc. In addition to including a computer program capable of performing the server-side tool access method executed by the electronic device 20 as disclosed in any of the foregoing embodiments, the computer program 222 may further include a computer program capable of performing other specific tasks.
[0067] Furthermore, this application also discloses a computer-readable storage medium for storing a computer program; wherein, when the computer program is executed by a processor, it implements the aforementioned server-side tool access method. The specific steps of this method can be found in the corresponding content disclosed in the foregoing embodiments, and will not be repeated here.
[0068] The various embodiments in this specification are described in a progressive manner, with each embodiment focusing on its differences from other embodiments. Similar or identical parts between embodiments can be referred to interchangeably. For the apparatus disclosed in the embodiments, since it corresponds to the method disclosed in the embodiments, the description is relatively simple; relevant parts can be referred to in the method section.
[0069] Those skilled in the art will further recognize that the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, computer software, or a combination of both. To clearly illustrate the interchangeability of hardware and software, the components and steps of the various examples have been generally described in terms of functionality in the foregoing description. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can 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.
[0070] The steps of the methods or algorithms described in conjunction with the embodiments disclosed herein can be implemented directly by hardware, a software module executed by a processor, or a combination of both. The software module can be located in random access memory (RAM), main memory, read-only memory (ROM), electrically programmable ROM, electrically erasable programmable ROM, registers, hard disk, removable disk, CD-ROM, or any other form of storage medium known in the art.
[0071] Finally, it should be noted that in this document, relational terms such as "first" and "second" are used only to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Furthermore, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitations, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes said element.
[0072] The technical solutions provided in this application have been described in detail above. Specific examples have been used to illustrate the principles and implementation methods of this application. The descriptions of the above embodiments are only for the purpose of helping to understand the methods and core ideas of this application. At the same time, for those skilled in the art, there will be changes in the specific implementation methods and application scope based on the ideas of this application. Therefore, the content of this specification should not be construed as a limitation of this application.
Claims
1. A method for accessing server-side tools, characterized in that, Applied to the client side, including: After obtaining the target privacy level corresponding to the target tool from the server based on the unauthenticated access request, the user authorizes the login page of the authorization service so that the authorization service can determine the target trust score of the client based on the user environment of the login page. A token acquisition request carrying the target privacy level is sent to the authorization service so that the authorization service can determine the target trust threshold corresponding to the target privacy level. If the user authorization is determined to be successful based on the comparison result of the target trust score and the target trust threshold, a restricted token carrying the access permission range is issued to the client. The client sends a tool access request carrying the restricted token to the server, so that the server responds to the tool access request by performing a preset verification operation and determines whether to allow the client to access the target tool based on the verification result; the preset verification operation includes verifying the validity of the restricted token, the target trust score and the access permission range, or any combination of several of these.
2. The server-side tool access method according to claim 1, characterized in that, The process of obtaining the target privacy level of the target tool from the server based on the unauthenticated access request includes: An unauthenticated access request for the target tool is sent to the server, so that the server returns an unauthenticated error containing header information to the client based on the unauthenticated access request; Extract the metadata retrieval address from the header information, and send the metadata document retrieval request to the server based on the metadata retrieval address, so that the server can determine the corresponding protected resource metadata document based on the metadata document retrieval request, add the target privacy level corresponding to the target tool to the protected resource metadata document, and return the added protected resource metadata document to the client; Obtain the target privacy level from the newly added protected resource metadata document; The target privacy level is a privacy level dynamically determined by the server based on the functional characteristics, data type, and historical call behavior of the target tool.
3. The server-side tool access method according to claim 2, characterized in that, The login page of the access authorization service authorizes the user so that the authorization service can determine the target trust score of the client based on the user environment on the login page, including: Extract the metadata retrieval address of the authorization service from the newly added protected resource metadata document, and send the metadata retrieval request to the authorization service based on the metadata retrieval address, so that the authorization service can return its own metadata to the client based on the metadata retrieval request; The authorization service obtains the login page of the authorization service based on the metadata of the authorization service, and accesses the login page to authorize the user, so that the authorization service can collect the user environment through the login page and determine the target trust score of the client based on the user environment; The user environment includes any one or a combination of several of the client's device information, location information, time information, and operation behavior information, and the authorization service dynamically adjusts the target trust score when it detects a change in the user environment.
4. The server-side tool access method according to any one of claims 1 to 3, characterized in that, After the authorization service determines the target trust threshold corresponding to the target privacy level, it also includes: Determine the comparison result between the target trust score and the target trust threshold; If the comparison result indicates that the target trust score is not less than the target trust threshold, then the user authorization is determined to be successful, and a restricted token carrying the access permission range corresponding to the target privacy level is issued to the client.
5. The server-side tool access method according to claim 4, characterized in that, After determining the comparison result between the target trust score and the target trust threshold, the method further includes: If the comparison result indicates that the target trust score is less than the target trust threshold, then other privacy levels lower than the target privacy level are determined from each privacy level, and it is determined whether there are candidate trust thresholds that are not greater than the target trust score among the trust thresholds corresponding to the other privacy levels. If it exists, then determine the maximum trust threshold from the candidate trust thresholds, determine the appropriate privacy level corresponding to the maximum trust threshold, and issue a restricted token carrying the access permission range corresponding to the appropriate privacy level to the client.
6. The server-side tool access method according to claim 4, characterized in that, After determining the comparison result between the target trust score and the target trust threshold, the method further includes: If the comparison result indicates that the target trust score is less than the target trust threshold, the client is triggered to perform secondary verification. After the secondary verification is passed, the target trust score is raised to a preset trust score, and a restricted token carrying the access permission range corresponding to the target privacy level is issued to the client. Wherein, the preset trust score is not less than the target trust threshold.
7. The server-side tool access method according to claim 4, characterized in that, After determining the comparison result between the target trust score and the target trust threshold, the method further includes: If the comparison result indicates that the target trust score is less than the target trust threshold, then it is determined that the user authorization has not been approved, and an abnormal prompt message of access denial is sent to the client.
8. A server-side tool access device, characterized in that, Applied to the client side, including: The user authorization module is used to access the login page of the authorization service to authorize the user after obtaining the target privacy level corresponding to the target tool from the server based on the unauthenticated access request, so that the authorization service can determine the target trust score of the client based on the user environment of the login page. The first request sending module is used to send a token acquisition request carrying the target privacy level to the authorization service, so that the authorization service can determine the target trust threshold corresponding to the target privacy level. If the user authorization is determined to be successful based on the comparison result of the target trust score and the target trust threshold, a restricted token carrying the access permission range is issued to the client. The second request sending module is used to send a tool access request carrying the restricted token to the server, so that the server responds to the tool access request by performing a preset verification operation and determines whether to allow the client to access the target tool based on the verification result; the preset verification operation includes verifying the validity of the restricted token, the target trust score and the access permission range, or any combination of several of them.
9. An electronic device, characterized in that, include: Memory, used to store computer programs; A processor for executing the computer program to implement the server tool access method as described in any one of claims 1 to 7.
10. A computer-readable storage medium, characterized in that, Used to store a computer program, which, when executed by a processor, implements the server tool access method as described in any one of claims 1 to 7.