Scientific research tool integration method and system based on open platform

Abstract

The invention belongs to the technical field of computer identity authentication, and particularly relates to a scientific research tool integration method and system based on an open platform. The method comprises the following steps: receiving a user access request sent by a third-party platform; presenting an open platform authorization page containing the client component to the user; through the client component, a third-party platform and an open platform are coordinated to complete application and return of a one-time temporary authorization code; after verifying the temporary authorization code, the open platform signs and issues an access token packaged with user identity permission; storing the access token in a user side storage space which shares a main domain with the scientific research tool; and the open platform analyzes the actual access address according to the tool identifier in the request and redirects the user, and the scientific research tool completes authentication by using the access token. According to the invention, the open platform is set as an authentication hub, and the tool provider can be reused by a plurality of users only through one-time development and access to the open platform, so that the management efficiency is remarkably improved.

Description

Technical Field

[0001] This invention belongs to the technical field of computer identity authentication, specifically relating to a method and system for integrating scientific research tools based on an open platform. Background Technology

[0002] Currently, when introducing third-party research tools (such as literature analysis, experiment management, and data visualization systems), research institutions generally adopt a point-to-point interface model. This means each research institution must individually negotiate interface protocols, authentication methods, and access control strategies with the tool provider, and conduct customized development. This approach has the following technical drawbacks:

[0003] 1. High development costs and poor reusability: If the same research tool needs to be connected to multiple research institutions, the tool provider must repeatedly develop adaptation code for each institution, making it difficult to achieve standardized delivery;

[0004] 2. Fragmented authentication system: Each research institution usually has its own independent account system, making it difficult for tool providers to manage user identities in a unified manner. They often rely on simple token transmission or hard-coded credentials, which poses security risks.

[0005] 3. Coarse-grained access control: It lacks a fine-grained dynamic authorization mechanism, making it impossible to precisely control tool access permissions by project, role, or data scope, and making it difficult to revoke permissions after the cooperation ends;

[0006] 4. Weak security auditing capabilities: Most existing solutions do not record complete user access links, making it difficult to trace abnormal operations; at the same time, there is a lack of automated de-identification processing for returned sensitive scientific research data;

[0007] 5. Poor user experience: After clicking on the tool entry on a third-party platform, users often need to be redirected to a separate login page to re-authenticate, making seamless embedded access impossible.

[0008] Although some systems have attempted to introduce OAuth2.0 or SAML to achieve single sign-on, they are usually designed for enterprise intranet environments and do not take into account the challenges of session transmission when research tools are embedded components in IFrame or micro-frontend architectures. In particular, in cross-domain scenarios, they cannot effectively synchronize the authentication status to the main domain where the tool page is located. Summary of the Invention

[0009] To address the aforementioned problems in existing technologies—namely, high integration costs, fragmented authentication systems, lax access control, weak security auditing capabilities, and poor user experience in the cross-institutional system integration of existing research tools, and the difficulty in achieving rapid, secure, and scalable reuse of research tools—this invention, in its first aspect, proposes a research tool integration method based on an open platform, comprising:

[0010] Receive user access requests from third-party platforms, wherein the user access requests include the tool identifier of the scientific research tool;

[0011] In response to the user access request, an authorization page provided by the open platform is presented to the user, the authorization page including the client component of the open platform;

[0012] The client component triggers the third-party platform to send a request to the open platform to obtain a temporary authorization code. After verifying the identity of the third-party platform, the open platform generates a temporary authorization code and returns it to the third-party platform.

[0013] The client component obtains the temporary authorization code from the third-party platform and sends it back to the open platform. The open platform verifies the temporary authorization code and, upon successful verification, issues an access token encapsulating the user's identity and preset permission information.

[0014] The access token is stored in the user's storage space, which is associated with the tool center main domain shared by all research tools;

[0015] The open platform parses the actual access address of the research tool based on the tool identifier and redirects the user to the actual access address. The research tool is authenticated based on the access token in the user's terminal storage space.

[0016] In some preferred embodiments, the verification of the temporary authorization code includes:

[0017] Verify the issuance timestamp of the temporary authorization code to ensure that it has not exceeded the preset lifespan;

[0018] Verify the binding relationship between the temporary authorization code and the client ID of the third-party platform that initiated the request and the user session;

[0019] Or cancel the temporary authorization code to prevent at least one of the following replay attacks.

[0020] In some preferred embodiments, the client component is a client script, which transmits instructions and data between the authorization page and the front end of the third-party platform through the cross-origin communication mechanism on the browser side.

[0021] In some preferred embodiments, the access token is a data structure that conforms to a predetermined token standard. The data structure includes a unique user identifier, a list of authorized tools, a scope of permissions, an issuer field for identifying the open platform, a recipient field for identifying the target research tool or tool cluster, an expiration time field for defining the validity period of the access token, and a token ID field that uniquely identifies the access token.

[0022] In some preferred embodiments, the research tool verifies user permissions, including:

[0023] The access token is extracted from the HTTP request, and the signature of the access token is verified locally using a pre-shared verification key obtained from the open platform. The payload of the access token is then parsed to obtain user permissions.

[0024] In some preferred embodiments, the storage space on the user end is a cookie, and the cookie is configured to prohibit client scripts from accessing the cookie, restrict the cookie to be transmitted only through an encryption protocol, and restrict the cookie from being sent with cross-site requests.

[0025] In some preferred embodiments, the method further includes:

[0026] When a user initiates a logout request, the logout request is uniformly directed to the central logout interface of the open platform, which is used to clear the authentication credentials in the user's terminal storage space.

[0027] The client component notifies all integrated third-party platforms to synchronously clear their respective user session states.

[0028] In some preferred embodiments, the method further includes:

[0029] A data processing gateway is set up in the open platform as a unified data outlet. The data processing gateway performs real-time dynamic desensitization processing on sensitive fields in the response data according to the role and permissions of the requesting user and the predefined desensitization policy rules.

[0030] In a second aspect, this invention proposes a research tool integration system based on an open platform, comprising:

[0031] The request receiving and routing module is used to receive user access requests and route them to the authorization page that hosts the client components;

[0032] The client component is used to interact with a third-party platform through a cross-source communication mechanism to coordinate the application and return process of temporary authorization codes;

[0033] The authentication and authorization service is used to issue and verify one-time temporary authorization codes, and issue access tokens based on the user's permission policy after successful verification.

[0034] The token storage control module is used to store the issued access tokens in the client storage space associated with the tool center main domain;

[0035] The address resolution module is used to provide dynamic routing pointers for scientific research tools to the request receiving and routing module.

[0036] In some preferred embodiments, the system further includes:

[0037] The permission policy management center is used to dynamically configure access control permission policies between users, user groups, and research tools. The authentication and authorization service generates permission information based on the permission policy when issuing tokens.

[0038] The beneficial effects of this invention are:

[0039] Compared with the prior art, the present invention has the following significant advantages:

[0040] Based on the method proposed in this invention, an open platform is used as the authentication hub and client components are used as the technical bridge. Existing third-party systems or research tools can be smoothly integrated into a unified authentication system without large-scale modifications, which significantly improves user experience and work efficiency. Users no longer need to remember and manage multiple account passwords, nor do they need to repeatedly log in when switching between different systems, which significantly improves the management efficiency and work efficiency of research tools.

[0041] Meanwhile, this invention employs a mechanism of exchanging temporary authorization codes for access tokens, avoiding the direct transmission of user passwords between multiple systems and effectively reducing the risk of account leakage and data misuse. Administrators can uniformly configure, monitor, and audit the permissions of all users and tools, significantly reducing the complexity of permission management in a distributed system environment and improving management efficiency and system controllability. Attached Figure Description

[0042] Other features, objects, and advantages of this application will become more apparent from the following detailed description of non-limiting embodiments with reference to the accompanying drawings:

[0043] Figure 1 This is a flowchart illustrating a method for integrating scientific research tools based on an open platform, as provided in an embodiment of the present invention.

[0044] Figure 2 This is a schematic diagram of the architecture of an open platform system provided in an embodiment of the present invention;

[0045] Figure 3 This is a schematic diagram of the computer system structure of the server implementing the methods and system embodiments of this application. Detailed Implementation

[0046] The present application will now be described in further detail with reference to the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are for illustrative purposes only and are not intended to limit the invention. Furthermore, it should be noted that, for ease of description, only the parts relevant to the invention are shown in the accompanying drawings.

[0047] It should be noted that, unless otherwise specified, the embodiments and features described in this application can be combined with each other. This application will now be described in detail with reference to the accompanying drawings and embodiments.

[0048] To more clearly explain the open platform-based research tool integration method of the present invention, the following will be combined with... Figure 1 The steps in the embodiments of the present invention will be described in detail below.

[0049] The first embodiment of the present invention provides a method for integrating scientific research tools based on an open platform, including steps S10-S60, each step of which is described in detail below:

[0050] Step S10: Receive a user access request from a third-party platform, wherein the user access request includes the tool identifier of the scientific research tool;

[0051] Step S20: In response to the user access request, present the user with an authorization page provided by the open platform, the authorization page including the client component of the open platform;

[0052] Step S30: Through the client component, the third-party platform is triggered to send a request to the open platform to obtain a temporary authorization code. After verifying the identity of the third-party platform, the open platform generates a temporary authorization code and returns it to the third-party platform.

[0053] Step S40: The client component obtains the temporary authorization code from the third-party platform and sends it back to the open platform. The open platform verifies the temporary authorization code and, after successful verification, issues an access token encapsulating the user's identity and preset permission information.

[0054] Step S50: Store the access token in the user's storage space, which is associated with the tool center main domain shared by all research tools;

[0055] In step S60, the open platform parses the actual access address of the research tool based on the tool identifier and redirects the user to the actual access address. The research tool is authenticated based on the access token in the user's terminal storage space.

[0056] This embodiment aims to solve the problem of users needing to authenticate repeatedly when accessing research tools across different systems, and to achieve single sign-on.

[0057] Please refer to Figure 2 First, the open platform system involved in this embodiment will be described. Figure 2 The core components of the open platform system and their interactions are illustrated, including: third-party platforms (Web / PC / mobile), Spring Cloud gateway cluster, authentication service, permission management module, tool management center, SDK module (including authorization relay SDK, communication SDK, single sign-on SDK), Nacos registration and configuration center, research tool cluster (research tool 1, research tool 2, etc.), log center (ELK), distributed message middleware (RabbitMQ), distributed cache (Redis), distributed database and Hadoop data warehouse, etc.

[0058] Based on the aforementioned open platform system, specifically, users first operate on a third-party platform integrated with the open platform (e.g., an internal research management portal of a university, an experimental data platform of a research institute, etc.). When a user clicks a link or button pointing to a specific research tool, the front end of the third-party platform initiates a user access request. The target address of this request is uniformly standardized as the entry address of the open platform and carries a tool identifier (tool_id) that can uniquely identify the target research tool. For example, the URL of this request could be "https: / / <Tool Center Main Domain> / app / <Tool Identifier>". This request is then sent to the open platform of this invention.

[0059] Next, upon receiving the user's access request, the open platform's server checks whether the request contains valid authentication credentials (such as an access token). In a typical first-time access scenario, since the user has not yet been authenticated by the open platform, the request does not contain valid credentials. In this case, the open platform responds to the request by redirecting the user's browser to a specific authorization page provided by the open platform. This authorization page is designed as an authorization intermediary, embedding client-side components provided by the open platform within its page.

[0060] Taking an access token as an example, when using an access token as an authentication credential, the access token is a data structure that conforms to a predetermined token standard. The data structure includes a unique user identifier, a list of authorized tools, a scope of permissions, an issuer field for identifying the open platform, a recipient field for identifying the target research tool or tool cluster, an expiration time field for defining the validity period of the access token, and a token ID field that uniquely identifies the access token.

[0061] In this embodiment, the client component can be specifically implemented as a client-side script (e.g., in JavaScript form), i.e., an SDK (Software Development Kit). After the script is loaded into the user's browser, it uses the browser's cross-origin communication mechanism (e.g., by executing the postMessage API) to securely transmit instructions and data with the parent window, i.e., the front-end page of the third-party platform.

[0062] After the client component executes, it detects that the current access originates from a registered third-party platform. It then sends an instruction to the front end of the third-party platform through a cross-origin communication mechanism, triggering the third-party platform to initiate a request to the open platform's authentication service to obtain a one-time temporary authorization code. This request serves as a secure backend-to-backend communication that follows industry standard protocols (such as the authorization code mode of OAuth 2.0).

[0063] The third-party platform uses its client ID (client_id) and client secret (client_secret) obtained during registration with the open platform to initiate a request to the open platform's authentication service. After verifying the legitimacy of the third-party platform's identity, the open platform generates a temporary authorization code with a short lifespan that is bound to the current user session and client ID, and returns it to the third-party platform's backend.

[0064] Subsequently, the third-party platform, through its frontend and via the aforementioned client component as a secure channel, sends the obtained temporary authorization code back to the open platform's frontend, namely the aforementioned authorization page. Upon receiving the temporary authorization code, the client script on the authorization page immediately submits it to the open platform's backend for verification.

[0065] The backend of the open platform verifies the received temporary authorization code. This verification process may include, but is not limited to, at least one of the following, to ensure the security of the process:

[0066] Verify the issuance timestamp of the temporary authorization code to ensure that it does not exceed the preset, usually short lifespan of a few seconds or tens of seconds, to prevent it from being intercepted and remaining valid for a long time.

[0067] Verify the binding relationship between the temporary authorization code and the client ID of the third-party platform that initiated the request, as well as the current user session, to ensure that the authorization code was applied for by a legitimate third party for the current user and to prevent the authorization code from being stolen;

[0068] Once the verification is successful, the temporary authorization code is immediately deactivated from the cache or database, thus effectively preventing replay attacks.

[0069] After successful verification, the open platform's authentication service officially issues an access token. This access token encapsulates the user's identity information and the preset permission information for this access. The access token is then extracted from the HTTP request, and the signature of the access token is verified locally using a pre-shared verification key obtained from the open platform. Its payload is then parsed to obtain the user's permissions.

[0070] In this embodiment, the access token preferably adopts a data structure that conforms to a predetermined token standard, such as JSON Web Token (JWT). The payload of this JWT can contain rich claim information, such as: the user's unique identifier (e.g., openid), the list of tools that the user is authorized to access, the specific permission scope (e.g., read-only, read-write, etc.), the issuer field (iss) used to clearly identify the issuing authority (i.e., this open platform), the receiver field (aud) used to specify the target recipient of the token (i.e., a specific research tool or tool cluster), an expiration time field (exp) used to define the validity period of the access token, and a token ID field (jti) as the token's own unique ID, to enhance its traceability and security.

[0071] After obtaining the access token, the open platform's backend execution stores it in the user's storage space. To enable single sign-on across different research tools, this storage space must be associated with the tool center main domain shared by all research tools.

[0072] In this embodiment, an efficient implementation is to set the user's storage space as a browser cookie. The open platform sets the Set-Cookie directive in the HTTP response header, writing the access token into a cookie associated with the tool center's main domain (e.g., .openx.cnki.net).

[0073] In addition, to enhance security, multiple security attributes can be configured for this cookie, such as: configuring the HttpOnly flag to prohibit direct access by client-side scripts to effectively prevent cross-site scripting (XSS) attacks; configuring the Secure flag to restrict the cookie to be transmitted only via encrypted HTTPS protocol; and configuring the SameSite flag (such as Lax or Strict) to restrict the policy of sending this cookie with cross-site requests to resist cross-site request forgery (CSRF) attacks.

[0074] Ultimately, based on the tool identifier included in the initial request, the open platform queries its internal routing configuration information to resolve the actual network access address of the target research tool. Subsequently, the open platform sends a redirection instruction (such as an HTTP 302 response) to the user's browser, redirecting the user to this actual access address. Since this address also belongs to the tool's main domain or its subdomains, the browser automatically includes the cookie containing the access token stored in the previous step when initiating access to the tool's page. The target research tool's backend service extracts the access token from the HTTP request (such as the Cookie field in the header) and verifies the digital signature of the access token locally using a pre-shared verification key (such as a public key for asymmetric encryption) obtained from the open platform. After successful signature verification, the payload content is securely parsed to obtain the user's identity and authorization information, completing automatic authentication and authorization. Throughout this process, the user does not need to enter any credentials again, achieving seamless passwordless access.

[0075] Furthermore, the method in this embodiment of the invention further includes:

[0076] When a user initiates a logout request within any integrated third-party platform or research tool, the request will be uniformly redirected to the central logout interface of the open platform.

[0077] The core task of this central logout interface is to clear authentication credentials, that is, to delete or invalidate access tokens in the user's storage space (such as the main domain cookie). Simultaneously, to achieve a complete global logout, the open platform can also broadcast logout notifications to all third-party platforms associated with the current user session through the aforementioned client components, triggering them to synchronously clear their respective user session states (such as information in local storage), thereby ensuring that the user is logged out in all associated systems.

[0078] In addition, to ensure the security of scientific research data, the method in this embodiment also includes:

[0079] A data processing gateway is set up within the open platform, serving as the unified exit point for all research tools to provide data. When research tools need to return data containing sensitive fields to users (e.g., personal identification information, classified project numbers, unpublished experimental data, etc.), all data flows must pass through this gateway. This gateway can dynamically de-identify sensitive fields in the response data based on the requesting user's role and permissions, as well as predefined de-identification policy rules. For example, it can use asterisks (*) to mask parts of the content, perform data generalization, or directly replace them with meaningless characters before returning the processed data to the user. This ensures the security of core data without affecting normal use.

[0080] Furthermore, the second embodiment of the present invention also proposes a research tool integration system based on an open platform, comprising:

[0081] The request receiving and routing module is used to receive user access requests and route them to the authorization page that hosts the client components;

[0082] The client component is used to interact with a third-party platform through a cross-source communication mechanism to coordinate the application and return process of temporary authorization codes;

[0083] The authentication and authorization service is used to issue and verify one-time temporary authorization codes, and issue access tokens based on the user's permission policy after successful verification.

[0084] The token storage control module is used to store the issued access tokens in the client storage space associated with the tool center main domain;

[0085] The address resolution module is used to provide dynamic routing pointers for scientific research tools to the request receiving and routing module.

[0086] It should be noted that the research tool integration method and system based on the open platform provided in the above embodiments are only illustrative examples of the above functional module division. In practical applications, the above functions can be assigned to different functional modules as needed, that is, the modules or steps in the embodiments of the present invention can be further decomposed or combined. For example, the modules in the above embodiments can be merged into one module, or further divided into multiple sub-modules to complete all or part of the functions described above. The names of the modules and steps involved in the embodiments of the present invention are only for distinguishing the various modules or steps and are not considered as an improper limitation of the present invention.

[0087] A computer-readable storage medium according to a third embodiment of the present invention stores computer instructions, which are executed by the computer to implement the above-described method for integrating scientific research tools based on an open platform.

[0088] Those skilled in the art will understand that, for the sake of convenience and brevity, the specific working process and related descriptions of the storage device and processing device described above can be referred to the corresponding processes in the foregoing method embodiments, and will not be repeated here.

[0089] The following is for reference. Figure 3 It shows a schematic diagram of the structure of a computer system used to implement the methods and system embodiments of this application. Figure 3 The server shown is merely an example and should not impose any limitations on the functionality and scope of use of the embodiments of this application.

[0090] like Figure 3As shown, the computer system includes a Central Processing Unit (CPU) 301, which can perform various appropriate actions and processes based on programs stored in Read Only Memory (ROM) 302 or programs loaded from storage section 308 into Random Access Memory (RAM) 303. The RAM 303 also stores various programs and data required for system operation. The CPU 301, ROM 302, and RAM 303 are interconnected via a bus 304. An Input / Output (I / O) interface 305 is also connected to the bus 304.

[0091] The following components are connected to I / O interface 305: an input section 306 including a keyboard, mouse, etc.; an output section 307 including a cathode ray tube (CRT), liquid crystal display (LCD), and speakers, etc.; a storage section 308 including a hard disk, etc.; and a communication section 309 including a network interface card such as a LAN (Local Area Network) card and a modem, etc. The communication section 309 performs communication processing via a network such as the Internet. A drive 310 is also connected to I / O interface 305 as needed. Removable media 311, such as a disk, optical disk, magneto-optical disk, semiconductor memory, etc., are installed on drive 310 as needed so that computer programs read from them can be installed into storage section 308 as needed.

[0092] Specifically, according to embodiments of this disclosure, the processes described above with reference to the flowcharts can be implemented as computer software programs. For example, embodiments of this disclosure include a computer program product comprising a computer program carried on a computer-readable medium, the computer program containing program code for performing the methods shown in the flowcharts. In such embodiments, the computer program can be downloaded and installed from a network via communication section 309, and / or installed from removable medium 311. When the computer program is executed by central processing unit (CPU) 301, it performs the functions defined in the methods of this application. It should be noted that the computer-readable medium described above in this application can be a computer-readable signal medium or a computer-readable storage medium, or any combination of the two. A computer-readable storage medium can be, for example,—but not limited to—an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any combination thereof. More specific examples of computer-readable storage media may include, but are not limited to: electrical connections having one or more wires, portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber, portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination thereof. In this application, a computer-readable storage medium can be any tangible medium containing or storing a program that can be used by or in connection with an instruction execution system, apparatus, or device. In this application, a computer-readable signal medium may include a data signal propagated in baseband or as part of a carrier wave, carrying computer-readable program code. Such propagated data signals can take various forms, including but not limited to electromagnetic signals, optical signals, or any suitable combination thereof. A computer-readable signal medium can also be any computer-readable medium other than a computer-readable storage medium, which can send, propagate, or transmit a program for use by or in connection with an instruction execution system, apparatus, or device. The program code contained on a computer-readable medium can be transmitted using any suitable medium, including but not limited to: wireless, wire, optical fiber, RF, etc., or any suitable combination thereof.

[0093] Computer program code for performing the operations of this application can be written in one or more programming languages ​​or a combination thereof, including object-oriented programming languages ​​such as Java, Smalltalk, and C++, and conventional procedural programming languages ​​such as the "C" language or similar programming languages. The program code can be executed entirely on the user's computer, partially on the user's computer, as a standalone software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In cases involving remote computers, the remote computer can be connected to the user's computer via any type of network—including a local area network (LAN) or a wide area network (WAN)—or can be connected to an external computer (e.g., via the Internet using an Internet service provider).

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

[0095] The terms “first”, “second”, etc., are used to distinguish similar objects, not to describe or indicate a specific order or sequence.

[0096] The term "comprising" or any other similar term is intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus / device that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent in such process, method, article, or apparatus / device.

[0097] The technical solution of the present invention has been described above with reference to the preferred embodiments shown in the accompanying drawings. However, it will be readily understood by those skilled in the art that the scope of protection of the present invention is obviously not limited to these specific embodiments. Without departing from the principles of the present invention, those skilled in the art can make equivalent changes or substitutions to the relevant technical features, and the technical solutions after these changes or substitutions will all fall within the scope of protection of the present invention.

Claims

1. A method for integrating scientific research tools based on an open platform, characterized in that, Includes the following steps: Receive user access requests from third-party platforms, wherein the user access requests include the tool identifier of the scientific research tool; In response to the user access request, an authorization page provided by the open platform is presented to the user, the authorization page including the client component of the open platform; The client component triggers the third-party platform to send a request to the open platform to obtain a temporary authorization code. After verifying the identity of the third-party platform, the open platform generates a temporary authorization code and returns it to the third-party platform. The client component obtains the temporary authorization code from the third-party platform and sends it back to the open platform. The open platform verifies the temporary authorization code and, upon successful verification, issues an access token encapsulating the user's identity and preset permission information. The access token is stored in the user's storage space, which is associated with the tool center main domain shared by all research tools; The open platform parses the actual access address of the research tool based on the tool identifier and redirects the user to the actual access address. The research tool is authenticated based on the access token in the user's terminal storage space.

2. The method according to claim 1, characterized in that, The verification of the temporary authorization code includes: Verify the issuance timestamp of the temporary authorization code to ensure that it has not exceeded the preset lifespan; Verify the binding relationship between the temporary authorization code and the client ID of the third-party platform that initiated the request and the user session; The temporary authorization code is revoked to prevent at least one of the replay attacks.

3. The method according to claim 1, characterized in that, The client component is a client-side script, which transmits instructions and data between the authorization page and the front end of the third-party platform through the cross-origin communication mechanism on the browser side.

4. The method according to claim 1, characterized in that, The access token is a data structure that conforms to a predetermined token standard. The data structure includes a unique user identifier, a list of authorized tools, a scope of permissions, an issuer field for identifying the open platform, a recipient field for identifying the target research tool or tool cluster, an expiration time field for defining the validity period of the access token, and a token ID field that uniquely identifies the access token.

5. The method according to claim 1, characterized in that, The research tool verifies user permissions, including: The access token is extracted from the HTTP request, and the signature of the access token is verified locally using a pre-shared verification key obtained from the open platform. The payload of the access token is then parsed to obtain user permissions.

6. The method according to claim 1, characterized in that, The storage space on the user's end is a cookie. The cookie is configured to prohibit client scripts from accessing the cookie, restrict the cookie to be transmitted only through an encrypted protocol, and restrict the cookie from being sent with cross-site requests.

7. The method according to claim 1, characterized in that, The method further includes: When a user initiates a logout request, the logout request is uniformly directed to the central logout interface of the open platform, which is used to clear the authentication credentials in the user's terminal storage space. The client component notifies all integrated third-party platforms to synchronously clear their respective user session states.

8. The method according to claim 1, characterized in that, The method further includes: A data processing gateway is set up in the open platform as a unified data outlet. The data processing gateway performs real-time dynamic desensitization processing on sensitive fields in the response data according to the role and permissions of the requesting user and the predefined desensitization policy rules.

9. A research tool integration system based on an open platform, characterized in that, include: The request receiving and routing module is used to receive user access requests and route them to the authorization page that hosts the client components; The client component is used to interact with a third-party platform through a cross-source communication mechanism to coordinate the application and return process of temporary authorization codes; The authentication and authorization service is used to issue and verify one-time temporary authorization codes, and issue access tokens based on the user's permission policy after successful verification. The token storage control module is used to store the issued access tokens in the client storage space associated with the tool center main domain; The address resolution module is used to provide dynamic routing pointers for scientific research tools to the request receiving and routing module.

10. The system according to claim 9, characterized in that, The system also includes: The permission policy management center is used to dynamically configure access control permission policies between users, user groups, and research tools. The authentication and authorization service generates permission information based on the permission policy when issuing tokens.

Images