Double-layer routing identity authentication device and identity authentication method for application integration platform

Abstract

The invention discloses a double-layer routing identity authentication device and method for an application integration platform, relates to the field of system identity authentication, and solves the problem of identity authentication compatibility caused by client capability difference by performing double-layer routing and context adaptation on an application request through a gateway module. When the application request is a login request, the gateway module realizes rapid shunting based on a white list mechanism, the application request is authenticated by the verification module if the matching is passed, and the application request is automatically verified by the gateway module if the matching is not passed, so that the authentication flexibility is improved; for a service processing request, the gateway module verifies the source and identity of the request based on request header information in the request after adaptation processing, and ensures correct routing and secure access of the request. According to the mechanism, path completion and identity verification are completed in a gateway module in a unified manner, so that the dependence on a client is reduced, the user experience of one-time login and seamless jump in a multi-application environment is realized, and the compatibility, security and maintainability of an application integration platform are enhanced.

Description

Technical Field

[0001] The present invention relates to the field of system identity authentication, and in particular to a double-layer routing identity authentication device and an identity authentication method for an application integration platform. Background Art

[0002] In existing technologies, when integrating applications with traffic gateways for authentication, they typically rely on clients to intercept, proxy, and deeply assemble requests to inject identity information and maintain routing context. This process places high demands on the client's technical support capabilities, particularly relying on front-end capabilities like Service Workers to uniformly intercept requests and perform prefix completion on URL paths based on the current request context (e.g., completing / api / user to / app1 / api / user), ensuring that requests are correctly routed by the gateway to the corresponding application's backend services.

[0003] However, due to differences in technical architecture, operating environment, and standard support among different clients (such as browsers, Android apps, iOS apps, and HarmonyOS apps), especially the varying levels of support for Service Workers (for example, some mobile WebViews do not support or are disabled by default), request interception and path prefix auto-completion cannot be reliably implemented in these environments. As a result, requests are sent directly to the gateway with incomplete paths (such as / api / user). The gateway cannot correctly parse the identity context because it cannot recognize the sub-application to which it belongs, which leads to identity token verification failure or routing errors, ultimately causing the authentication process to be interrupted or jump abnormally. This problem severely limits the compatibility and security of the application integration platform in a multi-terminal environment. Summary of the Invention

[0004] To reduce the reliance of identity authentication on front-end interception capabilities such as client-side Service Workers and achieve cross-terminal compatibility, the present invention proposes a two-tier routing identity authentication device for an application integration platform. The application integration platform includes: a client including a main application and multiple sub-applications, a back-end platform corresponding to the client, and back-end services corresponding to each application; each sub-application runs in the operating environment provided by the main application; the two-tier routing identity authentication device includes: a gateway module and a verification module provided on the back-end platform; wherein: The client is used to load the currently triggered application and execute the initialization script corresponding to the application. It determines whether the currently accessed URL is the main application based on the judgment result, loads and sets the corresponding application data based on the judgment result, and initiates an application request after the loading and setting are completed; the application request is a client login request or a business processing request; The gateway module is used to intercept application requests and perform request context adaptation processing based on the context information of the request; when the application request is a login request, a whitelist match is performed. If the match is successful, the request is forwarded to the verification module of the backend platform. If the match fails, a gateway verification is performed, and the response content is determined based on the verification result, and the corresponding response is returned to the client; The verification module is used to perform identity authentication on the client login request, generate an identity token after the authentication is passed, and return the token to the client; the business processing request includes the identity token returned by the verification module; The gateway module is also used to verify the source and identity of the request when the application request is a business processing request. If the verification is successful, the request is sent to the back-end service of the corresponding application; if the verification fails, the response content is set based on the cookie of the request and the response content is returned to the client; The backend service of each application is used to execute the business logic of the business processing request sent by the gateway module and return the execution data to the client.

[0005] Furthermore, the corresponding application data is loaded and set according to the judgment result; specifically: When the currently triggered application is the main application, the application prefix identifier of the cookie is set to empty; when the currently triggered application is the sub-application, the JavaScript engine is loaded, the currently accessed URL path is parsed, and the application prefix identifier of the cookie is set based on the parsing result; Load the application data corresponding to the current application; the application data includes: JavaScript files and CSS style files.

[0006] Furthermore, the application request is initiated after the loading and setting are completed, specifically: Generate an application request and obtain the support status of the Service Worker. If the status is supported, the current application request is processed by the Service Worker, the SW application support flag of the cookie is set to enabled, and when the URL path of the current request corresponds to a sub-application, the prefix of the URL path is completed by the application prefix flag of the cookie, and the application request is issued.

[0007] Furthermore, the gateway module specifically includes a primary routing unit and a secondary routing unit; The first-level routing unit is used to intercept application requests and perform request context adaptation processing based on the context information of the request; it is also used to determine whether the current application request is a client login request. If so, it detects whether the current URL path of the request is in the whitelist. If it is in the whitelist, it means that the match is passed and the request is forwarded to the verification module; if not, the request is sent to the second-level routing unit; The secondary routing unit is used to perform gateway verification on the client login request sent by the primary routing unit, determine the response content based on the verification result, and return the corresponding response to the client; The verification module is used to authenticate the client login request, generate an identity token after the authentication is successful, and return the token to the client; specifically: The username and password in the client login request are verified based on the user data table in the database. If the verification is successful, an identity token is generated and returned to the client through the first-level routing unit; the identity token includes the user ID, token expiration time and role code.

[0008] Furthermore, the request context adaptation processing is performed based on the context information of the request, specifically: judging whether the source of the current request is the main application through the current URL path; if not, and its URL path does not contain the application prefix identifier, the path is prefix-completed based on the application prefix identifier in the cookie.

[0009] Furthermore, the secondary routing unit is used to perform gateway verification on the client login request sent by the primary routing unit, determine the response content based on the verification result, and return the corresponding response to the client; specifically: Verify the legitimacy of the source of the request based on the request header information in the client login request, and determine whether it carries an identity token; the request header information includes cookies; If the source is legitimate and the identity token carried has not expired, the user is determined to be logged in and a redirect response is returned to the main application homepage. Otherwise, a redirect response is returned to the login interface.

[0010] Furthermore, the first-level routing unit is further configured to forward the adapted request to the second-level routing unit when the application request is a service processing request; The secondary routing unit is also used to verify the legitimacy of the source of the request based on the request header information in the business processing request, and determine whether it carries an identity token; if the source is legitimate and the identity token carried has not expired, it is determined that the user is in a logged-in state and the request is sent to the back-end service of the corresponding application; otherwise, the response content is set based on the cookie of the request and returned to the client.

[0011] Furthermore, the response content is set based on the cookie of the request and returned to the client, specifically: The cookie-based SW application support identifier determines whether the client has enabled Service Worker. If so, the HTTP status code is set to 302, and the redirect URL path is set in the response header to point to the login page of the main application, and the response is returned to the client; if not, the HTTP status code is set to 401, and an error message is set in the response header, and the response is returned to the client; the error message indicates that the identity token has expired.

[0012] The embodiment of the present invention further provides an identity authentication method, which is applied to the above-mentioned double-layer routing identity authentication device; the method comprises the steps of: S1: Load the currently triggered application through the client and execute the initialization script corresponding to the application; S2: Determine whether the currently accessed URL is the main application based on the path, load and set the corresponding application data based on the judgment result, and initiate the current application request after loading and setting are completed; S3: intercept the application request through the first-level routing unit and perform request context adaptation processing based on the context information of the request; determine whether the current application request is a client login request, if so, proceed to the next step; if not, jump to step S7; S4: The first-level routing unit detects whether the current URL path of the request is in the whitelist. If it is, it means the match is passed, and the request is forwarded to the verification module and proceeds to the next step; if it is not in the whitelist, the request is sent to the second-level routing unit; S5: The authentication module authenticates the client login request, generates an identity token after the authentication is successful, and returns the token to the client; S6: Generate a business request through the client, add the identity token returned by the verification module to the request header of the business request to obtain a business processing request, and return to step S2; S7: forwarding the adapted request to the secondary routing unit through the primary routing unit; S8: The secondary routing unit verifies the legitimacy of the source of the request based on the request header information in the business processing request, and determines whether it carries an identity token; if the source is legitimate and the identity token carried has not expired, it is determined that the user is in a logged-in state and the request is sent to the back-end service of the corresponding application; otherwise, the response content is set based on the cookie of the request and returned to the client.

[0013] Furthermore, the method also includes: when the current URL path of the login request is not in the whitelist, the secondary routing unit verifies the legitimacy of the source of the request based on the request header information in the client login request, and determines whether it carries an identity token; if the source is legitimate and the identity token carried has not expired, it is determined that the user is in a logged-in state, and a redirect response is returned to the main application homepage; otherwise, a redirect response is returned to the login interface.

[0014] Compared with the prior art, the present invention has at least the following beneficial effects:

[0015] (1) The present invention solves the authentication compatibility problem caused by differences in client capabilities by performing two-layer routing and context adaptation on application requests through the gateway module. When the application request is a login request, the gateway module implements rapid diversion based on the whitelist mechanism. If the match is passed, it will be authenticated by the verification module. If it fails, the gateway module will verify it by itself, thereby improving the flexibility of authentication. For business processing requests, the gateway module verifies the source and identity of the request based on the request header information in the request after adaptation processing, ensuring correct routing and secure access to the request. This mechanism unifies path completion and identity verification in the gateway module, reducing dependence on the client (such as Service Worker), achieving a user experience of one-time login and seamless jump in a multi-application environment, and enhancing the compatibility, security and maintainability of the application integration platform.

[0016] (2) The present invention effectively solves the problem of missing request paths caused by the client not supporting Service Worker by parsing the URL path and setting the application prefix identifier during the client initialization phase, combining the Service Worker front-end completion and the gateway-side path completion mechanism. When a request is sent, if the client supports ServiceWorker, it intercepts the request and completes the sub-application path prefix based on the cookie; if it does not support it, the first-level routing unit automatically completes the URL path based on the application prefix identifier in the cookie, ensuring that the request can be correctly routed to the back-end service of the corresponding application, avoiding 404 or authentication failure caused by incomplete path, achieving dual protection of front-end optimization and back-end fault tolerance, and significantly improving the robustness and availability of the device.

[0017] (3) This invention addresses the issue of different ServiceWorker support among different clients (such as browsers, Android, iOS, and Hongmeng applications). By introducing the SW application support identifier, the gateway can identify the client's capability status and return differentiated response strategies accordingly. For clients that support Service Worker, the gateway returns a 302 redirect, and the front-end automatically jumps to the login page; for clients that do not support it, a 401 status code and an error message are returned, and the native container or JS bridge guides the login. This mechanism avoids the problem of unified redirection being unable to handle on the mobile side, truly realizes compatible support for multi-terminal environments, and improves the adaptability of the application integration platform in a complex ecosystem.

[0018] (4) The present invention constructs a two-tier authentication architecture in which the first-level routing unit and the second-level routing unit work together, significantly improving the security and maintainability of the device. The first-level routing unit is responsible for request interception, path completion, and whitelist matching of login requests to achieve preliminary diversion; the second-level routing unit performs in-depth verification of all business requests, verifies the legitimacy of the request source and the validity of the identity token, and ensures that only legitimate requests can reach the back-end service. This layered mechanism implements the design concept of "diversion before, security after", which not only reduces the burden on the core verification module, but also prevents the risk of illegal requests bypassing the front end, forming a complete security protection closed loop and enhancing the overall security of the platform.

[0019] (5) This invention decouples the core authentication logic from the client and transfers it to the backend gateway for unified processing, significantly reducing the reliance on deep client customization and interception capabilities. The client only needs to execute a lightweight initialization script and set the necessary cookie identifiers, without the need to implement complex request interception and assembly logic. When adding a new sub-application, it is only necessary to configure routing rules in the gateway without modifying the client code on each end, which greatly simplifies the cost of multi-end collaborative development and maintenance. This design improves the scalability and maintainability of the platform, facilitates the rapid integration of new applications, and supports the continuous evolution of large-scale micro-frontend architectures.

[0020] (6) The present invention enables users to seamlessly switch between the main application and sub-applications, significantly improving the user experience. By automatically setting the application prefix identifier and combining it with the path completion capability of the Service Worker or gateway, users do not need to log in repeatedly when accessing different applications. Application requests can be automatically completed to obtain the correct URL path and carry the identity token. This mechanism ensures the smoothness and consistency of cross-application access, achieving a one-time login and seamless jump experience, meeting the requirements of modern application integration platforms for high availability and user-friendliness. BRIEF DESCRIPTION OF THE DRAWINGS

[0021] Figure 1A flowchart of an identity authentication method. DETAILED DESCRIPTION

[0022] The following are specific embodiments of the present invention and the accompanying drawings to further describe the technical solutions of the present invention, but the present invention is not limited to these embodiments.

[0023] In order to reduce the reliance of identity authentication on front-end interception capabilities such as client-side Service Workers and achieve cross-terminal compatibility, the present invention proposes a two-tier routing identity authentication device for an application integration platform. The application integration platform includes: a client including a main application and multiple sub-applications, a back-end platform corresponding to the client, and back-end services corresponding to each application; each sub-application runs in the operating environment provided by the main application; the two-tier routing identity authentication device includes: a gateway module and a verification module provided on the back-end platform; wherein: The client is used to load the currently triggered application and execute the initialization script corresponding to the application. It determines whether the currently accessed URL is the main application based on the judgment result, loads and sets the corresponding application data based on the judgment result, and initiates an application request after the loading and setting are completed; the application request is a client login request or a business processing request; The corresponding application data is loaded and set according to the judgment result; specifically: When the currently triggered application is the main application, the application prefix identifier of the cookie is set to empty; when the currently triggered application is a sub-application, the JavaScript engine (Quick.js) is loaded, the URL path currently accessed is parsed, and the application prefix identifier of the cookie is set based on the parsing result; Load the application data corresponding to the current application; the application data includes: JavaScript files and CSS style files.

[0024] The application request is initiated after the loading and setting are completed, specifically: Generate an application request and obtain the support status of the Service Worker. If the status is supported, the current application request is processed by the Service Worker, the SW application support flag of the cookie is set to enabled, and when the URL path of the current request corresponds to a sub-application, the prefix of the URL path is completed by the application prefix flag of the cookie, and the application request is issued.

[0025] The present invention parses the URL path and sets the application prefix identifier during the client initialization phase, and combines the ServiceWorker front-end completion with the gateway-side path completion mechanism to effectively solve the problem of missing request paths caused by the client not supporting Service Worker. When a request is sent, if the client supports Service Worker, it intercepts the request and completes the sub-application path prefix based on the cookie; if it does not support it, the first-level routing unit automatically completes the URL path based on the application prefix identifier in the cookie, ensuring that the request can be correctly routed to the back-end service of the corresponding application, avoiding 404 or authentication failures caused by incomplete paths, achieving dual guarantees of front-end optimization and back-end fault tolerance, and significantly improving the robustness and availability of the device.

[0026] The gateway module is used to intercept application requests and perform request context adaptation processing based on the context information of the request; when the application request is a login request, a whitelist match is performed. If the match is successful, the request is forwarded to the verification module of the backend platform. If the match fails, a gateway verification is performed, and the response content is determined based on the verification result, and the corresponding response is returned to the client; The gateway module specifically includes a primary routing unit and a secondary routing unit; The first-level routing unit is used to intercept application requests and perform request context adaptation processing based on the context information of the request; it is also used to determine whether the current application request is a client login request. If so, it detects whether the current URL path of the request is in the whitelist. If it is in the whitelist, it means that the match is passed and the request is forwarded to the verification module; if not, the request is sent to the second-level routing unit; The request context adaptation processing is performed based on the context information of the request, specifically: judging whether the source of the current request is the main application through the current URL path; if not, and its URL path does not contain the application prefix identifier, the path is prefix-completed based on the application prefix identifier in the cookie.

[0027] In this embodiment, the path is prefix-completed based on the application prefix identifier in the cookie, specifically: By parsing the cookie information in the request header, the application prefix identifier (such as zgt-app-prefix= / app1) is obtained and used to complete the original URL path. For example, if the request path initiated by the client is the relative path / api / user, and the application prefix identifier in the cookie is / app1, the first-level routing unit automatically completes the request path to / app1 / api / user. This completion process relies on the context information set by the client during the initialization phase to ensure that the request can be correctly routed to the backend service of the corresponding sub-application. Even if the client fails to complete the path on the front end because it does not support or has not enabled Service Worker, it can still achieve a fallback adaptation on the gateway side to ensure the accuracy of the routing and the compatibility of the system.

[0028] The secondary routing unit is used to perform gateway verification on the client login request sent by the primary routing unit, determine the response content based on the verification result, and return the corresponding response to the client; specifically: Verify the legitimacy of the source of the request based on the request header information in the client login request, and determine whether it carries an identity token; the request header information includes cookies; If the source is legitimate and the identity token carried has not expired, the user is determined to be logged in and a redirect response is returned to the main application homepage. Otherwise, a redirect response is returned to the login interface.

[0029] In actual applications, the login requests initiated by the client may not all be the first access in the non-logged-in state. For example, the user refreshes the login page when already logged in, or directly accesses the login entrance through a bookmark. At this time, the request header still carries a valid identity token (such as Token or Session information) and is contained in header fields such as cookies. The present invention performs a legitimacy check on this type of login request through a secondary routing unit, verifies the legitimacy of the source based on the request header information, and detects whether the identity token exists and has not expired. If the check passes, it is determined that the user is in a valid login state and there is no need for repeated authentication. The redirect response is directly returned to the main application homepage to avoid repeated logins for the user; if the identity token is missing or expired, it is regarded as a non-logged-in state, and the redirection to the login interface is returned to guide the user to re-authenticate. This mechanism takes into account both security and user experience, and realizes intelligent jumps and status perception of login paths.

[0030] The verification module is used to perform identity authentication on the client login request, generate an identity token after the authentication is passed, and return the token to the client; the business processing request includes the identity token returned by the verification module; The verification module is used to authenticate the client login request, generate an identity token after the authentication is successful, and return the token to the client; specifically: The username and password in the client login request are verified based on the user data table in the database. If the verification is successful, an identity token is generated and returned to the client through the first-level routing unit; the identity token includes the user ID, token expiration time and role code.

[0031] The gateway module is also used to verify the source and identity of the request when the application request is a business processing request. If the verification is successful, the request is sent to the back-end service of the corresponding application; if the verification fails, the response content is set based on the cookie of the request and the response content is returned to the client; The first-level routing unit is further configured to forward the adapted request to the second-level routing unit when the application request is a service processing request; The secondary routing unit is also used to verify the legitimacy of the source of the request based on the request header information in the business processing request, and determine whether it carries an identity token; if the source is legitimate and the identity token carried has not expired, it is determined that the user is in a logged-in state and the request is sent to the back-end service of the corresponding application; otherwise, the response content is set based on the cookie of the request and returned to the client.

[0032] In the present invention, the legitimacy of the source of the client login request or business processing request is verified by parsing its request header information (including fields such as Origin, Referer, and cookie). Origin: indicates the source site of the request (protocol + domain name + port), which is used to indicate the source from which the request was initiated and is often used for CORS security verification; Referer: Indicates the full URL path of the source page, which refers to the web page from which the current request is linked.

[0033] Specifically, the Origin field is checked first. If it is not present, the Referer field is checked to confirm whether the domain name belongs to the preset trusted application range. Application context information (such as the application prefix identifier) ​​in the cookie is also combined to determine whether the request is within a valid application context. If the originating domain is trusted and the context information is complete and valid, the request is considered legitimate; otherwise, it is considered invalid. This mechanism effectively prevents cross-site request forgery (CSRF) and unauthorized access, ensuring the security and reliability of the authentication process.

[0034] The complete and effective judgment of the application context information in the cookie is as follows:

[0035] 1. Completeness judgment (whether it exists): Check if the cookie contains the following key fields: zgt-app-prefix: application prefix identifier; zgt-sw-enabled: SW application support flag; If these fields are missing or empty, the context is considered "incomplete".

[0036] 2. Validity judgment (whether it is “correct”): Format verification: Checks whether the application prefix identifier conforms to the predefined format (for example, the prefix is ​​a legal path " / app1" and not ".. / " or a malicious string); Validity verification: Checks whether the application corresponding to the application prefix identifier is a registered application.

[0037] The present invention constructs a two-tier identity authentication architecture in which the first-level routing unit and the second-level routing unit work together, significantly improving the security and maintainability of the device. The first-level routing unit is responsible for request interception, path completion, and whitelist matching of login requests to achieve preliminary diversion; the second-level routing unit performs in-depth verification of all business processing requests, verifies the legitimacy of the request source and the validity of the identity token, and ensures that only legitimate requests can reach the back-end service. This layered mechanism implements the design concept of "diversion upfront and security post-placement", which not only reduces the burden on the core verification module, but also prevents the risk of illegal requests bypassing the front end, forming a complete security protection closed loop and enhancing the overall security of the platform.

[0038] The response content is set based on the cookie of the request and returned to the client, specifically: The cookie-based SW application support identifier determines whether the client has enabled Service Worker. If so, the HTTP status code is set to 302, and the redirect URL path is set in the response header to point to the login page of the main application, and the response is returned to the client; if not, the HTTP status code is set to 401, and an error message is set in the response header, and the response is returned to the client; the error message indicates that the identity token has expired.

[0039] This invention addresses the issue of varying Service Worker support across different clients (such as browsers, Android, iOS, and Hongmeng apps). By introducing a SW application support identifier, the gateway can identify the client's capability status and respond accordingly with differentiated response strategies. For clients that support Service Worker, the gateway returns a 302 redirect, and the frontend automatically redirects to the login page. For clients that don't, a 401 status code and error message are returned, and login guidance is provided by the native container or JS bridge. This mechanism avoids the problem of unified redirection being unavailable on mobile devices, truly enabling compatible support for multiple terminal environments and improving the adaptability of the application integration platform within complex ecosystems.

[0040] Furthermore, this invention enables seamless user switching between main applications and sub-applications, significantly improving the user experience. By automatically setting the application prefix identifier and combining it with the path completion capabilities of a Service Worker or gateway, users no longer need to log in repeatedly when accessing different applications. Application requests are automatically completed to obtain the correct URL path and carry an identity token. This mechanism ensures smooth and consistent cross-application access, enabling a single login and seamless transition experience, meeting the high availability and user-friendliness requirements of modern application integration platforms.

[0041] The backend service of each application is used to execute the business logic of the business processing request sent by the gateway module and return the execution data to the client.

[0042] The present invention solves the authentication compatibility problem caused by differences in client capabilities by performing double-layer routing and context adaptation on application requests through the gateway module. When the application request is a login request, the gateway module implements rapid diversion based on the whitelist mechanism. If the match is passed, it will be handed over to the verification module for authentication. If it fails, the gateway module will verify it by itself, thereby improving the flexibility of authentication. For business processing requests, the gateway module verifies the source and identity of the request based on the request header information in the request after adaptation processing, ensuring the correct routing and secure access of the request. This mechanism unifies path completion and identity verification in the gateway module, reducing dependence on the client (such as Service Worker), realizing a user experience of one-time login and seamless jump in a multi-application environment, and enhancing the compatibility, security and maintainability of the application integration platform.

[0043] At the same time, the present invention decouples the core authentication logic from the client and transfers it to the back-end gateway for unified processing, greatly reducing the reliance on deep customization and interception capabilities of the client. The client only needs to execute a lightweight initialization script and set the necessary cookie identifiers without implementing complex request interception and assembly logic. When adding a new sub-application, it is only necessary to configure the routing rules in the gateway without modifying the client code on each end, which greatly simplifies the cost of multi-end collaborative development and maintenance. This design improves the scalability and maintainability of the platform, facilitates the rapid access to new applications, and supports the continuous evolution of large-scale micro-frontend architectures.

[0044] like Figure 1 As shown, the embodiment of the present invention further proposes an identity authentication method, which is applied to the double-layer routing identity authentication device described above; the method comprises the steps of:

[0045] S1: Load the currently triggered application through the client and execute the initialization script corresponding to the application; In this embodiment, after receiving a user access request, a client (such as a browser) loads the corresponding application resources based on the URL path. If the request is for the main application, the main application entry page is loaded; if it is for a sub-application, its independent JavaScript file and CSS stylesheet are loaded. The initialization script typically contains application context configuration, route registration, and Service Worker registration logic. The execution of this script establishes the application runtime environment and provides contextual support for subsequent request processing.

[0046] S2: Determine whether the currently accessed URL is the main application based on the path, load and set the corresponding application data based on the judgment result, and initiate the current application request after loading and setting are completed; Specifically, the client determines the source of the request by parsing the current URL path (e.g., / for the main application, / app1 for a sub-application). If it's a sub-application, it further loads its dedicated JavaScript engine and parses the path structure, extracting the application prefix (e.g., / app1), and writing it into a cookie (e.g., zgt-app-prefix= / app1). It also sets the SW support flag (e.g., zgt-sw-enabled=true, where true indicates "enabled"). After completing context initialization, the client initiates an application request, which could be a login request or a business processing request, carrying the already set context information, namely the cookie.

[0047] S3: intercept the application request through the first-level routing unit and perform request context adaptation processing based on the context information of the request; determine whether the current application request is a client login request, if so, proceed to the next step; if not, jump to step S7; In this embodiment, the first-level routing unit serves as the front-end entry point for the gateway module, uniformly intercepting all requests entering the system. It first parses fields such as cookie, origin, and referer in the request header to obtain contextual information such as the application prefix identifier. If the request path contains features such as / login or / auth, it is determined to be a login request and enters the whitelist verification process; otherwise, it is considered a business processing request and jumps to step S7 for subsequent identity and source verification. This bifurcation mechanism enables intelligent identification of request types and routing diversion.

[0048] S4: The first-level routing unit detects whether the current URL path of the request is in the whitelist. If it is, it means the match is passed, and the request is forwarded to the verification module and proceeds to the next step; if it is not in the whitelist, the request is sent to the second-level routing unit; It's important to note that whitelisted paths typically include public entrances that don't require identity verification, such as the main application homepage, login page, and registration page (e.g., / login, / register). If the login request path matches the whitelist, indicating a legitimate source, the primary routing unit will directly forward it to the backend platform's authentication module for username and password verification. If the path isn't on the whitelist (e.g., directly accessing / app1 / login), it's considered a possible illegal entry point or requires contextual verification. The request will be forwarded to the secondary routing unit for in-depth verification to prevent unauthorized access.

[0049] When the current URL path of the login request is not in the whitelist, the secondary routing unit verifies the legitimacy of the source of the request based on the request header information in the client login request, and determines whether it carries an identity token; if the source is legitimate and the identity token carried has not expired, the user is determined to be in the logged-in state, and a redirect response is returned to the main application homepage; otherwise, a redirect response is returned to the login interface.

[0050] Specifically, the secondary routing unit first checks whether the Origin or Referer in the request header belongs to a trusted platform domain (e.g., *.your-platform.com). It then uses the zgt-app-prefix in the cookie to determine whether the request is within a legitimate application context. If the origin is legitimate, and the identity token in the cookie is decoded and verified to be valid and not expired, the user is deemed logged in and an HTTP 302 redirect is returned to the main application homepage. If the token is missing or invalid, the user is redirected to the unified login page, ensuring user re-authentication and improving security and user experience consistency.

[0051] S5: The authentication module authenticates the client login request, generates an identity token after the authentication is successful, and returns the token to the client; Specifically, after receiving a login request, the verification module extracts the username and password and compares them against the user data table in the database. After successful authentication, an identity token (such as a JWT) is generated, containing information such as the user ID, role code, and expiration time. This token is signed using HMAC or RSA to ensure tamper-proof authentication. This token is returned to the client as part of the response, typically in a response header. It's important to note that the secondary routing unit shares a secret key (HMAC) or public key (RSA) with the verification module. Therefore, when verifying the signature, the secondary routing unit can use the same secret key (HMAC) or public key (RSA) to verify the validity of the JWT signature. When using HMAC, the secondary routing unit uses the same key for signature verification. The shared key means that the secondary routing unit uses the same key as the verification module for signing, and both share this key to verify the identity token's authenticity. When using RSA, the verification module signs with its private key, and the secondary routing unit verifies the signature with the same public key. This means that this signature verification mechanism is client-independent and securely closed.

[0052] Furthermore, in this invention, after the verification module completes identity authentication and generates an identity token, it not only returns the token to the client via a response but also sends a redirect (HTTP 302) to the client, directing it to the main application homepage. This redirect ensures that users automatically enter the main application interface after a successful login, creating a seamless "login and enter" experience. The token is typically sent in a response header and automatically carried by the client in subsequent requests for identity verification in subsequent service requests. This mechanism, combined with routing context, enables seamless transitions between main and sub-applications and unified login state management.

[0053] S6: Generate a business request through the client, add the identity token returned by the verification module to the request header of the business request to obtain a business processing request, and return to step S2; After receiving the identity token, the client stores it in memory or a temporary variable (to avoid the risk of persistent leakage). When a user triggers a business operation (such as querying data or submitting a form), the client generates a new HTTP request and adds the identity token to the request header. This request re-enters the system as a business processing request and returns to step S2 for a new round of context judgment and routing processing, forming a closed loop.

[0054] S7: forwarding the adapted request to the secondary routing unit through the primary routing unit; Specifically, for business processing requests, the first-level routing unit completes context adaptation (for example, completing the path from / api / user to / app1 / api / user) before forwarding it to the second-level routing unit. This process ensures that even if Service Worker is not enabled on the frontend or the path is incomplete, the gateway can still correctly resolve the request target, improving system robustness and compatibility.

[0055] S8: The secondary routing unit verifies the legitimacy of the source of the request based on the request header information in the business processing request, and determines whether it carries an identity token; if the source is legitimate and the identity token carried has not expired, it is determined that the user is in a logged-in state and the request is sent to the back-end service of the corresponding application; otherwise, the response content is set based on the cookie of the request and returned to the client.

[0056] In this embodiment, the secondary routing unit comprehensively verifies the origin domain (Origin / Referer), the cookie context (e.g., zgt-app-prefix), and the identity token in the request header. If the origin is trusted and the token is valid, the request is forwarded to the corresponding application's backend service. If any of these verifications fail, a redirect response to the login page or a 401 Unauthorized status is returned, prompting the client to redirect the user to log in, ensuring system security.

[0057] It should be noted that all directional indications (such as up, down, left, right, front, back, etc.) in the embodiments of the present invention are only used to explain the relative position relationship, movement status, etc. between the various components under a certain specific posture (as shown in the accompanying drawings). If the specific posture changes, the directional indication will also change accordingly.

[0058] In addition, in the present invention, descriptions such as "first," "second," and "one" are for descriptive purposes only and should not be understood to indicate or imply their relative importance or implicitly specify the number of the technical features indicated. Therefore, a feature specified as "first" or "second" may explicitly or implicitly include at least one of such features. In the description of the present invention, "plurality" means at least two, such as two, three, etc., unless otherwise specifically defined.

[0059] In the present invention, unless otherwise specified or limited, the terms "connection" and "fixation" should be understood in a broad sense. For example, "fixation" can mean fixed connection, detachable connection, or integration; mechanical connection or electrical connection; direct connection or indirect connection through an intermediate medium; internal communication between two elements or interaction between two elements, unless otherwise specified. Those skilled in the art will be able to understand the specific meanings of the above terms in the present invention based on specific circumstances.

[0060] In addition, the technical solutions between the various embodiments of the present invention can be combined with each other, but it must be based on the fact that ordinary technicians in this field can implement it. When the combination of technical solutions is mutually contradictory or cannot be implemented, it should be deemed that such a combination of technical solutions does not exist and is not within the scope of protection required by the present invention.

Claims

1. A double-layer routing identity authentication device for an application integration platform, characterized in that: The application integration platform includes: a client including a main application and multiple sub-applications, a backend platform corresponding to the client, and backend services corresponding to each application; each sub-application runs in the operating environment provided by the main application; the two-layer routing identity authentication device includes: a gateway module and a verification module set on the backend platform; wherein: The client is used to load the currently triggered application and execute the initialization script corresponding to the application. It determines whether the currently accessed URL is the main application based on the judgment result, loads and sets the corresponding application data based on the judgment result, and initiates an application request after the loading and setting are completed; the application request is a client login request or a business processing request; The gateway module is used to intercept application requests and perform request context adaptation processing based on the context information of the request; when the application request is a login request, a whitelist match is performed. If the match is successful, the request is forwarded to the verification module of the backend platform. If the match fails, a gateway verification is performed, and the response content is determined based on the verification result, and the corresponding response is returned to the client; The verification module is used to perform identity authentication on the client login request, generate an identity token after the authentication is passed, and return the token to the client; the business processing request includes the identity token returned by the verification module; The gateway module is also used to verify the source and identity of the request when the application request is a business processing request. If the verification is successful, the request is sent to the back-end service of the corresponding application; if the verification fails, the response content is set based on the cookie of the request and the response content is returned to the client; The backend service of each application is used to execute the business logic of the business processing request sent by the gateway module and return the execution data to the client.

2. A double-layer routing identity authentication device for an application integration platform according to claim 1, characterized in that: The corresponding application data is loaded and set according to the judgment result; specifically: When the currently triggered application is the main application, the application prefix identifier of the cookie is set to empty; when the currently triggered application is the sub-application, the JavaScript engine is loaded, the currently accessed URL path is parsed, and the application prefix identifier of the cookie is set based on the parsing result; Load the application data corresponding to the current application; the application data includes: JavaScript files and CSS style files.

3. A double-layer routing identity authentication device for an application integration platform according to claim 2, characterized in that: The application request is initiated after the loading and setting are completed, specifically: Generate an application request and obtain the support status of the Service Worker. If the status is supported, the current application request is processed by the Service Worker, the SW application support flag of the cookie is set to enabled, and when the URL path of the current request corresponds to a sub-application, the prefix of the URL path is completed by the application prefix flag of the cookie, and the application request is issued.

4. A double-layer routing identity authentication device for an application integration platform according to claim 3, characterized in that: The gateway module specifically includes a primary routing unit and a secondary routing unit; The first-level routing unit is used to intercept application requests and perform request context adaptation processing based on the context information of the request; it is also used to determine whether the current application request is a client login request. If so, it detects whether the current URL path of the request is in the whitelist. If it is in the whitelist, it means that the match is passed and the request is forwarded to the verification module; If it is not in the whitelist, the request is sent to the secondary routing unit; The secondary routing unit is used to perform gateway verification on the client login request sent by the primary routing unit, determine the response content based on the verification result, and return the corresponding response to the client; The verification module is used to authenticate the client login request, generate an identity token after the authentication is successful, and return the token to the client; specifically: The username and password in the client login request are verified based on the user data table in the database. If the verification is successful, an identity token is generated and returned to the client through the first-level routing unit; the identity token includes the user ID, token expiration time and role code.

5. A double-layer routing identity authentication device for an application integration platform according to claim 4, characterized in that: The request context adaptation processing is performed based on the context information of the request, specifically: judging whether the source of the current request is the main application through the current URL path; if not, and its URL path does not contain the application prefix identifier, the path is prefix-completed based on the application prefix identifier in the cookie.

6. A double-layer routing identity authentication device for an application integration platform according to claim 5, characterized in that: The secondary routing unit is used to perform gateway verification on the client login request sent by the primary routing unit, determine the response content based on the verification result, and return the corresponding response to the client; specifically: Verify the legitimacy of the source of the request based on the request header information in the client login request, and determine whether it carries an identity token; the request header information includes cookies; If the source is legitimate and the identity token carried has not expired, the user is determined to be logged in and a redirect response is returned to the main application homepage. Otherwise, a redirect response is returned to the login interface.

7. A double-layer routing identity authentication device for an application integration platform according to claim 4, characterized in that: The first-level routing unit is further configured to forward the adapted request to the second-level routing unit when the application request is a service processing request; The secondary routing unit is also used to verify the legitimacy of the source of the request based on the request header information in the business processing request, and determine whether it carries an identity token; if the source is legitimate and the identity token carried has not expired, it is determined that the user is in a logged-in state and the request is sent to the back-end service of the corresponding application; otherwise, the response content is set based on the cookie of the request and returned to the client.

8. A double-layer routing identity authentication device for an application integration platform according to claim 7, characterized in that: The response content is set based on the cookie of the request and returned to the client, specifically: The cookie-based SW application supports identifying whether the client has enabled Service Worker. If so, the HTTP status code is set to 302, and the redirect URL path is set in the response header to point to the login page of the main application, and the response is returned to the client. If not, set the HTTP status code to 401, set an error message in the response header, and return the response to the client; The error message indicates that the identity token has expired.

9. An identity authentication method, applied to the double-layer routing identity authentication device according to any one of claims 4 to 8; characterized in that: The method comprises the steps of: S1: Load the currently triggered application through the client and execute the initialization script corresponding to the application; S2: Determine whether the currently accessed URL is the main application based on the path, load and set the corresponding application data based on the judgment result, and initiate the current application request after loading and setting are completed; S3: intercept the application request through the first-level routing unit and perform request context adaptation processing based on the context information of the request; determine whether the current application request is a client login request, and if so, proceed to the next step; If not, jump to step S7; S4: The first-level routing unit detects whether the current URL path of the request is in the whitelist. If it is, it means the match is passed, and the request is forwarded to the verification module and proceeds to the next step; if it is not in the whitelist, the request is sent to the second-level routing unit; S5: The authentication module authenticates the client login request, generates an identity token after the authentication is successful, and returns the token to the client; S6: Generate a business request through the client, add the identity token returned by the verification module to the request header of the business request to obtain a business processing request, and return to step S2; S7: forwarding the adapted request to the secondary routing unit through the primary routing unit; S8: The secondary routing unit verifies the legitimacy of the source of the request based on the request header information in the business processing request, and determines whether it carries an identity token; if the source is legitimate and the identity token carried has not expired, it is determined that the user is in a logged-in state and the request is sent to the back-end service of the corresponding application; otherwise, the response content is set based on the cookie of the request and returned to the client.

10. An identity authentication method according to claim 9, characterized in that: The method also includes: when the current URL path of the login request is not in the whitelist, verifying the legitimacy of the source of the request based on the request header information in the client login request through the secondary routing unit, and determining whether it carries an identity token; if the source is legitimate and the identity token carried has not expired, it is determined that the user is in a logged-in state, and a redirect response is returned to the main application homepage; otherwise, a redirect response is returned to the login interface.

Images