Dual-layer route authentication device and authentication method for application integration platform

Abstract

The application discloses a double-layer routing authentication device and authentication method for an application integration platform, relates to the field of system authentication, and solves the compatibility problem of authentication caused by the difference in client capability 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 implements rapid shunting based on a white list mechanism, and if the matching passes, the request is authenticated by a verification module, and if the matching fails, the request is checked by the gateway module, thereby improving the authentication flexibility. For a business processing request, the gateway module verifies the source and identity of the request based on the request header information in the processed request, thereby ensuring correct routing and safe access of the request. The mechanism unifies path completion and identity verification in the gateway module, reduces the dependence on the client, realizes one-time login and seamless switching of user experience in a multi-application environment, and enhances the compatibility, security and maintainability of the application integration platform.

Description

TECHNICAL FIELD

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

[0002] In the prior art, when an application is integrated with a traffic gateway for identity authentication, the client usually intercepts and proxies the request and performs deep assembly to achieve the injection of identity information and the maintenance of routing context. This process puts high requirements on the technical support capability of the client, especially relying on the Service Worker and other front-end capabilities to uniformly intercept requests and prefix the url path based on the current request context (such as completing / api / user to / app1 / api / user) to ensure that the request can be correctly routed by the gateway to the backend service of the corresponding application.

[0003] However, due to differences in technical architecture, running environment and standard support among different clients (such as browsers, Android applications, iOS applications and Harmony applications), especially the varying degrees of support for Service Worker (such as some mobile WebView does not support or is disabled by default), it is not possible to stably implement request interception and automatic completion of path prefixing in these environments. As a result, the request is sent directly to the gateway with an incomplete path (such as / api / user), the gateway cannot correctly parse the identity context because it cannot identify the sub-application it belongs to, and thus the identity token verification fails or the routing is incorrect, ultimately causing the identity authentication process to be interrupted or the jump to be abnormal. This problem seriously limits the compatibility and security of the application integration platform in multi-terminal environments. SUMMARY

[0004] To reduce the dependence of identity authentication on the front-end interception capabilities of the client Service Worker and other front-end capabilities, and to achieve cross-terminal compatibility, the present application proposes a double-layer routing identity authentication device for an application integration platform, the application integration platform comprising: a client comprising a main application and a plurality of sub-applications, a backend platform corresponding to the client, and a backend service corresponding to each application; each sub-application runs in a running environment provided by the main application; the double-layer routing identity authentication device comprises: a gateway module and an authentication module arranged in the backend platform; wherein:

[0005] The client is configured to load the currently triggered application and execute the initialization script corresponding to the application, determine whether the currently accessed url path is the main application, load and set the corresponding application data according to the determination result, and initiate an application request after the loading and setting are completed; the application request is a client login request or a business processing request;

[0006] The gateway module is configured to intercept an application request and perform context adaptation processing according to context information of the request; when the application request is a login request, white list matching is performed; if the matching is passed, the request is forwarded to a verification module of a backend platform; if the matching is not passed, gateway verification is performed, a response content is determined based on a verification result, and a corresponding response is returned to a client;

[0007] The verification module is configured to perform identity authentication on a client login request, generate an identity token after the authentication is passed, and return the token to the client; the identity token returned by the verification module is included in the business processing request;

[0008] The gateway module is further configured to, when the application request is a business processing request, verify a source and an identity of the request; if the verification is passed, the request is sent to a backend service of a corresponding application; if the verification is not passed, response content is set based on a cookie of the request, and the response content is returned to the client;

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

[0010] Further, the corresponding application data is loaded and set according to the judgment result; specifically,

[0011] When the currently triggered application is a main application, the application prefix identifier of the cookie is set to be empty; when the currently triggered application is a sub-application, a JavaScript engine is loaded, a currently accessed url path is parsed, and the application prefix identifier of the cookie is set based on a parsing result.

[0012] The application data corresponding to the current application is loaded; the application data includes a JavaScript file and a CSS style file.

[0013] Further, the application request is initiated after the loading and setting are completed; specifically,

[0014] The application request is generated, a support state of a Service Worker is acquired, if the state is support, the current application request is processed through the Service Worker, the SW application support identifier of the cookie is set to be enabled, and when the url path of the current request corresponds to a sub-application, the prefix of the url path is completed through the application prefix identifier of the cookie, and the application request is issued.

[0015] Further, the gateway module specifically includes a first-level routing unit and a second-level routing unit;

[0016] The first-level routing unit is configured to intercept an application request, and perform request context adaptation processing according to context information of the request; and is further configured to determine whether the current application request is a client login request, and if so, to detect whether a current url path of the request is in a white list, and if so, to indicate that the matching passes, and to forward the request to a verification module; and if not, to send the request to a second-level routing unit;

[0017] The second-level routing unit is configured to perform gateway verification on the client login request sent by the first-level routing unit, to determine response content based on a verification result, and to return a corresponding response to the client;

[0018] The verification module is configured to perform identity authentication on the client login request, to generate an identity token after the authentication passes, and to return the token to the client; specifically:

[0019] The verification module is configured to perform identity authentication on the client login request, to generate an identity token after the authentication passes, and to return the token to the client; specifically:

[0020] Further, the request context adaptation processing according to the context information of the request is specifically: determining whether the source of the current request is a main application through the current url path; if not, and the url path does not contain an application prefix identifier, prefixing the path based on the application prefix identifier in the cookie.

[0021] Further, the second-level routing unit is configured to perform gateway verification on the client login request sent by the first-level routing unit, to determine response content based on a verification result, and to return a corresponding response to the client; specifically:

[0022] The second-level routing unit is configured to perform gateway verification on the client login request sent by the first-level routing unit, to determine response content based on a verification result, and to return a corresponding response to the client; specifically:

[0023] If the source is legal and the identity token carried is not expired, it is determined that the user is in a logged-in state, and a redirection response is returned to the main application homepage, otherwise, a redirection response is returned to the login interface.

[0024] Further, the first-level routing unit is further configured to forward the request after the adaptation processing to the second-level routing unit when the application request is a business processing request;

[0025] The secondary routing unit is further configured to verify the legitimacy of the source of the request based on the request header information in the business processing request, and determine whether an identity token is carried; if the source is legitimate and the carried identity token is not expired, it is determined that the user is in a logged-in state, and the request is sent to the backend service of the corresponding application; otherwise, the response content is set based on the cookie of the request, and the response content is returned to the client.

[0026] Further, the response content is set based on the cookie of the request, and the response content is returned to the client, specifically:

[0027] The cookie-based SW application supports identity judgment to determine whether the client enables the Service Worker, if yes, sets the HTTP status code as 302, and sets the redirection url path in the response header, points to the login page of the main application, and returns the response to the client; if not, sets the HTTP status code as 401, and sets the error message in the response header, and returns the response to the client; the error message indicates that the identity token has expired.

[0028] The embodiment of the application also provides an identity authentication method applied to the double-layer routing identity authentication device.

[0029] S1: loading the current triggered application through the client, and executing the initialization script corresponding to the application;

[0030] S2: determining whether the current accessed url path is the main application according to the url path, loading and setting the corresponding application data according to the determination result, and initiating the current application request after the loading and setting are completed;

[0031] S3: intercepting the application request through the primary routing unit, and performing request context adaptation processing according to the context information of the request; determining whether the current application request is a client login request, if yes, proceeding to the next step; if not, jumping to step S7;

[0032] S4: detecting whether the current url path of the request is in the white list through the primary routing unit, if yes, indicating that the matching is passed, forwarding the request to the verification module, and proceeding to the next step; if not, sending the request to the secondary routing unit;

[0033] S5: performing identity authentication on the client login request through the verification module, generating an identity token after the authentication is passed, and returning the token to the client;

[0034] S6: generating a business request through the client, adding the identity token returned by the verification module to the request header of the business request to obtain a business processing request, and returning to step S2;

[0035] S7: forwarding the adapted request to the secondary routing unit through the primary routing unit;

[0036] S8: verifying the legitimacy of the request source based on the request header information in the service processing request through the secondary routing unit, and determining whether an identity token is carried; if the source is legitimate and the carried identity token is not expired, it is determined that the user is in a logged-in state, and the request is sent to the backend service of the corresponding application; otherwise, the response content is set based on the cookie of the request, and the response content is returned to the client.

[0037] Further, the method further comprises: when the current url path of the login request is not in the whitelist, verifying the legitimacy of the request source based on the request header information in the client login request through the secondary routing unit, and determining whether an identity token is carried; if the source is legitimate and the carried identity token is not expired, it is determined that the user is in a logged-in state, and a redirection response is returned to the home page of the main application, otherwise, a redirection response is returned to the login interface.

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

[0039] (1) The application performs double-layer routing and context adaptation on application requests through the gateway module, solving the identity authentication compatibility problem caused by the difference in client capabilities. When the application request is a login request, the gateway module implements rapid shunting based on the whitelist mechanism, and if the matching is passed, it is authenticated by the verification module, and if it is not passed, it is checked by the gateway module itself, improving the authentication flexibility; for service processing requests, the gateway module verifies the source and identity of the request based on the request header information in the adapted request, ensuring correct routing and secure access of the request. This mechanism unifies path completion and identity verification in the gateway module, reducing the dependence on the client (such as Service Worker), achieving one-time login and seamless jump user experience in a multi-application environment, and enhancing the compatibility, security and maintainability of the application integration platform.

[0040] (2) The application effectively solves the problem of missing request path caused by the client not supporting the Service Worker by parsing the url path and setting the application prefix identifier in the client initialization stage, combining the Service Worker front-end completion and gateway side path bottom-up completion mechanism. When the request is sent, if the client supports the ServiceWorker, the request is intercepted by the ServiceWorker and the sub-application path prefix is completed based on the cookie; if it does not support, the first-level routing unit automatically completes the url path according to the application prefix identifier in the cookie, ensures that the request can be correctly routed to the corresponding application backend service, avoids the 404 or authentication failure caused by incomplete path, realizes the double guarantee of front-end optimization and back-end fault tolerance, and significantly improves the robustness and usability of the device.

[0041] (3) The application introduces the SW application support identifier to enable the gateway to identify the capability state of the client, and returns a differentiated response strategy accordingly. For the client supporting the Service Worker, the gateway returns 302 redirection, and the front end jumps to the login page independently; for the client not supporting the Service Worker, the gateway returns 401 status code and error message, and the native container or JS bridge performs login guidance. This mechanism avoids the problem that uniform redirection cannot be handled on mobile terminals, truly realizes the compatible support for multi-terminal environment, and improves the adaptability of the application integration platform in complex ecology.

[0042] (4) The application constructs a double-layer identity authentication architecture with the cooperation of the first-level routing unit and the second-level routing unit, which significantly improves the security and maintainability of the device. The first-level routing unit is responsible for request interception, path completion and login request whitelist matching, and realizes preliminary shunting; the second-level routing unit performs deep checking on all business requests, verifies the legality of the request source and the validity of the identity token, and ensures that only legal requests can reach the backend service. This layered mechanism realizes the design idea of "pre-shunting and post-security", which not only reduces the burden of the core verification module, but also prevents illegal requests from bypassing the front end, forming a complete security protection closed loop and enhancing the overall security of the platform.

[0043] (5) The application decouples the core identity verification logic from the client and transfers it to the backend gateway for unified processing, greatly reducing the dependence on the client's deep customization and interception capabilities. The client only needs to execute a lightweight initialization script and set the necessary cookie identifier, without implementing complex request interception and assembly logic. When adding a new sub-application, only route rules need to be configured in the gateway, without modifying the client code on each end, greatly simplifying the cost of multi-end collaborative development and maintenance. This design improves the scalability and maintainability of the platform, facilitating the rapid integration of new applications and supporting the continuous evolution of large-scale micro-frontend architecture.

[0044] (6) The application realizes seamless switching between the main application and the sub-application, significantly improving user experience. By automatically setting the application prefix identifier and combining the path completion capabilities 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 identity tokens. This mechanism ensures the smoothness and consistency of cross-application access, achieving a seamless switching experience with one login, meeting the requirements of modern application integration platforms for high availability and user friendliness. BRIEF DESCRIPTION OF DRAWINGS

[0045] Figure 1 A flowchart of an identity verification method. DETAILED DESCRIPTION

[0046] The following is a specific embodiment of the application combined with the drawings, which further describes the technical solutions of the application, but the application is not limited to these embodiments.

[0047] In order to reduce the dependence of identity verification on client-side Service Worker and other front-end interception capabilities and achieve cross-terminal compatibility, the application proposes a dual-layer routing identity verification device for an application integration platform, which includes a client containing a main application and multiple sub-applications, a backend platform corresponding to the client, and a backend service corresponding to each application. Each sub-application runs in the runtime environment provided by the main application. The dual-layer routing identity verification device includes a gateway module and a verification module set in the backend platform. Wherein:

[0048] The client is used to load the currently triggered application and execute the initialization script corresponding to the application, determine whether the currently accessed url path is the main application, load and set the corresponding application data according to the determination result, and initiate an application request after loading and setting is completed; the application request is a client login request or a business processing request;

[0049] The corresponding application data is loaded and set according to the determination result; specifically:

[0050] When the current triggered application is a main application, the application prefix identifier of the cookie is set as empty; when the current triggered application is a sub-application, a JavaScript engine (Quick.js) is loaded, the url path of the current access is parsed, and the application prefix identifier of the cookie is set based on the parsing result;

[0051] The application data corresponding to the current application is loaded; the application data includes a JavaScript file and a CSS style file.

[0052] After the loading and setting are completed, the application request is initiated.

[0053] The application request is generated, and the support state of the Service Worker is obtained; if the state is support, the current application request is processed through the Service Worker, the SW application support identifier of the cookie is set as enabled, and when the url path of the current request corresponds to a sub-application, the prefix of the url path is completed through the application prefix identifier of the cookie, and the application request is sent.

[0054] The application prefix identifier is set by parsing the url path in the client initialization stage, and the ServiceWorker front-end completion and gateway side path bottom-up completion mechanism are combined, so that the request path loss problem caused by the client not supporting the Service Worker is effectively solved. When the request is sent, if the client supports the Service Worker, the request is intercepted by the Service Worker and the sub-application path prefix is completed based on the cookie; if not, the url path is automatically completed by the first routing unit according to the application prefix identifier in the cookie, so that the request can be correctly routed to the backend service of the corresponding application, and the 404 or authentication failure caused by incomplete path is avoided, realizing the double guarantee of front-end optimization and back-end fault tolerance, and significantly improving the robustness and usability of the device.

[0055] The gateway module is used for intercepting application requests and performing request context adaptation processing according to the context information of the request; when the application request is a login request, white list matching is performed, if the matching is passed, the request is forwarded to the verification module of the backend platform, if the matching is not passed, gateway verification is performed, and the response content is determined based on the verification result, and the corresponding response is returned to the client;

[0056] The gateway module specifically includes a first routing unit and a second routing unit.

[0057] The primary routing unit is configured to intercept an application request and perform request context adaptation processing according to context information of the request, and is further configured to determine whether the current application request is a client login request, and if so, to determine whether a current url path of the request is in a white list, and if so, to indicate that the match passes, and to forward the request to a verification module, and if not, to send the request to a secondary routing unit.

[0058] The request context adaptation processing according to the context information of the request is specifically: determining whether the source of the current request is a main application through the current url path, and if not, and the url path does not contain an application prefix identifier, then prefix-completing the path based on the application prefix identifier in the cookie.

[0059] In this embodiment, the prefix-completing of the path based on the application prefix identifier in the cookie is specifically:

[0060] The application prefix identifier (such as zgt-app-prefix= / app1) in the cookie information in the request header is obtained by parsing the cookie information in the request header, and the original url path is completed using the identifier. For example, if the request path initiated by the client is a relative path / api / user, and the application prefix identifier in the cookie is / app1, then the primary routing unit automatically completes the request path to / app1 / api / user. The completion process relies on the context information set by the client in the initialization stage, ensuring 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 completion in the front end due to not supporting or not enabling the Service Worker, the fallback adaptation can be realized on the gateway side, ensuring the accuracy of routing and the compatibility of the system.

[0061] The secondary routing unit is configured 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, and specifically:

[0062] The source legality of the client login request is verified based on the request header information in the request, and it is determined whether the identity token is carried; the request header information includes a cookie;

[0063] If the source is legal and the identity token carried is not expired, it is determined that the user is in a logged-in state, and a redirection response is returned to the home page of the main application, otherwise, a redirection response is returned to the login interface.

[0064] In actual application, the login request initiated by the client can not be the first access in the non-logged-in state, for example, the user refreshes the login page in the logged-in state or directly accesses the login portal through a bookmark. At this time, the valid identity token (such as Token or Session information) is still carried in the request header and is included in the cookie or other header fields. The application verifies the legitimacy of the login request through the secondary routing unit, verifies the legitimacy of the source based on the request header information, and detects whether the identity token exists and is not expired. If the verification is passed, it is determined that the user is in the valid logged-in state, and no repeated authentication is required, and a redirection response is directly returned to the home page of the main application, thereby avoiding repeated login of the user; if the identity token is missing or has expired, it is regarded as the non-logged-in state, and a redirection is returned to the login interface to guide the user to re-authenticate. The mechanism takes into account the security and user experience, and realizes intelligent jump and state perception of the login path.

[0065] The verification module is configured 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.

[0066] The verification module is configured 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; and specifically:

[0067] The username and password in the client login request are verified based on the user data table in the database, and an identity token is generated after the verification is passed, and the identity token is returned to the client through the primary routing unit; the identity token includes a user ID, a token expiration time, and a role code.

[0068] The gateway module is further configured to, when the application request is a business processing request, verify the source and identity of the request, and send the request to the backend service of the corresponding application after the verification is passed; and set response content based on the cookie of the request, and return the response content to the client after the verification fails.

[0069] The primary routing unit is further configured to, when the application request is a business processing request, forward the request after the adaptive processing to the secondary routing unit.

[0070] The secondary routing unit is further configured to verify the legitimacy of the source of the request based on the request header information in the business processing request, and determine whether the identity token is carried; if the source is legitimate and the carried identity token is not expired, it is determined that the user is in the logged-in state, and the request is sent to the backend service of the corresponding application; otherwise, response content is set based on the cookie of the request, and the response content is returned to the client.

[0071] In the present application, the source legitimacy of the client login request or service processing request is verified by analyzing the request header information (including Origin, Referer, cookie and other fields). Among them:

[0072] Origin: indicates the source site of the request (protocol + domain name + port), which is used to indicate from which source the request is initiated, and is commonly used for CORS security verification;

[0073] Referer: indicates the complete url path of the source page, indicating which web page link the current request comes from.

[0074] Specifically, the Origin field is checked first, and if it does not exist, the Referer is checked to confirm whether its domain name belongs to the preset trusted application range. At the same time, combined with the application context information (such as application prefix identifier) in the cookie, it is judged whether the request is in a legal application context. If the source domain is trusted and the context information is complete and valid, it is considered a legal request; otherwise, it is determined to be an illegal request. This mechanism effectively prevents cross-site forgery requests (CSRF) and illegal entry access, ensuring the security and reliability of the identity verification process.

[0075] For the complete and effective judgment of the application context information in the cookie, specifically:

[0076] 1. Integrity judgment (whether "has"):

[0077] Check if the key fields in the cookie exist, such as:

[0078] zgt-app-prefix: application prefix identifier;

[0079] zgt-sw-enabled: SW application support identifier;

[0080] If these fields are missing or empty, it is considered that the "context is not complete".

[0081] 2. Effectiveness judgment (whether "correct"):

[0082] Format verification: check if the application prefix identifier conforms to the pre-defined format (such as the prefix is a legal path " / app1", not ".. / " or malicious string);

[0083] Legitimacy verification: check if the application corresponding to the application prefix identifier is a registered application.

[0084] The application constructs a double-layer identity authentication architecture in which a first-level routing unit and a second-level routing unit work cooperatively, and significantly improves 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, and realizes preliminary shunting. The second-level routing unit performs deep checking on all business processing requests, verifies the legality of the request source and the validity of the identity token, and ensures that only legal requests can reach the backend service. The hierarchical mechanism realizes the design idea of "pre-shunting and post-security", which not only reduces the burden of the core verification module, but also prevents illegal requests from bypassing the front end, forms a complete security protection closed loop, and enhances the overall security of the platform.

[0085] The cookie-based request is set as a response content, and the response content is returned to the client, specifically:

[0086] The cookie-based SW application support identification judges whether the client enables the Service Worker, if yes, sets the HTTP status code as 302, sets the redirection url path in the response header, points to the login page of the main application, and returns the response to the client; if not, sets the HTTP status code as 401, sets the error message in the response header, and returns the response to the client; the error message indicates that the identity token has expired.

[0087] The application introduces the SW application support identification to enable the gateway to identify the capability state of the client, and returns a differentiated response strategy accordingly. For the client supporting the Service Worker, the gateway returns 302 redirection, and the front end jumps to the login page by itself; for the client not supporting the Service Worker, the gateway returns the 401 status code and the error message, and the native container or JS bridge guides the login. The mechanism avoids the problem that uniform redirection cannot be handled on the mobile end, truly realizes the compatible support for the multi-terminal environment, and improves the adaptive ability of the application integration platform in the complex ecology.

[0088] In addition, the application realizes the seamless switching of users between the main application and the sub-application, and significantly improves the user experience. By automatically setting the application prefix identification and combining the path completion capability of the Service Worker or the gateway, the user does not need to log in repeatedly when accessing different applications, and the application request can be automatically completed to obtain the correct url path and carry the identity token. The mechanism guarantees the fluency and consistency of cross-application access, realizes the use experience of one-time login and seamless jump, and meets the requirements of high availability and user friendliness of the modern application integration platform.

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

[0090] The application solves the identity authentication compatibility problem caused by the difference in client capability by performing double-layer routing and context adaptation on the application request through the gateway module. When the application request is a login request, the gateway module implements rapid shunting based on a whitelist mechanism. If the matching passes, the gateway module authenticates the request; if the matching fails, the gateway module verifies the request by itself, thereby improving the authentication flexibility. For a business processing request, the gateway module verifies the source and identity of the request based on the request header information in the adapted processing request, thereby ensuring correct routing and secure access of the request. The mechanism completes the path completion and identity verification in the gateway module, reduces the dependence on the client (such as the Service Worker), realizes the one-time login and seamless jump user experience in the multi-application environment, and enhances the compatibility, security, and maintainability of the application integration platform.

[0091] Meanwhile, the application decouples the core identity authentication logic from the client and transfers it to the backend gateway for unified processing, thereby greatly reducing the dependence on the deep customization and interception capability of the client. The client only needs to execute a lightweight initialization script and set the necessary cookie identifier, without implementing complex request interception and assembly logic. When a new sub-application is added, the gateway only needs to configure the routing rules, without modifying the client code of each end, thereby greatly simplifying the multi-end collaborative development and maintenance cost. The design improves the scalability and maintainability of the platform, facilitates the rapid access of new applications, and supports the continuous evolution of large-scale micro-frontend architecture.

[0092] As shown in Figure 1 The application also provides an identity authentication method applied to the double-layer routing identity authentication device.

[0093] S1: loading the application triggered by the client and executing the initialization script corresponding to the application;

[0094] In this embodiment, the client (such as a browser) receives a user access request, loads the corresponding application resource according to the URL path. If the request is directed to the main application, the main application entry page is loaded; if it is a sub-application, the independent JavaScript file and CSS style file of the sub-application are loaded. The initialization script usually includes application context configuration, route registration, and Service Worker registration logic. The execution of the script marks the establishment of the application running environment, and provides context support for subsequent request processing.

[0095] S2: judging whether the current accessed url path is the main application according to the current accessed url path, loading and setting the corresponding application data according to the judgment result, and initiating the current application request after the loading and setting are completed;

[0096] Specifically, the client judges the request source by parsing the current URL path (such as / indicates the main application, and / app1 indicates the sub-application). If it is a sub-application, the exclusive JavaScript engine of the sub-application is further loaded and the path structure is parsed, the application prefix identifier (such as / app1) is extracted, and it is written into the cookie (such as zgt-app-prefix= / app1). At the same time, the SW support identifier (such as zgt-sw-enabled=true, where true indicates "enabled") is set. After the context initialization is completed, the client initiates an application request, which can be a login request or a business processing request, carrying the set context information, that is, the cookie.

[0097] S3: intercepting the application request through the first routing unit, and performing request context adaptation processing according to the context information of the request; judging whether the current application request is a client login request, if yes, entering the next step; if no, jumping to step S7;

[0098] In this embodiment, the first routing unit serves as the front-end entrance of the gateway module, and uniformly intercepts all requests entering the system. It first parses the cookie, Origin, Referer and other fields in the request header to obtain the context information such as the application prefix identifier. If the request path contains / login, / auth and other features, it is determined as a login request, and the white list verification process is entered; otherwise, it is regarded as a business processing request, and jumps to step S7 for subsequent identity and source verification. This branching mechanism realizes intelligent identification and routing of request types.

[0099] S4: detecting, by the first routing unit, whether the current url path of the request is in the white list, if yes, indicating that the matching passes, forwarding the request to the verification module, and entering the next step; if not, sending the request to the second routing unit;

[0100] It should be noted that the white list path usually includes the main application homepage, login page, registration page and other public entrances (such as / login, / register) that do not need identity verification. If the path of the login request matches the white list, it means that the source is legal, and the first routing unit directly forwards it to the verification module of the back-end platform for username and password authentication; if the path is not in the white list (such as directly accessing / app1 / login), it is considered that it may come from an illegal entrance or needs context verification, and the request is handed over to the second routing unit for deep verification to prevent unauthorized access.

[0101] When the current url path of the login request is not in the whitelist, the secondary routing unit verifies the legitimacy of the request source based on the request header information in the client login request, and judges whether the identity token is carried; if the source is legal and the carried identity token is not expired, it is determined that the user is in a logged-in state, and a redirection response is returned to the home page of the main application, otherwise, a redirection response is returned to the login interface.

[0102] Specifically, the secondary routing unit first checks whether the Origin or Referer in the request header belongs to the platform trusted domain name (such as: *. your-platform.com), and judges whether it is in a legal application context in combination with the zgt-app-prefix in the cookie. If the source is legal, and the identity token in the cookie is not expired and the signature is valid after decoding verification, it is determined that the user has logged in, and an HTTP 302 redirection is returned to the home page of the main application; if the token is missing or invalid, it is redirected to the unified login page to ensure that the user re-authenticates, and to improve security and user experience consistency.

[0103] S5: performing identity authentication on the client login request through the verification module, generating an identity token after authentication, and returning the token to the client;

[0104] Specifically, after the verification module receives the login request, the username and password are extracted, and the user data table in the database is queried for comparison. After authentication, an identity token (such as JWT) containing user ID, role code, expiration time, etc. is generated, and HMAC or RSA signature is used to ensure that it cannot be tampered with. The token is returned to the client as part of the response, usually under the response header. It should be noted that the secondary routing unit and the verification module share the key (HMAC) or public key (RSA), so the secondary routing unit uses the same key (HMAC) or public key (RSA) when verifying the signature, which can verify whether the JWT signature is valid: when using HMAC, the secondary routing unit uses the same key to verify the signature; wherein the same key means that the key used by the secondary routing unit and the key used by the verification module for signature are the same, and the two share the key for anti-fake verification of the identity token. When using RSA, the verification module uses a private key to sign, and the secondary routing unit uses the same public key to verify the signature. That is, this signature verification mechanism does not depend on the client and is a secure closed loop.

[0105] In addition, in the present application, when the verification module completes identity authentication and generates an identity token, the token is not only returned to the client through a response, but also a redirection instruction (HTTP 302) is sent to the client to guide it to the home page of the main application. The redirection ensures that the user automatically enters the main application interface after successful login, realizing a smooth experience of “logging in to enter”. The token is usually issued in the form of a response header, which is automatically carried by the client in subsequent requests for identity verification of subsequent business requests. This mechanism combines the routing context to achieve seamless jumping between the main and sub-applications and unified login state management.

[0106] S6: The client generates a business request, adds the identity token returned by the verification module to the request header of the business request to obtain a business processing request, and returns to the S2 step;

[0107] After receiving the identity token, the client stores it in the memory or a temporary variable (to avoid the risk of persistent leakage). When the 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. The request reenters the system as a business processing request, returns to the S2 step for a new round of context judgment and routing processing, forming a closed loop.

[0108] S7: The first-level routing unit forwards the adapted request to the second-level routing unit;

[0109] Specifically, for the business processing request, the first-level routing unit forwards it to the second-level routing unit after completing context adaptation (such as path completion: completing / api / user to / app1 / api / user). This process ensures that even if the front end does not enable the Service Worker or the path is incomplete, the gateway can still correctly parse the request target, improving the robustness and compatibility of the system.

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

[0111] In this embodiment, the second-level routing unit verifies the source domain (Origin / Referer), the cookie context (such as zgt-app-prefix), and the identity token in the request header. If the source is trusted and the token is valid, the request is forwarded to the backend service of the corresponding application; if any verification fails, a redirection response is returned to the login page, or a 401 unauthorized state is returned, and the client redirects the user to log in accordingly, ensuring the security boundary of the system.

[0112] It should be noted that all directional indications, such as upper, lower, left, right, front, rear, etc., are only used for explanation purposes and are not intended to limit the scope of the present application.

[0113] In addition, the terms "first", "second", "one", etc. in the present application are only used for descriptive purposes and cannot be understood as indicating or implying the relative importance of the technical features indicated or implying the number of technical features indicated. Therefore, the features defined as "first", "second" can explicitly or implicitly include at least one of the features. In the description of the present application, the meaning of "a plurality of" is at least two, for example, two, three, etc., unless otherwise explicitly specified and limited.

[0114] In the present application, unless otherwise explicitly specified and limited, the terms "connection", "fixing" and the like should be understood in a broad sense, for example, "fixing" can be fixed connection, or detachable connection, or integral; can be mechanical connection, or electrical connection; can be directly connected, or indirectly connected through an intermediate medium; can be the internal communication of two elements or the interaction relationship between two elements, unless otherwise explicitly limited. For those skilled in the art, the specific meaning of the above terms in the present application can be understood according to the specific circumstances.

[0115] In addition, the technical solutions of each embodiment of the present application can be combined with each other, but it must be based on the realization of the ordinary skilled in the art, when the combination of technical solutions appears contradictory or cannot be realized, it should be considered that the combination of technical solutions does not exist, nor within the scope of protection required by the present application.

Claims

1. A dual-layer routing authentication apparatus for application integration platform, characterized in that, The application integration platform comprises a client comprising a main application and a plurality of sub-applications, a backend platform corresponding to the client, and a backend service corresponding to each application; each sub-application runs in a running environment provided by the main application; the double-layer routing authentication device comprises a gateway module and an authentication module arranged in the backend platform; wherein: The client is configured to load a currently triggered application, execute an initialization script corresponding to the application, determine whether the currently accessed url path is the main application, load and set corresponding application data according to the determination result, and initiate an application request after the loading and setting are completed; the application request is a client login request or a business processing request; The application data is loaded and set according to the determination result; specifically: When the currently triggered application is the main application, the application prefix identifier of the cookie is set to be empty; when the currently triggered application is the sub-application, a 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; The application data corresponding to the current application is loaded; the application data comprises a JavaScript file and a CSS style file; The application request is initiated after the loading and setting are completed; specifically: The application request is generated, and the support state of the Service Worker is obtained; if the state is supported, the current application request is processed through the Service Worker, the SW application support identifier of the cookie is set to be enabled, and when the url path of the current request corresponds to the sub-application, the prefix of the url path is completed through the application prefix identifier of the cookie, and the application request is sent; if the state is not supported, the url path is automatically completed by the first routing unit according to the application prefix identifier in the cookie; The gateway module is configured to intercept the application request and perform request context adaptation processing according to the context information of the request; when the application request is a login request, white list matching is performed; if the matching is passed, the request is forwarded to the authentication module of the backend platform; if the matching is not passed, gateway verification is performed, the response content is determined based on the verification result, and the corresponding response is returned to the client; The authentication module is configured 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 identity token returned by the authentication module is included in the business processing request; The gateway module is further configured to, when the application request is a business processing request, verify the source and identity of the request; if the verification is passed, the request is sent to the backend service of the corresponding application; if the verification is not passed, 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 configured to execute the business logic of the business processing request sent by the gateway module, and return the execution data to the client.

2. The dual-layer routing authentication apparatus for application integration platform of claim 1, wherein, The gateway module specifically comprises a first routing unit and a second routing unit; The first-level routing unit is configured to intercept an application request, and perform request context adaptation processing according to context information of the request; and is further configured to determine whether the current application request is a client login request, and if so, to detect whether a current url path of the request is in a white list, and if so, to indicate that the matching passes, and to forward the request to a verification module; If not, the request is sent to a second-level routing unit; The second-level routing unit is configured to perform gateway verification on the client login request sent by the first-level routing unit, and determine response content based on a verification result, and return a corresponding response to the client; The verification module is configured to perform identity authentication on the client login request, generate an identity token after the authentication passes, and return the token to the client; specifically: The username and password in the client login request are verified based on a user data table in a database, and if the verification passes, an identity token is generated, and the identity token is returned to the client through the first-level routing unit; the identity token includes a user ID, a token expiration time, and a role code.

3. The dual-layer routing authentication apparatus for application integration platform of claim 2, wherein, The request context adaptation processing according to the context information of the request is specifically: determining whether the source of the current request is a main application through the current url path; if not, and the url path does not contain an application prefix identifier, the path is prefixed based on the application prefix identifier in the cookie.

4. The dual-layer routing authentication apparatus for application integration platform of claim 3, wherein, The second-level routing unit is configured to perform gateway verification on the client login request sent by the first-level routing unit, and determine response content based on a verification result, and return a corresponding response to the client; specifically: The source legality of the request is verified based on request header information in the client login request, and whether the identity token is carried is determined; the request header information includes a cookie; If the source is legal and the carried identity token is not expired, it is determined that the user is in a logged-in state, a redirection response is returned to the main application homepage, otherwise, a redirection response is returned to the login interface.

5. The dual-layer routing identity verification device for an application integration platform according to claim 2, wherein 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 business processing request; The second-level routing unit is further configured to verify the source legality of the request based on request header information in the business processing request, and determine whether an identity token is carried; if the source is legal and the carried identity token is not expired, it is determined that the user is in a logged-in state, and the request is sent to a backend service of a corresponding application; otherwise, response content is set based on the cookie of the request, and the response content is returned to the client.

6. The dual-layer routing authentication apparatus for application integration platform according to claim 5, wherein, The response content is set based on the cookie, and the response content is returned to the client, specifically: If the client enables a Service Worker based on a cookie-based SW application support identifier, an HTTP status code is set to 302, a redirection url path is set in a response header, pointing to a login page of the main application, and the response is returned to the client; If not, set the HTTP status code as 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.

7. An identity authentication method applied to the dual-layer routing identity authentication device of any one of claims 2 to 6, characterized in that, The method comprises the steps of: S1: loading the current triggered application through the client and executing the initialization script corresponding to the application; S2: judging whether the current accessed url path is the main application according to the url path, loading and setting the corresponding application data according to the judgment result, and initiating the current application request after the loading and setting are completed; S3: intercepting the application request through the first-level routing unit, and performing request context adaptation processing according to the context information of the request; if the current application request is a client login request, go to the next step; If not, jump to step S7; S4: detecting whether the current url path of the request is in the white list through the first-level routing unit, if in the white list, indicating that the matching is passed, forwarding the request to the verification module, and going to the next step; if not in the white list, sending the request to the second-level routing unit; S5: performing identity authentication on the client login request through the verification module, generating an identity token after the authentication is passed, and returning the token to the client; S6: generating a business request through the client, adding the identity token returned by the verification module to the request header of the business request to obtain a business processing request, and returning to step S2; S7: forwarding the request after adaptation processing to the second-level routing unit through the first-level routing unit; S8: verifying the legitimacy of the source of the request based on the request header information in the business processing request through the second-level routing unit, and judging whether the identity token is carried; if the source is legal and the carried identity token is not expired, it is determined that the user is in a logged-in state, and the request is sent to the backend service of the corresponding application; otherwise, setting the response content based on the cookie of the request, and returning the response content to the client.

8. The identity verification method of claim 7, wherein, The method further comprises: when the current url path of the login request is not in the white list, verifying the legitimacy of the source of the client login request based on the request header information in the client login request through the second-level routing unit, and judging whether the identity token is carried; if the source is legal and the carried identity token is not expired, it is determined that the user is in a logged-in state, and a redirection response is returned to the main application homepage, otherwise, a redirection response is returned to the login interface.

Images