Request processing method and apparatus, computer device, and readable storage medium

Abstract

This application relates to a request processing method, apparatus, computer device, and readable storage medium. The method includes: after a client completes login and sends a resource request to a resource server, parsing an authentication request generated by the resource server in response to the resource request to obtain a session identifier corresponding to the client; if the session identifier meets the token construction conditions, constructing an OAuth2 token matching the session identifier; obtaining OAuth2 authorization information based on the OAuth2 token and its corresponding token parameters; and sending the OAuth2 authorization information to the resource server, so that the resource server can return a request result matching the resource request to the client based on the OAuth2 authorization information. This method simplifies permission management and optimizes the request processing process.

Description

Technical Field

[0001] This application relates to the field of computer technology, and in particular to a request processing method, apparatus, computer device, and readable storage medium. Background Technology

[0002] In the software development field, OAuth2 and Session are two commonly used authentication and authorization strategies in different scenarios, each with its own emphasis in terms of permission management logic and application scenarios. For example, in the process of developing a Model Context Protocol Server (MCP server) based on the Spring AI framework, it is necessary to encapsulate the microservices and Representational State Transfer (REST) ​​interfaces of various applications into a standardized MCP tool, and provide capabilities to the outside world through the MCP server. In this process, permission management is a core supporting link. The MCP server needs to obtain authentication data from its own permission system to implement access control, but currently the MCP server only supports the OAuth2 authorization mode; however, the application interfaces that the MCP service backend connects to may use the traditional Session authorization scheme for permission control. This asymmetry leads to two independent permission systems running in parallel.

[0003] However, because OAuth2 and Session authorization policies store, manage, and validate the same user, resource, and permission data separately, they not only cause problems such as duplicate storage of permission data and redundant maintenance processes, but also significantly increase the complexity of the system architecture. For example, permission configuration needs to be operated separately in the two systems, and permission changes need to be adapted to both logics simultaneously, which can easily lead to risks such as inconsistent permission data and configuration omissions, seriously affecting the development efficiency, maintenance costs, and operational stability of the MCP server. In addition, obtaining an access token requires redirecting to the authorization server for user authentication and authorization, and then redirecting back, which is a cumbersome process that seriously affects the user experience. Therefore, an innovative solution is urgently needed to achieve deep integration of OAuth2 and Session, connect the data links of the two permission systems, and achieve unified management and interoperability of permission data. Summary of the Invention

[0004] Therefore, it is necessary to provide a request processing method, apparatus, computer device, and readable storage medium that can simplify permission management and optimize the request processing process to address the aforementioned technical problems.

[0005] Firstly, this application provides a request processing method, including:

[0006] When the client completes login and the client sends a resource request to the resource server, the authentication request generated by the resource server in response to the resource request is parsed to obtain the session identifier corresponding to the client.

[0007] If the session identifier meets the token construction conditions, construct an OAuth2 token that matches the session identifier;

[0008] Based on the OAuth2 token and the token parameters corresponding to the OAuth2 token, the OAuth2 authorization information is obtained;

[0009] The OAuth2 authorization information is sent to the resource server so that the resource server can return a request result matching the resource request to the client based on the OAuth2 authorization information.

[0010] In one embodiment, constructing the OAuth2 token that matches the session identifier includes:

[0011] Obtain the session creation time and session timeout duration that match the session identifier;

[0012] The statistical duration of the session timeout and the preset duration is determined;

[0013] Using the session creation time as the token issuance time and the time after the statistical duration starting from the current time as the token expiration time, an OAuth2 token matching the session identifier is obtained.

[0014] In one embodiment, the method for obtaining the token parameter corresponding to the OAuth2 token includes:

[0015] Identify the authentication object that matches the session identifier, and extract the username from the authentication object;

[0016] Extract the set of authorization scopes that match the username from the set of permissions of the authenticated object;

[0017] The session identifier and the authorization scope set are combined to obtain the token parameters corresponding to the OAuth2 token.

[0018] In one embodiment, obtaining the OAuth2 authorization information based on the OAuth2 token and the token parameters corresponding to the OAuth2 token includes:

[0019] Bind the OAuth2 token to the token parameter corresponding to the OAuth2 token to obtain the initial authorization information;

[0020] The initial authorization information is initialized to obtain OAuth2 authorization information.

[0021] In one embodiment, initializing the initial authorization information to obtain OAuth2 authorization information includes:

[0022] Based on the authorization code pattern and username that match the session identifier, as well as the token validity time and token identifier of the OAuth2 token, the claim metadata is obtained;

[0023] By binding the initial authorization information and the claim metadata, OAuth2 authorization information is obtained.

[0024] In one embodiment, determining the authentication object matching the session identifier includes:

[0025] If a user session matching the session identifier is retrieved from the session repository, the security context is extracted from the user session.

[0026] From the security context, determine the authentication object that matches the session identifier.

[0027] In one embodiment, the session identifier satisfies token construction conditions, including any one of the following:

[0028] First item:

[0029] If no matching OAuth2 token exists for the session identifier, it is determined that the session identifier meets the token construction conditions;

[0030] Second item:

[0031] If a matching OAuth2 token exists for the session identifier, and the type of the matching OAuth2 token is consistent with the preset token type, then the session identifier is determined to meet the token construction conditions.

[0032] Secondly, this application provides a request processing apparatus, the apparatus comprising:

[0033] The parsing module is used to parse the authentication request generated by the resource server in response to the resource request after the client completes login and the client sends a resource request to the resource server, so as to obtain the session identifier corresponding to the client.

[0034] The building module is used to build an OAuth2 token that matches the session identifier if the session identifier meets the token building conditions;

[0035] The processing module is used to obtain OAuth2 authorization information based on the OAuth2 token and the token parameters corresponding to the OAuth2 token;

[0036] The sending module is used to send the OAuth2 authorization information to the resource server, so that the resource server can send a request result matching the resource request back to the client based on the OAuth2 authorization information.

[0037] Thirdly, this application also provides a computer device, including a memory and a processor, wherein the memory stores a computer program, and the processor executes the computer program to perform the following steps:

[0038] When the client completes login and the client sends a resource request to the resource server, the authentication request generated by the resource server in response to the resource request is parsed to obtain the session identifier corresponding to the client.

[0039] If the session identifier meets the token construction conditions, construct an OAuth2 token that matches the session identifier;

[0040] Based on the OAuth2 token and the token parameters corresponding to the OAuth2 token, the OAuth2 authorization information is obtained;

[0041] The OAuth2 authorization information is sent to the resource server so that the resource server can return a request result matching the resource request to the client based on the OAuth2 authorization information.

[0042] Fourthly, this application also provides a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, performs the following steps:

[0043] When the client completes login and the client sends a resource request to the resource server, the authentication request generated by the resource server in response to the resource request is parsed to obtain the session identifier corresponding to the client.

[0044] If the session identifier meets the token construction conditions, construct an OAuth2 token that matches the session identifier;

[0045] Based on the OAuth2 token and the token parameters corresponding to the OAuth2 token, the OAuth2 authorization information is obtained;

[0046] The OAuth2 authorization information is sent to the resource server so that the resource server can return a request result matching the resource request to the client based on the OAuth2 authorization information.

[0047] Fifthly, this application also provides a computer program product, including a computer program that, when executed by a processor, performs the following steps:

[0048] When the client completes login and the client sends a resource request to the resource server, the authentication request generated by the resource server in response to the resource request is parsed to obtain the session identifier corresponding to the client.

[0049] If the session identifier meets the token construction conditions, construct an OAuth2 token that matches the session identifier;

[0050] Based on the OAuth2 token and the token parameters corresponding to the OAuth2 token, the OAuth2 authorization information is obtained;

[0051] The OAuth2 authorization information is sent to the resource server so that the resource server can return a request result matching the resource request to the client based on the OAuth2 authorization information.

[0052] The aforementioned request processing method, apparatus, computer device, and readable storage medium, upon client login and the client sending a resource request to the resource server, parse the authentication request generated by the resource server in response to the resource request to obtain the client's corresponding session identifier. If the session identifier meets the token construction conditions, an OAuth2 token matching the session identifier is constructed. Then, based on the OAuth2 token and its corresponding token parameters, OAuth2 authorization information is obtained and sent to the resource server. This allows the resource server to return a request result matching the resource request to the client based on the OAuth2 authorization information. Therefore, by constructing an OAuth2 token based on the session identifier and binding the OAuth2 token with its corresponding token parameters, session identifier-related content can be converted into OAuth2 content, achieving unification between the session mechanism and the OAuth2 mechanism. Thus, by integrating the session mechanism and the OAuth2 mechanism, redundant permission management steps in the MCP service architecture can be simplified, reducing repetitive configuration and maintenance work, and lowering manpower and time costs. Furthermore, by connecting the data links of the two mechanisms, unified synchronization and consistency verification of permission data can be achieved, fundamentally avoiding the risks caused by data inconsistency and ensuring the stable and reliable operation of the MCP server. Moreover, by building a simpler permission management architecture and achieving compatibility with different authorization modes and permission configuration methods, the difficulty of developing new features and expanding the system can be reduced, improving overall development efficiency. Attached Figure Description

[0053] To more clearly illustrate the technical solutions in the embodiments of this application or related technologies, the drawings used in the description of the embodiments of this application or related technologies will be briefly introduced below. Obviously, the drawings described below are only some embodiments of this application. For those skilled in the art, other related drawings can be obtained based on these drawings without creative effort.

[0054] Figure 1 This is a flowchart illustrating a request processing method in one embodiment;

[0055] Figure 2 This is a schematic diagram illustrating the process of constructing an OAuth2 token that matches the session identifier in one embodiment;

[0056] Figure 3 This is a flowchart illustrating how to obtain the token parameters corresponding to an OAuth2 token in one embodiment.

[0057] Figure 4 This is a flowchart illustrating the request processing method in another embodiment;

[0058] Figure 5 This is a structural block diagram of a request processing device in one embodiment;

[0059] Figure 6 This is an internal structural diagram of a computer device in one embodiment;

[0060] Figure 7 This is a diagram of the internal structure of a computer device in another embodiment. Detailed Implementation

[0061] To make the objectives, technical solutions, and advantages of this application clearer, the following detailed description is provided in conjunction with the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative and not intended to limit the scope of this application.

[0062] It should be noted that the terms "first," "second," etc., used in this application can be used to describe various elements, but these elements are not limited by these terms. These terms are only used to distinguish the first element from the second element. The terms "comprising" and "having," and any variations thereof, used in this application, are intended to cover non-exclusive inclusion. The term "multiple" used in this application refers to two or more. The term "and / or" used in this application refers to one of the embodiments, or any combination of multiple embodiments.

[0063] The Session mechanism is a core mechanism used by Web servers to maintain user state, specifically referring to a series of continuous interactions between a user and the Web server. The Hypertext Transfer Protocol (HTTP) is inherently stateless, meaning that servers cannot directly associate multiple user requests through the protocol itself; each request is treated as an independent and entirely new access. To address this issue, the Session mechanism was developed. The server generates a unique Session Identifier (ID) for each first-time user and binds the user's state information (such as login credentials, shopping cart data, preferences, etc.) to the SessionID, storing it on the server. In subsequent client requests (if the client is a browser, the SessionID is usually stored in a cookie), this SessionID is automatically included. By verifying the SessionID in the request, the server can accurately match the corresponding user state data, thereby effectively identifying and maintaining the user's state throughout the continuous interaction process.

[0064] OAuth is an open standard designed to enable third-party applications to securely access users' private resources. Through this standard, users can access their private resources (such as photos, videos, and contact lists) stored on a platform (such as social networking sites or cloud storage services) without exposing their account and password to the third-party application, using an AccessToken. Its core authorization process follows the logic of "user authorization - credential exchange," ensuring user information security throughout. Specifically, the third-party application first redirects the user to a trusted authorization server interface; after the user enters their account and password to complete identity authentication and confirm authorization, the authorization server issues an authorization code to the application; the third-party application then uses the authorization code to call the authorization server interface, ultimately exchanging for an access token. Throughout the entire process, the third-party application cannot access the user's core sensitive information such as account and password, thus fundamentally avoiding the risk of information leakage.

[0065] The OAuth system ensures the orderliness and security of the authorization process by clearly defining four roles. The roles and their corresponding responsibilities are as follows: **Authorization Server:** As the core hub of the entire authorization process, the Authorization Server is primarily responsible for: verifying the identity of the resource owner (user); issuing access tokens to the client (third-party application) based on the user's authorization decision; and handling key functions such as validating access tokens and querying authorization information. **Resource Server:** Responsible for hosting and protecting the user's private resources and processing resource access requests from clients. The Resource Server's core responsibilities are: verifying the validity and expiration of the access token carried in the request, and whether it has the necessary permissions to access the target resource; only after successful verification will it return the corresponding protected resource to the client. **Resource Owner:** Typically refers to the end user, the legal owner of the protected resource; the resource owner has control over their own resources and can independently decide whether to grant clients access to their private resources. **Client:** Typically refers to a third-party application, the entity that needs to access the user's private resources; the client must request access to the corresponding protected resource from the Resource Server with the authorization of the resource owner and a valid access token.

[0066] The existing pain points in the permission management architecture of MCP server development stem from the independent operation of two permission systems, OAuth2 and Session, which bring numerous problems. Specifically, in an MCP server based on the SpringAI framework, providing services externally relies on the OAuth2 authorization mode, while the backend application interfaces may use the traditional Session authorization scheme. The two systems store and maintain the same user, resource, and permission data separately, leading to duplicate permission data and overlapping management processes. Therefore, by integrating the core mechanisms of both systems, redundant permission management steps are streamlined, reducing repetitive configuration and maintenance work, lowering manpower and time costs, thereby eliminating permission system redundancy and reducing system management costs. Because the two permission systems operate independently, permission configuration and changes must be performed separately in each, which easily leads to problems such as configuration asynchrony, data mismatch, or omissions, resulting in security risks such as unauthorized access and permission invalidation, affecting the reliable operation of the MCP service. Therefore, by connecting the data links of the two systems, unified synchronization and consistency verification of permission data can be achieved, fundamentally avoiding the risks caused by data inconsistency, ensuring stable service operation, and thus solving the risk of permission data inconsistency and improving system stability. The parallel operation of two independent permission systems increases the complexity of the MCP service architecture, hindering the access of new microservice interfaces and the expansion of authorization scenarios (such as the need to adapt two permission logics to new interfaces). Based on this, a simpler permission management architecture can be built to achieve compatibility with different authorization modes and permission configuration methods, reduce the difficulty of developing new functions and expanding the system, and improve the overall development or expansion efficiency.

[0067] Therefore, since a user has a session identifier while logged in, third-party applications can use this session identifier as an access token when requesting the resource server's Application Programming Interface (API). The resource server doesn't care about or know whether the access token was previously issued by the authorization server; it can request the authorization server to verify the access token. Thus, by implementing a mapping between session identifiers and access tokens on the authorization server, the corresponding session can be found using the session identifier, and the user authorization information stored in the session can be mapped to the authorization information required for OAuth. This eliminates the cumbersome process of obtaining an access token through a user interface, improving the user experience.

[0068] In view of this, such as Figure 1 As shown, this application provides a request processing method, which is illustrated using an authorization server as an example. The method includes the following steps:

[0069] S102: After the client completes login and sends a resource request to the resource server, the authentication request generated by the resource server in response to the resource request is parsed to obtain the session identifier corresponding to the client.

[0070] In this context, the client refers to a third-party application. The client's login process signifies that the user has entered their account and password to a trusted authorization server to complete identity authentication. In this case, the authorization server issues a session ID to the client. Based on this session ID, the client can then request a resource from the resource server.

[0071] Among them, a resource request refers to a request sent by the client to call the API of the resource server, which is used to obtain a request result matching the resource request from the resource server based on the API of the resource server.

[0072] Specifically, the client sends a resource request to the resource server, including: the client sending the resource request to the resource server in the form of a message, the message corresponding to the resource request carrying a session identifier.

[0073] Specifically, when receiving a message corresponding to a resource request from a client, the resource server parses the client's session identifier from the message corresponding to the resource request.

[0074] An authentication request is a request to authenticate a resource request sent by a client. The resource server sends an authentication request to the authorization server, and the authentication request carries a session identifier. The authorization server can obtain the corresponding session identifier of the client by parsing the authentication request.

[0075] S104. If the session identifier meets the token construction conditions, construct an OAuth2 token that matches the session identifier.

[0076] In one embodiment, determining that a session identifier satisfies the token construction condition includes: determining that the session identifier satisfies the token construction condition when no matching OAuth2 token exists for the session identifier. That is, determining that the session identifier satisfies the token construction condition when it is determined that the OAuth2 token corresponding to the session identifier is empty.

[0077] In one embodiment, if a matching OAuth2 token exists for the session identifier, and the type of the matching OAuth2 token matches the type of the access token, then the session identifier is determined to meet the token construction conditions. That is, it determines whether the type of the OAuth2 token corresponding to the session identifier is an access token type (OAuth2TokenType.ACCESS_TOKEN). Considering the short validity period of access tokens, if the type of the OAuth2 token corresponding to the session identifier is an access token type, then the session identifier is also determined to meet the token construction conditions.

[0078] In one embodiment, if the session identifier does not meet the token construction conditions, the `findByToken` method of the delegated authorization service (OAuth2AuthorizationService) returns a query result or an empty string. The query result represents OAuth2 authentication object information, which includes, but is not limited to: the client's identifier, the principal identifier of the resource owner granting the authorization, and the authorization type used.

[0079] S106. Obtain OAuth2 authorization information based on the OAuth2 token and the token parameters corresponding to the OAuth2 token.

[0080] The OAuth2 authorization information can be obtained based on the OAuth2 token and its corresponding token parameters using the following method:

[0081] In one embodiment, OAuth2 authorization information is obtained based on the OAuth2 token and its corresponding token parameters. This includes: binding the OAuth2 token and its corresponding token parameters to obtain initial authorization information; and initializing the initial authorization information to obtain the final OAuth2 authorization information. Thus, by binding the OAuth2 token and its corresponding token parameters, session identifier-related content can be converted into OAuth2 content, achieving unification between the session mechanism and the OAuth2 mechanism. Therefore, by integrating the session mechanism and the OAuth2 mechanism, redundant permission management steps in the MCP service architecture can be simplified, reducing repetitive configuration and maintenance work, and lowering manpower and time costs.

[0082] Specifically, the initial authorization information is initialized to obtain OAuth2 authorization information, including: authorization code pattern and username matching the session identifier, and token validity time and token identifier of the OAuth2 token, to obtain claim metadata; the initial authorization information and claim metadata are then bound to obtain the OAuth2 authorization information. Therefore, by binding the initial authorization information and claim metadata, the normal use of OAuth2 authorization information can be guaranteed, thereby improving the stability and reliability of the MCP server's service.

[0083] The metadata declaration includes the username (Subject, SUB), the resource server's server identifier (Audience, AUD), the token validity period (Not Before, NBF), the token identifier (JWT ID, JTI), and the authorization code pattern. The token validity period can refer to the token issuance time of the OAuth2 token corresponding to the session identifier, or it can refer to the time after a preset interval following the token issuance time of the OAuth2 token. For example, the token validity period refers to the time after a 2-hour interval following the token issuance time of the OAuth2 token. The OAuth2 token issuance time refers to the session creation time matching the session identifier. The token identifier is used to uniquely identify the OAuth2 token.

[0084] S108, send OAuth2 authorization information to the resource server so that the resource server can send a request result that matches the resource request to the client based on the OAuth2 authorization information.

[0085] Specifically, the resource server returns a request result matching the resource request to the client based on the OAuth2 authorization information. This includes: the resource server parsing the OAuth2 authorization information to obtain an authorization scope set; and, based on the authorization scope set, determining that the client has access rights to the request result matching the resource request, returning the request result matching the resource request to the client. The request result includes, but is not limited to, photos, videos, and contact lists.

[0086] In some cases, if the server determines, based on the authorized scope set, that the client does not have access rights to the result of a resource request that matches the request, a preset message is displayed to the client. This preset message indicates a 403 error, meaning insufficient permissions. In other words, if the client does not have access rights to the result of a resource request that matches the request, the resource server can deny the client access to the corresponding API.

[0087] Using the method described in the above embodiments, after the client completes login and sends a resource request to the resource server, the authentication request generated by the resource server in response to the resource request is parsed to obtain the client's corresponding session identifier. If the session identifier meets the token construction conditions, an OAuth2 token matching the session identifier is constructed. Then, based on the OAuth2 token and its corresponding token parameters, OAuth2 authorization information is obtained and sent to the resource server. This allows the resource server to return a request result matching the resource request to the client based on the OAuth2 authorization information. Therefore, by constructing an OAuth2 token based on the session identifier and binding the OAuth2 token with its corresponding token parameters, the content related to the session identifier can be converted into OAuth2 content, achieving unification between the session mechanism and the OAuth2 mechanism. Thus, by integrating the session mechanism and the OAuth2 mechanism, redundant permission management steps in the MCP service architecture can be simplified, reducing repetitive configuration and maintenance work, and lowering manpower and time costs. Furthermore, by connecting the data links of the two mechanisms, unified synchronization and consistency verification of permission data can be achieved, fundamentally avoiding the risks caused by data inconsistency and ensuring the stable and reliable operation of the MCP server. Moreover, by building a simpler permission management architecture and achieving compatibility with different authorization modes and permission configuration methods, the difficulty of developing new features and expanding the system can be reduced, and the overall development efficiency can be improved.

[0088] based on Figure 1 As shown in one embodiment, the method further includes: defining a custom implementation class MyOAuth2AuthorizationService that inherits from OAuth2AuthorizationService; and annotating the implementation class with @Component and @Primary annotations to register the custom implementation class as a Spring-managed bean based on the @Component annotation, and to ensure that Spring prioritizes the implementation class based on the @Primary annotation. In other words, in actual processing, the authorization server can construct a program matching the request handling method of this application based on SpringAuthorizationServer and SpringSession. Specifically, after receiving an authentication request, the authorization server can first process the request according to the default OAuth flow until it reaches the findByToken method of the OAuth2AuthorizationService implementation class, at which point it executes... Figure 1The method shown is as described. Therefore, the request processing method provided in this application implements request processing for resource requests by overriding the findByToken method of the OAuth2AuthorizationService implementation class.

[0089] In one embodiment, such as Figure 2 The diagram illustrates a process for constructing an OAuth2 token that matches a session identifier. Taking the application of this method to an authorization server as an example, it includes the following steps:

[0090] S202, obtain the session creation time and session timeout duration that match the session identifier.

[0091] The session timeout duration refers to the maximum inactivity interval of a session.

[0092] S204, determine the session timeout duration and the statistical duration of the preset duration.

[0093] Specifically, the statistical duration is the sum of the session timeout duration and the preset duration.

[0094] S206. Use the session creation time as the token issuance time, and the time after calculating the interval starting from the current time as the token expiration time, to obtain an OAuth2 token that matches the session identifier.

[0095] Specifically, by using the session creation time as the token issuance time (IAT) and the time elapsed after calculating the interval starting from the current time as the token expiration time, an OAuth2 token of type Bearer that matches the session identifier can be obtained. In the embodiments related to this application, the token expiration time can be 30 days, or it can be set to other values.

[0096] By using the method described in the above embodiments, an OAuth2 token matching the session identifier is constructed by considering the session creation time and session timeout duration corresponding to the session identifier, thereby improving the accuracy of token construction.

[0097] In one embodiment, such as Figure 3 The diagram illustrates a process for obtaining the token parameters corresponding to an OAuth2 token. Taking the application of this method to an authorization server as an example, it includes the following steps:

[0098] S302, determine the authentication object that matches the session identifier, and extract the username from the authentication object.

[0099] In one embodiment, determining an authentication object that matches a session identifier includes: extracting a security context from a user session that matches a session identifier if a user session matching the session identifier is extracted from a session repository; and determining an authentication object that matches the session identifier from the security context.

[0100] Specifically, the security context (SecurityContext) with the key HttpSessionSecurityContextRepository.SPRING_SECURITY_CONTEXT_KEY is extracted from the session repository using the findById method of the session repository.

[0101] Specifically, the authentication object matching the session identifier is obtained from the security context.

[0102] In some cases, if a user session matching the session identifier does not exist in the session repository, or if a user session matching the session identifier exists in the session repository but lacks a security context, or if a user session matching the session identifier exists in the session repository and contains a security context but lacks an authentication object, an empty result is returned to the resource server. In other words, if any of the user session, security context, or authentication object is missing, an empty result is returned to the resource server.

[0103] Specifically, extracting the username from the authentication object includes using the getName method to extract the username from the authentication object.

[0104] S304 Extract the set of authorization scopes that match the username from the set of authentication object permissions.

[0105] Specifically, a streaming processing method can be used to extract the set of authorization scopes that match the username from the authentication object's permission set. The authorization scope set is prefixed with "SCOPE_".

[0106] S306, combine the session identifier and the authorization scope set to obtain the token parameters corresponding to the OAuth2 token.

[0107] Using the method described in the above embodiments, the username can be extracted from the authentication object corresponding to the session identifier. The authorization scope set matching the username can be extracted from the authorization object's permission set. Thus, the token parameter corresponding to the OAuth2 token includes the authorization scope set. Based on the authorization scope set in the token parameter corresponding to the OAuth2 token, requests in real-world scenarios can be verified, thereby improving the security of request processing.

[0108] Based on the above, after the client completes login, when the client needs to call the resource server's API, it can send a resource request to the resource server, including a session ID, without needing to request a traditional OAuth access token from the authorization server. Upon receiving the resource request with the session ID, the resource server follows the standard OAuth authorization verification process. It does not directly judge the validity of the session ID or its associated authorization information, but immediately initiates an authentication request for the session ID to the authorization server. Specifically, the resource server sends an authentication request generated from the resource request to the authorization server. The resource server and the authorization server are located in the same domain.

[0109] Furthermore, such as Figure 4 The diagram illustrates a request processing method, using an authorization server as an example. The method includes the following steps:

[0110] S402 After receiving the authentication request from the resource server, the authorization server first processes it according to the default OAuth process until it reaches the findByToken method of the OAuth2AuthorizationService implementation class.

[0111] S404: The authorization server parses the authentication request from the resource server and obtains the session identifier corresponding to the client.

[0112] S406, Does the session identifier meet the token construction conditions?

[0113] Specifically, if the session identifier meets the token construction conditions, S408 is executed; otherwise, S424 is executed.

[0114] S408, obtain the session creation time and session timeout duration that match the session identifier, and determine the statistical duration of the session timeout duration and the preset duration.

[0115] S410: Use the session creation time as the token issuance time, and the time after calculating the interval starting from the current time as the token expiration time, to obtain an OAuth2 token that matches the session identifier.

[0116] S412, whether to retrieve a user session matching the session identifier from the session repository.

[0117] If a user session matching the session identifier is retrieved from the session repository, S414 is executed; otherwise, S426 is executed.

[0118] S414, whether to extract the security context from the user session.

[0119] If the security context is extracted from the user session, S416 is executed; otherwise, S426 is executed.

[0120] S416, whether the authentication object was extracted from the security context.

[0121] If the authentication object is extracted from the security context, execute S418; otherwise, execute S426.

[0122] S418: Extract the username from the authentication object and extract the set of authorization scopes that match the username from the authentication object's permission set.

[0123] S420, combine the session identifier and the authorization scope set to obtain the token parameters corresponding to the OAuth2 token.

[0124] S422, based on the OAuth2 token and the token parameters corresponding to the OAuth2 token, obtain the OAuth2 authorization information.

[0125] Specifically, the initial authorization information is obtained by binding the OAuth2 token with the corresponding token parameters; the claim metadata is obtained based on the authorization code pattern and username that match the session identifier, as well as the token validity time and token identifier of the OAuth2 token; and the OAuth2 authorization information is obtained by binding the initial authorization information and the claim metadata.

[0126] S424 returns the query results to the resource server.

[0127] S426 returns an empty result to the resource server.

[0128] S428, send OAuth2 authorization information to the resource server so that the resource server can send a request result that matches the resource request to the client based on the OAuth2 authorization information.

[0129] Specifically, the resource server parses the OAuth2 authorization information to obtain the authorization scope set; based on the authorization scope set, if it determines that the client has access rights to the request result that matches the resource request, it sends the request result that matches the resource request back to the client.

[0130] In some cases, if it is determined, based on the set of authorized scopes, that the client does not have access rights to the result of the resource request that matches the request, a preset prompt is entered into the client. The preset prompt is used to indicate a 403 error, that is, insufficient permissions.

[0131] The contents of S430-S428 can be referred to the aforementioned content description, and will not be repeated here.

[0132] As shown above, the method provided in this application innovatively eliminates the two redirection steps required to obtain the access token in traditional OAuth2 authorization, directly reusing the Session ID in the user's logged-in state as the access token. This significantly improves the smoothness of user operations, avoids the fragmented experience caused by multi-step redirection, and thus optimizes the user interaction experience and simplifies the authorization process. Furthermore, it adopts a design pattern of "core logic rewriting + non-core logic delegation," maximizing the reuse of existing code functionality. Only lightweight modifications such as customizing the OAuth2AuthorizationService implementation class are needed to achieve the integration of the two systems without changing the original verification logic of the resource server. This design maintains code conciseness, implements OAuth authorization based on SessionID, and significantly improves system maintainability, reducing development and iteration costs. Thus, it achieves elegant compatibility with minimal modifications and ensures code quality. In addition, to address the adaptation challenges of the OAuth2 "AccessToken-resource scope" and Spring Security's "user-role-permission-resource" heterogeneous models, an innovative configurable permission mapping engine is designed. By pre-setting a semantic parsing-based mapping rule base, it supports custom permission identifier dimensions and format conversion logic, enabling automatic matching and accurate conversion of permission data under different models. This completely solves the problem of permission data mismatch and omission in traditional solutions, ensuring the consistency of permission data inside and outside the MCP service. Thus, through the heterogeneous permission model adaptation architecture, accurate cross-system data interoperability can be achieved.

[0133] It should be understood that although the steps in the flowcharts of the embodiments described above are shown sequentially according to the arrows, these steps are not necessarily executed in the order indicated by the arrows. Unless explicitly stated herein, there is no strict order restriction on the execution of these steps, and they can be executed in other orders. Moreover, at least some steps in the flowcharts of the embodiments described above may include multiple steps or multiple stages. These steps or stages are not necessarily completed at the same time, but can be executed at different times. The execution order of these steps or stages is not necessarily sequential, but can be performed alternately or in turn with other steps or at least some of the steps or stages in other steps. It is understood that the steps in different embodiments can be freely combined as needed, and all non-contradictory solutions formed by such combinations are within the scope of protection of this application.

[0134] Based on the same inventive concept, this application also provides a request processing apparatus for implementing the request processing method described above. The solution provided by this apparatus is similar to the implementation described in the above method; therefore, the specific limitations in one or more request processing apparatus embodiments provided below can be found in the limitations of the request processing method described above, and will not be repeated here.

[0135] In one exemplary embodiment, such as Figure 5 As shown, a request processing apparatus is provided, including: a parsing module 502, a construction module 504, a processing module 506, and a sending module 508, wherein:

[0136] The parsing module 502 is used to parse the authentication request generated by the resource server for the resource request after the client completes login and the client sends a resource request to the resource server, and obtain the session identifier corresponding to the client; the construction module 504 is used to construct an OAuth2 token matching the session identifier if the session identifier meets the token construction conditions; the processing module 506 is used to obtain OAuth2 authorization information based on the OAuth2 token and the token parameters corresponding to the OAuth2 token; and the sending module 508 is used to send the OAuth2 authorization information to the resource server so that the resource server can return a request result matching the resource request to the client based on the OAuth2 authorization information.

[0137] In one embodiment, the construction module 504 is further configured to: obtain the session creation time and session timeout duration that match the session identifier; determine the statistical duration of the session timeout duration and the preset duration; use the session creation time as the token issuance time, and the time after the statistical duration starting from the current time as the token expiration time, to obtain an OAuth2 token that matches the session identifier.

[0138] In one embodiment, the processing module 506 is further configured to: determine an authentication object that matches the session identifier, and extract a username from the authentication object; extract an authorization scope set that matches the username from the authentication object's permission set; and combine the session identifier and the authorization scope set to obtain the token parameter corresponding to the OAuth2 token.

[0139] In one embodiment, the processing module 506 is further configured to: bind the OAuth2 token to the token parameter corresponding to the OAuth2 token to obtain initial authorization information; initialize the initial authorization information to obtain OAuth2 authorization information.

[0140] In one embodiment, the processing module 506 is further configured to: obtain claim metadata based on the authorization code pattern and username matching the session identifier, as well as the token validity time and token identifier of the OAuth2 token; and bind the initial authorization information and the claim metadata to obtain OAuth2 authorization information.

[0141] In one embodiment, the processing module 506 is further configured to: extract a security context from the user session if a user session matching the session identifier is extracted from the session repository; and determine an authentication object matching the session identifier from the security context.

[0142] In one embodiment, the construction module 504 is further configured to perform any of the following: First, if no matching OAuth2 token exists for the session identifier, determine that the session identifier meets the token construction conditions; Second, if a matching OAuth2 token exists for the session identifier, and the type of the matching OAuth2 token is consistent with a preset token type, determine that the session identifier meets the token construction conditions.

[0143] Each module in the aforementioned request processing device can be implemented entirely or partially through software, hardware, or a combination thereof. These modules can be embedded in or independent of the processor in a computer device in hardware form, or stored in the memory of a computer device in software form, so that the processor can invoke and execute the operations corresponding to each module.

[0144] In one exemplary embodiment, a computer device is provided, which may be an authorization server, and its internal structure diagram may be as follows: Figure 6 As shown, this computer device includes a processor, memory, input / output interfaces (I / O), and a communication interface. The processor, memory, and I / O interfaces are connected via a system bus, and the communication interface is also connected to the system bus via the I / O interfaces. The processor provides computational and control capabilities. The memory includes non-volatile storage media and internal memory. The non-volatile storage media stores the operating system, computer programs, and a database. The internal memory provides the environment for the operation of the operating system and computer programs stored in the non-volatile storage media. The database stores data during request processing. The I / O interfaces are used for exchanging information between the processor and external devices. The communication interface is used for communicating with external terminals via a network connection. When the computer program is executed by the processor, it implements a request processing method.

[0145] In one exemplary embodiment, a computer device is provided, which may be an authorization server, and its internal structure diagram may be as follows: Figure 7 As shown, the computer device includes a processor, memory, input / output interfaces, a communication interface, a display unit, and an input device. The processor, memory, and input / output interfaces are connected via a system bus, and the communication interface, display unit, and input device are also connected to the system bus via the input / output interfaces. The processor provides computing and control capabilities. The memory includes non-volatile storage media and internal memory. The non-volatile storage media stores the operating system and computer programs. The internal memory provides an environment for the operation of the operating system and computer programs stored in the non-volatile storage media. The input / output interfaces are used for exchanging information between the processor and external devices. The communication interface is used for wired or wireless communication with external terminals; wireless communication can be achieved through Wi-Fi, mobile cellular networks, Near Field Communication (NFC), or other technologies. When the computer program is executed by the processor, it implements a request processing method. The display unit is used to form a visually visible image and can be a display screen, a projection device, or a virtual reality imaging device. The display screen can be an LCD screen or an e-ink screen. The input device of the computer device can be a touch layer covering the display screen, or buttons, trackballs, or touchpads set on the casing of the computer device, or external keyboards, touchpads, or mice, etc.

[0146] Those skilled in the art will understand that Figure 6 or Figure 7 The structure shown is merely a block diagram of a portion of the structure related to the present application and does not constitute a limitation on the computer device to which the present application is applied. Specific computer devices may include more or fewer components than those shown in the figure, or combine certain components, or have different component arrangements.

[0147] In an exemplary embodiment, a computer device is provided, including a memory and a processor. The memory stores a computer program, and the processor executes the computer program to perform the following steps: when a client completes login and the client sends a resource request to a resource server, parsing an authentication request generated by the resource server for the resource request to obtain a session identifier corresponding to the client; if the session identifier meets the token construction conditions, constructing an OAuth2 token matching the session identifier; obtaining OAuth2 authorization information based on the OAuth2 token and the token parameters corresponding to the OAuth2 token; and sending the OAuth2 authorization information to the resource server so that the resource server returns a request result matching the resource request to the client based on the OAuth2 authorization information.

[0148] In one embodiment, when the processor executes the computer program, it further performs the following steps: obtaining the session creation time and session timeout duration that match the session identifier; determining the statistical duration of the session timeout duration and the preset duration; using the session creation time as the token issuance time and the time after the statistical duration starting from the current time as the token expiration time, to obtain an OAuth2 token that matches the session identifier.

[0149] In one embodiment, when the processor executes the computer program, it further performs the following steps: determining an authentication object that matches the session identifier and extracting a username from the authentication object; extracting an authorization scope set that matches the username from the authentication object's permission set; and combining the session identifier and the authorization scope set to obtain the token parameter corresponding to the OAuth2 token.

[0150] In one embodiment, when the processor executes the computer program, it further performs the following steps: binding the OAuth2 token to the token parameter corresponding to the OAuth2 token to obtain initial authorization information; initializing the initial authorization information to obtain OAuth2 authorization information.

[0151] In one embodiment, when the processor executes the computer program, it further performs the following steps: obtaining claim metadata based on the authorization code pattern and username matching the session identifier, as well as the token validity time and token identifier of the OAuth2 token; and binding the initial authorization information and the claim metadata to obtain OAuth2 authorization information.

[0152] In one embodiment, when the processor executes the computer program, it further performs the following steps: if a user session matching the session identifier is extracted from the session repository, extract a security context from the user session; and determine an authentication object matching the session identifier from the security context.

[0153] In one embodiment, when the processor executes the computer program, it further implements either of the following: First, if no matching OAuth2 token exists for the session identifier, it determines that the session identifier satisfies the token construction condition; Second, if a matching OAuth2 token exists for the session identifier, and the type of the matching OAuth2 token is consistent with a preset token type, it determines that the session identifier satisfies the token construction condition.

[0154] In one embodiment, a computer-readable storage medium is provided, on which a computer program is stored. When the computer program is executed by a processor, it performs the following steps: when a client completes login and the client sends a resource request to a resource server, the client parses an authentication request generated by the resource server for the resource request to obtain a session identifier corresponding to the client; if the session identifier satisfies the token construction conditions, the client constructs an OAuth2 token matching the session identifier; based on the OAuth2 token and the token parameters corresponding to the OAuth2 token, the client obtains OAuth2 authorization information; and the client sends the OAuth2 authorization information to the resource server so that the resource server returns a request result matching the resource request to the client based on the OAuth2 authorization information.

[0155] In one embodiment, when the computer program is executed by the processor, it further performs the following steps: obtaining the session creation time and session timeout duration that match the session identifier; determining the statistical duration of the session timeout duration and the preset duration; using the session creation time as the token issuance time and the time after the statistical duration starting from the current time as the token expiration time, to obtain an OAuth2 token that matches the session identifier.

[0156] In one embodiment, when the computer program is executed by the processor, it further performs the following steps: determining an authentication object that matches the session identifier and extracting a username from the authentication object; extracting an authorization scope set that matches the username from the authentication object's permission set; and combining the session identifier and the authorization scope set to obtain the token parameter corresponding to the OAuth2 token.

[0157] In one embodiment, when the computer program is executed by the processor, it further performs the following steps: binding the OAuth2 token to the token parameter corresponding to the OAuth2 token to obtain initial authorization information; initializing the initial authorization information to obtain OAuth2 authorization information.

[0158] In one embodiment, when the computer program is executed by the processor, it further performs the following steps: obtaining claim metadata based on the authorization code pattern and username matching the session identifier, as well as the token validity time and token identifier of the OAuth2 token; and binding the initial authorization information and the claim metadata to obtain OAuth2 authorization information.

[0159] In one embodiment, when the computer program is executed by the processor, it further performs the following steps: if a user session matching the session identifier is extracted from the session repository, extract a security context from the user session; and determine an authentication object matching the session identifier from the security context.

[0160] In one embodiment, when the computer program is executed by the processor, it further implements either of the following: first, if no matching OAuth2 token exists for the session identifier, it determines that the session identifier satisfies the token construction condition; second, if a matching OAuth2 token exists for the session identifier, and the type of the matching OAuth2 token is consistent with a preset token type, it determines that the session identifier satisfies the token construction condition.

[0161] In one embodiment, a computer program product is provided, including a computer program that, when executed by a processor, performs the following steps: when a client completes login and the client sends a resource request to a resource server, parsing an authentication request generated by the resource server for the resource request to obtain a session identifier corresponding to the client; if the session identifier satisfies token construction conditions, constructing an OAuth2 token matching the session identifier; obtaining OAuth2 authorization information based on the OAuth2 token and the token parameters corresponding to the OAuth2 token; and sending the OAuth2 authorization information to the resource server so that the resource server, based on the OAuth2 authorization information, returns a request result matching the resource request to the client.

[0162] In one embodiment, when the computer program is executed by the processor, it further performs the following steps: obtaining the session creation time and session timeout duration that match the session identifier; determining the statistical duration of the session timeout duration and the preset duration; using the session creation time as the token issuance time and the time after the statistical duration starting from the current time as the token expiration time, to obtain an OAuth2 token that matches the session identifier.

[0163] In one embodiment, when the computer program is executed by the processor, it further performs the following steps: determining an authentication object that matches the session identifier and extracting a username from the authentication object; extracting an authorization scope set that matches the username from the authentication object's permission set; and combining the session identifier and the authorization scope set to obtain the token parameter corresponding to the OAuth2 token.

[0164] In one embodiment, when the computer program is executed by the processor, it further performs the following steps: binding the OAuth2 token to the token parameter corresponding to the OAuth2 token to obtain initial authorization information; initializing the initial authorization information to obtain OAuth2 authorization information.

[0165] In one embodiment, when the computer program is executed by the processor, it further performs the following steps: obtaining claim metadata based on the authorization code pattern and username matching the session identifier, as well as the token validity time and token identifier of the OAuth2 token; and binding the initial authorization information and the claim metadata to obtain OAuth2 authorization information.

[0166] In one embodiment, when the computer program is executed by the processor, it further performs the following steps: if a user session matching the session identifier is extracted from the session repository, extract a security context from the user session; and determine an authentication object matching the session identifier from the security context.

[0167] In one embodiment, when the computer program is executed by the processor, it further implements either of the following: first, if no matching OAuth2 token exists for the session identifier, it determines that the session identifier satisfies the token construction condition; second, if a matching OAuth2 token exists for the session identifier, and the type of the matching OAuth2 token is consistent with a preset token type, it determines that the session identifier satisfies the token construction condition.

[0168] It should be noted that the user information (including but not limited to user device information, user personal information, etc.) and data (including but not limited to data used for analysis, data stored, data displayed, etc.) involved in this application are all information and data authorized by the user or fully authorized by all parties, and the collection, use and processing of the relevant data must comply with relevant regulations.

[0169] Those skilled in the art will understand that all or part of the processes in the methods of the above embodiments can be implemented by a computer program instructing related hardware. The computer program can be stored in a non-volatile computer-readable storage medium, and when executed, it can include the processes of the embodiments of the above methods. Any references to memory, databases, or other media used in the embodiments provided in this application can include at least one of non-volatile memory and volatile memory. Non-volatile memory can include read-only memory (ROM), magnetic tape, floppy disk, flash memory, optical memory, high-density embedded non-volatile memory, resistive random access memory (ReRAM), magnetic random access memory (MRAM), ferroelectric random access memory (FRAM), phase change memory (PCM), graphene memory, etc. Volatile memory can include random access memory (RAM) or external cache memory, etc. By way of illustration and not limitation, RAM can take many forms, such as Static Random Access Memory (SRAM) or Dynamic Random Access Memory (DRAM). The databases involved in the embodiments provided in this application may include at least one type of relational database and non-relational database. Non-relational databases may include, but are not limited to, blockchain-based distributed databases. The processors involved in the embodiments provided in this application may be general-purpose processors, central processing units, graphics processing units, digital signal processors, programmable logic devices, quantum computing-based data processing logic devices, artificial intelligence (AI) processors, etc., and are not limited to these.

[0170] The technical features of the above embodiments can be combined in any way. For the sake of brevity, not all possible combinations of the technical features in the above embodiments are described. However, as long as there is no contradiction in the combination of these technical features, they should be considered to be within the scope of this application.

[0171] The embodiments described above are merely illustrative of several implementation methods of this application, and while the descriptions are specific and detailed, they should not be construed as limiting the scope of this patent application. It should be noted that those skilled in the art can make various modifications and improvements without departing from the concept of this application, and these all fall within the protection scope of this application. Therefore, the protection scope of this application should be determined by the appended claims.

Claims

1. A request processing method, characterized in that, The method includes: When the client completes login and the client sends a resource request to the resource server, the authentication request generated by the resource server in response to the resource request is parsed to obtain the session identifier corresponding to the client. If the session identifier meets the token construction conditions, construct an OAuth2 token that matches the session identifier; Based on the OAuth2 token and the token parameters corresponding to the OAuth2 token, the OAuth2 authorization information is obtained; Send the OAuth2 authorization information to the resource server so that the resource server can return a request result matching the resource request to the client based on the OAuth2 authorization information; The step of constructing an OAuth2 token that matches the session identifier includes: Obtain the session creation time and session timeout duration that match the session identifier; The statistical duration of the session timeout and the preset duration is determined; Using the session creation time as the token issuance time and the time after the statistical duration starting from the current time as the token expiration time, an OAuth2 token matching the session identifier is obtained.

2. The method according to claim 1, characterized in that, The methods for obtaining the token parameters corresponding to the OAuth2 token include: Identify the authentication object that matches the session identifier, and extract the username from the authentication object; Extract the set of authorization scopes that match the username from the set of permissions of the authenticated object; The session identifier and the authorization scope set are combined to obtain the token parameters corresponding to the OAuth2 token.

3. The method according to claim 1, characterized in that, The process of obtaining OAuth2 authorization information based on the OAuth2 token and the token parameters corresponding to the OAuth2 token includes: Bind the OAuth2 token to the token parameter corresponding to the OAuth2 token to obtain the initial authorization information; The initial authorization information is initialized to obtain OAuth2 authorization information.

4. The method according to claim 3, characterized in that, The initialization of the initial authorization information to obtain OAuth2 authorization information includes: Based on the authorization code pattern and username that match the session identifier, as well as the token validity time and token identifier of the OAuth2 token, the claim metadata is obtained; By binding the initial authorization information and the claim metadata, OAuth2 authorization information is obtained.

5. The method according to claim 2, characterized in that, The process of determining the authentication object that matches the session identifier includes: If a user session matching the session identifier is retrieved from the session repository, the security context is extracted from the user session. From the security context, determine the authentication object that matches the session identifier.

6. The method according to any one of claims 1 to 5, characterized in that, The session identifier satisfies the token construction conditions, including any one of the following: First item: If no matching OAuth2 token exists for the session identifier, it is determined that the session identifier meets the token construction conditions; Second item: If a matching OAuth2 token exists for the session identifier, and the type of the matching OAuth2 token is consistent with the preset token type, then the session identifier is determined to meet the token construction conditions.

7. A request processing apparatus, characterized in that, The device includes: The parsing module is used to parse the authentication request generated by the resource server in response to the resource request after the client completes login and the client sends a resource request to the resource server, so as to obtain the session identifier corresponding to the client. The building module is used to build an OAuth2 token that matches the session identifier if the session identifier meets the token building conditions; The processing module is used to obtain OAuth2 authorization information based on the OAuth2 token and the token parameters corresponding to the OAuth2 token; The sending module is used to send the OAuth2 authorization information to the resource server, so that the resource server can send a request result matching the resource request back to the client based on the OAuth2 authorization information; The construction module is further configured to obtain the session creation time and session timeout duration that match the session identifier; determine the statistical duration of the session timeout duration and the preset duration; use the session creation time as the token issuance time, and the time after the statistical duration starting from the current time as the token expiration time, to obtain an OAuth2 token that matches the session identifier.

8. The apparatus according to claim 7, characterized in that, The processing module is further configured to determine the authentication object that matches the session identifier, and extract the username from the authentication object; extract the authorization scope set that matches the username from the authentication object permission set; and combine the session identifier and the authorization scope set to obtain the token parameter corresponding to the OAuth2 token.

9. A computer device comprising a memory and a processor, wherein the memory stores a computer program, characterized in that, When the processor executes the computer program, it implements the steps of the method according to any one of claims 1 to 6.

10. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by a processor, it implements the steps of the method according to any one of claims 1 to 6.

Images