Smooer unified authentication access method

Abstract

The invention discloses a smoother unified authentication access method, and belongs to the technical field of information security. The method comprises the following steps that: an entry control module executes Token existence judgment and address source judgment, and obtains a unified authentication address through a fetch method; the front-end system dynamically creates a hidden iframe loading unified authentication address, and establishes a message monitor; the lightweight callback processing module detects a running environment, extracts code information, and sends the code information to a parent window through a postMessage method; the entry control module receives code information, verifies a source, stores the code information to a temporary variable, and triggers a custom event; and the routing interception authority control module obtains code information, sends an authorized login request to a rear end, stores Token after completing user identity verification, and enters a system. According to the method, authentication is completed in the current page through an iframe and post Message communication mechanism, so that repeated page skipping and repeated resource loading are avoided, non-perception silent authentication is realized, and user experience and system performance are improved.

Description

Technical Field

[0001] This invention relates to the field of information security technology, and more particularly to a smoother unified authentication access method. Background Technology

[0002] With the development of internet technology, unified identity authentication has become a crucial component of digital transformation across various industries. Unified authentication refers to a unified authentication platform where users can access multiple application systems with a single authentication verification. By integrating the authentication mechanisms of different systems, it enables cross-system identity management, improves user experience, simplifies user management, and reduces security vulnerabilities. Currently, the demand for unified authentication across multiple enterprise application systems is increasing, and the authentication loading performance of subsystems connected to a unified authentication platform directly impacts the user experience. Traditional unified authentication access models have the following problems: After a user clicks on a subsystem from their browser, the system first loads the subsystem's resources. If the token is not found, it obtains the unified authentication address by interacting with the backend. The frontend then redirects to the unified authentication platform via `window.location`, resulting in a page redirect and resource reloading. After unified authentication login, a 302 status code redirect carrying the code directly redirects to the subsystem address, requiring the subsystem to reload system resources, leading to duplicate resource loading. If unified authentication is not successful, the subapplication needs to redirect multiple times between its initial opening and successful authentication. The multiple page redirects and redundant resource loading caused by the 302 status code directly impact user experience, resulting in low login logic processing efficiency, frequent refreshes, and high resource consumption. Summary of the Invention

[0003] The purpose of this invention is to provide a smoother unified authentication access method to solve the problems existing in the prior art.

[0004] This invention provides a smoother unified authentication access method, comprising the following steps: The entry control module performs a token existence check, retrieving the token information from the session storage using the sessionStorage.getItem method. If the token information exists, the page is rendered directly; otherwise, subsequent authentication steps are executed. The entry control module performs address source determination and obtains the parameter information carried in the URL through the window.location.search method. When the URL does not carry parameters or the parameter value is not oauth, the page is rendered directly. When the parameter value is oauth, subsequent authentication steps are executed. The entry control module sends a unified authentication request to the backend server via the fetch method. The backend server requests the authentication address from the unified authentication platform based on the configured clientId and appKey parameters, and returns the authentication address to the frontend system. The front-end system dynamically creates iframe elements, sets the unified authentication address to the src attribute value of the iframe, and establishes a message listener using the window.addEventListener method; The lightweight callback processing module detects whether the current page is running in an iframe environment, extracts the code information returned by the unified authentication platform callback from the URL parameters, and sends the code information to the parent window through the postMessage method; The message listener of the entry control module receives code information, verifies event.origin, stores the code information in the window.RHYY_AUTH_CODE temporary variable, creates a custom event authCodeReceived through CustomEvent and triggers the event; The route interception and access control module intercepts page redirection requests through route hook functions, checks whether a token exists, and if the token does not exist and the address source is oauth, it obtains the code information and sends an authorization login request to the backend server. The backend server interacts with the unified authentication platform to complete user authentication, and the frontend system stores the returned token in sessionStorage and executes page redirection to the target system page.

[0005] The above technical solution combines a lightweight iframe authentication module with the postMessage cross-window communication mechanism to complete unified authentication authorization verification within the current page. The user remains on the main page throughout the process, and the authentication process is completed by hiding the iframe. This avoids the problem of multiple page jumps caused by 302 status codes in traditional solutions, greatly shortens the entire authorization callback chain, reduces the number of browser refreshes and system resource consumption, achieves seamless static authentication, and significantly improves system loading speed and user experience.

[0006] Furthermore, when the entry control module establishes a message listener, a timeout mechanism is set. A 30-second timeout timer is set using the setTimeout method. If no code information is received after 30 seconds, the iframe element is automatically cleaned up and an error message is displayed to the user.

[0007] Furthermore, the lightweight callback processing module is deployed in the oauth.html file. The lightweight callback processing module detects the runtime environment based on the following conditions: the current window is not the top-level window, or the parent window exists and is not equal to the current window. When the runtime environment meets the above conditions, the code information extraction and sending steps continue to be executed. When the runtime environment does not meet the conditions, the execution is terminated.

[0008] Furthermore, when the lightweight callback processing module sends code information to the parent window via the postMessage method, it specifies the target source address to ensure that the message is only sent to the intended parent window.

[0009] Furthermore, the steps for the routing interception permission control module to obtain code information include: first, checking whether a code value exists in the temporary variable window.RHYY_AUTH_CODE; if a valid code value exists, using that code value directly; if no valid code value exists, obtaining the code value by listening to the custom authCodeReceived event.

[0010] Furthermore, the routing interception and access control module performs the following steps to distinguish the source of the address: obtaining the value of the origin parameter from the URL parameters, determining whether the value of the origin parameter is equal to oauth, identifying that the current request comes from the unified authentication callback and continuing to execute the code acquisition step when the value of the origin parameter is not equal to oauth, and executing the normal non-login processing logic when the value of the origin parameter is not equal to oauth.

[0011] Furthermore, the iframe element dynamically created by the front-end system is set to a hidden state, with its width and height set to 0 pixels and its border set to none; the iframe only contains the parameter parsing script and the communication script.

[0012] Furthermore, when the front-end system stores the token in sessionStorage, the storage key is SESSION; when the user closes the browser page, the token stored in sessionStorage is automatically cleared.

[0013] The beneficial effects of this invention are: 1. This invention loads a unified authentication address by dynamically creating a hidden iframe and using the postMessage method for cross-window communication to transmit code information. The user stays on the main page to complete the authentication process, avoiding the problem of multiple page jumps caused by the 302 status code in traditional solutions, reducing the number of browser refreshes, achieving seamless static authentication, and significantly improving the user experience.

[0014] 2. This invention uses a lightweight callback processing module that includes only necessary parameter parsing scripts and communication scripts. The main page prioritizes loading key resources, and the authentication logic is executed dynamically in an asynchronous manner. Unified authentication authorization verification is completed within the current page, avoiding the repeated loading of subsystem resources, greatly shortening the entire authorization callback chain, reducing system resource consumption, and improving system loading performance.

[0015] 3. This invention uses oauth.html as an independent page to handle the sensitive parameter code. When sending a message via postMessage, it strictly verifies event.origin to ensure the security of the message source. The code information is only temporarily stored in window.RHYY_AUTH_CODE and is not exposed to global variables. The token is stored in sessionStorage and is automatically cleared after the page is closed. The origin parameter value is used to verify the URL address source to avoid triggering the authentication process multiple times. This invention implements a multi-layer security isolation mechanism, effectively preventing XSS attacks and reducing the risk of token leakage. Attached Figure Description

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

[0017] Figure 1 This is a sequence diagram for traditional unified authentication access. Figure 2 This is a timing diagram for the smoother unified authentication access scheme of the present invention; Figure 3 This is a flowchart of the entry control module of the present invention; Figure 4 This is a complete flowchart of the subsystem access unified authentication process of the present invention. Detailed Implementation

[0018] The present invention will now be described in detail with reference to the accompanying drawings and specific embodiments. It should also be noted that, to make the embodiments more comprehensive, the following embodiments are the best and preferred embodiments, and those skilled in the art can use other alternative methods to implement some well-known technologies; moreover, the accompanying drawings are only for more specific description of the embodiments and are not intended to specifically limit the present invention.

[0019] It should be noted that the use of terms such as "an embodiment," "an embodiment," "an exemplary embodiment," and "some embodiments" in the specification indicates that the described embodiment may include a specific feature, structure, or characteristic, but not every embodiment necessarily includes that specific feature, structure, or characteristic. Furthermore, when a specific feature, structure, or characteristic is described in connection with an embodiment, implementing such a feature, structure, or characteristic in conjunction with other embodiments (whether explicitly described or not) should be within the knowledge of those skilled in the art.

[0020] Generally, terms can be understood at least partly from their use in context. For example, depending at least partly on the context, the term "one or more" as used herein can be used to describe any feature, structure, or characteristic in a singular sense, or a combination of features, structures, or characteristics in a plural sense. Additionally, the term "based on" can be understood not necessarily to convey an exclusive set of factors, but rather, alternatively, depending at least partly on the context, to allow for the presence of other factors that are not necessarily explicitly described.

[0021] See Figures 1 to 4 As shown This invention provides a smoother unified authentication access method. By constructing an iframe authentication module and a route interception mechanism, the authentication process system is reconstructed, effectively reducing the frequency of repeated page refreshes during unified authentication access, reducing redundant resource loading, significantly improving the user experience, and ensuring smooth system interaction.

[0022] The method described in this invention comprises three core modules: an entry control module, a lightweight callback processing module, and a route interception permission control module.

[0023] I. Entry Control Module The entry control module is deployed in the index.html file and is responsible for executing the unified authentication triggering logic. This module uses token judgment technology and port source judgment technology to actively trigger the unified authentication verification logic. The specific execution steps of the entry control module are as follows: Step A1, Token Existence Check: During the initial page load, the system retrieves the Token information corresponding to the SESSION from the session storage using the sessionStorage.getItem method. If the Token information already exists, the system directly executes the return operation, skipping subsequent authentication logic and proceeding directly to page rendering, thereby shortening the user's waiting time. If the Token information does not exist, the system continues to execute subsequent authentication steps.

[0024] Step A2, Address Source Determination: When a user accesses the project address via a URL, the system retrieves the parameter information carried in the URL using the `window.location.search` method. The system identifies whether the parameters meet the preset verification conditions. When the URL does not carry any parameters, the system directly renders the page. When the URL carries parameters but the parameter value is not `oauth`, the system directly renders the page and does not perform unified authentication verification. When the URL carries parameters and the parameter value is `oauth`, the system continues to perform subsequent authentication steps.

[0025] Step A3, Actively Triggering Unified Authentication Verification: The system actively sends a unified authentication request to the backend server via the fetch method. The backend server requests the authentication address from the unified authentication platform based on the pre-configured clientId and appKey parameters. The backend server then returns the obtained unified authentication address to the frontend system.

[0026] Step A4, Creating a Lightweight iframe Authentication Module: After obtaining the unified authentication address, the front-end system dynamically creates an iframe element. The system sets the unified authentication address as the iframe's src attribute value, causing the iframe to load the unified authentication page. As a lightweight authentication module, the iframe only contains the necessary parameter parsing scripts and communication scripts, and does not contain any additional dependencies.

[0027] Step A5, Establish a message listening mechanism: The system establishes a message listener using the `window.addEventListener` method. The message listener continuously listens for the `code` information returned from the lightweight callback processing module of `oauth.html`. The system has a 30-second timeout mechanism; if no `code` information is received after 30 seconds, the system automatically cleans up the iframe element and displays an error message to the user.

[0028] Step A6, Receiving and Processing Callback Data: After the message listener recognizes the code information, the system first verifies `event.origin` to confirm that the message originates from a secure authentication address. Upon successful verification, the system stores the code information in the temporary variable `window.RHYY_AUTH_CODE`. The system creates a custom event `authCodeReceived` using `CustomEvent` and encapsulates the code information within this event. The system triggers the `authCodeReceived` event, sending the authentication code information to the routing interception and access control module for subsequent use.

[0029] II. Lightweight Callback Handling Module The lightweight callback processing module is deployed in the oauth.html file, serving as a dedicated page for handling sensitive parameters of the unified authentication callback. This module intelligently analyzes and checks the runtime environment, sending callback parameters via postMessage to complete the closed loop of the unified authentication callback process. The specific execution steps of the lightweight callback processing module are as follows: Step B1, Runtime Environment Identification: After the module is loaded, the system first retrieves the parameter information carried in the URL using the `window.location.search` method. The system checks whether the current page is running in an iframe environment, specifically determining if the current window is not the top-level window, or if a parent window exists and is not equal to the current window. If the runtime environment meets the above conditions, the system continues with subsequent steps. If the runtime environment does not meet the conditions, the system terminates execution.

[0030] Step B2, code information extraction: The system extracts the code information returned by the unified authentication platform callback from the URL parameters. The code information is a unique identifier that the unified authentication platform carries to the callback address via redirection after the user completes authentication.

[0031] Step B3, Security Message Sending: After confirming that the operating environment meets the requirements, the system sends the code information to the parent window via the postMessage method. The system specifies the target source address when sending the message to ensure that the message is only sent to the intended parent window, preventing sensitive information from being leaked to unauthorized pages.

[0032] III. Routing Interception Access Control Module The route interception and access control module intercepts page redirects through route hook functions, distinguishes between user login status, identifies the address source in non-logged-in scenarios, obtains the corresponding code information based on the source, authorizes automatic login, and enters the system after obtaining user information. The specific execution steps of the route interception and access control module are as follows: Step C1, Route Interception and Token Verification: The system intercepts page redirection requests using route hook functions. The system first calls the `hasToken` method to determine if a valid token exists in the current session. If the token exists, the system directly redirects the user to the target system page according to the preset routing logic. If the token does not exist, the system continues with subsequent authentication steps.

[0033] Step C2, Address Source Differentiation: The system retrieves the `origin` parameter value from the URL parameters. The system then determines whether the `origin` parameter value is equal to `oauth`. If the `origin` parameter value is not equal to `oauth`, the system executes the standard not-logged-in processing logic. If the `origin` parameter value is equal to `oauth`, the system recognizes that the current request originates from the unified authentication callback and continues with the subsequent code retrieval steps.

[0034] Step C3, code information acquisition: The system first checks if a code value exists in the temporary variable `window.RHYY_AUTH_CODE`. If a valid code value exists in `window.RHYY_AUTH_CODE`, the system uses that code value directly. If no valid code value exists in `window.RHYY_AUTH_CODE`, the system obtains the code value by listening to the custom `authCodeReceived` event. The system waits for the `authCodeReceived` event to be triggered and extracts the code value from the event data.

[0035] Step C4, Automatic Authorization Login: After obtaining a valid code value, the system sends the code value as a request parameter to the backend server. The backend server uses the code value to interact with the unified authentication platform to complete user authentication. After verifying the validity of the code value, the unified authentication platform returns user authorization information to the backend server. The backend server generates a system token and returns the token and complete user information to the frontend system.

[0036] Step C5, Token Storage and Page Redirection: After receiving the token and user information, the front-end system stores the token in sessionStorage with the key name SESSION. Once the token is stored, the system executes a page redirection, and the user is redirected to the target system page.

[0037] IV. Security Isolation Mechanism This invention implements multiple layers of security isolation measures throughout the certification process: `oauth.html` handles the sensitive parameter `code` as a separate page, using `sessionStorage` to isolate token storage and prevent XSS attacks. `postMessage` strictly validates `event.origin` when sending messages to ensure the security of the message source. The `code` obtained by the authentication module is only temporarily stored using `window.RHYY_AUTH_CODE` and is not exposed to global variables. The token is stored in `sessionStorage` and is automatically cleared when the user closes the browser page, reducing the risk of token leakage. The system verifies the URL address source marker through the `origin` parameter value to avoid triggering the authentication process multiple times.

[0038] Example 1 This embodiment describes the complete authentication process for a user's first access to the subsystem.

[0039] Step 1: The user opens a browser, enters the subsystem access address in the address bar, and presses Enter. The browser requests subsystem resources from the server.

[0040] Step 2: The server returns the index.html entry file, and the browser begins to parse and load the index.html file.

[0041] Step 3: The index.html entry control module performs a token existence check. The system calls the sessionStorage.getItem method, passing in the SESSION parameter, to query whether token information exists in the session storage. Since this is the user's first visit, the token information corresponding to the SESSION does not exist in the session storage, and the result is that the token does not exist.

[0042] Step 4: The index.html entry control module performs address source determination. The system calls the window.location.search method to retrieve URL parameters. Since the user directly enters the address to access the site, the URL does not carry the origin parameter, and the system identifies it as a non-OAuth origin.

[0043] Step 5: The system directly renders the page and loads the system's key resources, including stylesheet files and JavaScript framework files.

[0044] Step 6: The system detects that the user is not logged in and proactively triggers unified authentication verification. The system sends a request to the backend server via the fetch method, with the request path being the authentication address retrieval interface.

[0045] Step 7: After receiving the request, the backend server uses the pre-configured clientId value client_001 and appKey value key_abc123 to request an authentication address from the unified authentication platform. The unified authentication platform returns the authentication address https: / / auth.example.com / oauth / authorize?client_id=client_001&redirect_uri=https: / / app.example.com / oauth.html.

[0046] Step 8: The backend server returns the unified authentication address to the frontend system.

[0047] Step 9: The front-end system dynamically creates an iframe element, sets the iframe's src attribute to the unified authentication address, sets the iframe's style attribute to hide it, sets the iframe's width to 0 pixels, height to 0 pixels, and border to none.

[0048] Step 10: The front-end system adds a message event listener using the window.addEventListener method, ready to receive messages from the iframe.

[0049] Step 11: The front-end system starts a 30-second timeout timer and calls the setTimeout method to set the scheduled task.

[0050] Step 12: The iframe loads the unified authentication address. Since this is the user's first visit, the unified authentication platform detects that the user is not logged in and displays the unified authentication login page.

[0051] Step 13: On the unified authentication login page, the user enters the username user001 and password password123, and clicks the login button.

[0052] Step 14: The unified authentication platform verifies the user's credentials. Upon successful verification, it generates an authorization code `code_xyz789`. The unified authentication platform then performs a redirect, redirecting the user's browser to the preset callback address `https: / / app.example.com / oauth.html?code=code_xyz789`.

[0053] Step 15: Load the oauth.html page in the iframe, with the code value code_xyz789 in the URL parameters.

[0054] Step 16: The lightweight callback processing module in oauth.html performs runtime environment identification. The system determines whether the current window is a top-level window. The result is that the current window is not a top-level window and is running in an iframe environment.

[0055] Step 17: The lightweight callback processing module of oauth.html extracts the code value code_xyz789 from the URL parameters.

[0056] Step 18: The lightweight callback handling module of oauth.html calls the window.parent.postMessage method to send a message to the parent window. The message content is a JSON object containing a code value, and the target source address is https: / / app.example.com.

[0057] Step 19: The message event listener of the index.html entry control module receives the message. The system first verifies whether the event.origin value is https: / / app.example.com, and the verification passes.

[0058] Step 20: The system extracts the code value code_xyz789 from the message data and assigns it to the temporary variable window.RHYY_AUTH_CODE.

[0059] Step 21: The system creates a custom event named `authCodeReceived`, with the event data containing the value `code_xyz789`. The system then calls the `window.dispatchEvent` method to trigger this custom event.

[0060] Step 22: The system cancels the 30-second timeout timer and removes the iframe element.

[0061] Step 23: The route interception and access control module intercepts page redirection requests. The system calls the hasToken method to determine if the token exists; the result is that the token does not exist.

[0062] Step 24: The system retrieves the origin value (oauth) from the URL parameters. The system recognizes that the current request originates from a unified authentication callback.

[0063] Step 25: The system checks the window.RHYY_AUTH_CODE variable and obtains the code value code_xyz789.

[0064] Step 26: The system sends an authorization login request to the backend server using the code value code_xyz789 as a request parameter.

[0065] Step 27: The backend server uses the code value code_xyz789 to interact with the unified authentication platform. The unified authentication platform verifies the validity of the code value and returns user information: username user001, user ID 10001, and department: Technology Department.

[0066] Step 28: The backend server generates a system token value, token_abc123def456, and returns the token value and user information to the frontend system.

[0067] Step 29: The front-end system calls the sessionStorage.setItem method to store the Token value token_abc123def456 in the session storage with the key name SESSION.

[0068] Step 30: The system completes the authorized login, redirects the user to the system's main page.

[0069] Example 2 This embodiment describes the quick access process for a user who is already logged in to access a subsystem.

[0070] Step 1: The user opens a browser, enters the subsystem access address in the address bar, and presses Enter. The browser requests subsystem resources from the server.

[0071] Step 2: The server returns the index.html entry file, and the browser begins to parse and load the index.html file.

[0072] Step 3: The index.html entry control module performs a token existence check. The system calls the sessionStorage.getItem method, passing in the SESSION parameter, to query the session storage. Since the user has already logged in during the current session, the session storage contains the token information token_abc123def456 corresponding to the SESSION, and the result is that the token exists.

[0073] Step 4: The system executes a return operation, skipping all subsequent authentication logic and directly proceeding to page rendering.

[0074] Step 5: The system loads key resources, including stylesheet files and JavaScript framework files.

[0075] Step 6: The route interception and access control module intercepts page redirection requests. The system calls the hasToken method to determine if the token exists; the result is that the token exists.

[0076] Step 7: The system redirects the user directly to the main page based on the preset routing logic.

[0077] Step 8: The entire access process did not trigger unified authentication verification, did not create an iframe, and did not exchange codes, resulting in a smooth and seamless user experience.

[0078] Example 3 This embodiment describes the authentication process where the unified authentication platform actively redirects to a subsystem.

[0079] Step 1: The user clicks the subsystem entry link on the unified authentication platform page. The unified authentication platform detects that the user is logged in and generates an authorization code: code_mno456.

[0080] Step 2: The unified authentication platform performs a redirect, redirecting the user's browser to the subsystem address https: / / app.example.com / ?origin=oauth.

[0081] Step 3: The browser requests subsystem resources from the server. The server returns the index.html entry file.

[0082] Step 4: The index.html entry control module performs a token existence check. The system calls the sessionStorage.getItem method to query the session storage. Since this is the user's first visit to the subsystem, the session storage does not contain the token information corresponding to the SESSION, and the result is that the token does not exist.

[0083] Step 5: The index.html entry control module performs address source determination. The system calls the window.location.search method to retrieve the URL parameter, and the origin parameter is found to be oauth. The system recognizes that the current request originates from a redirect from the unified authentication platform.

[0084] Step 6: The system actively triggers unified authentication verification. The system sends a request to the backend server using the fetch method to obtain the unified authentication address.

[0085] Step 7: The backend server returns the unified authentication address https: / / auth.example.com / oauth / authorize?client_id=client_001&redirect_uri=https: / / app.example.com / oauth.html.

[0086] Step 8: The front-end system dynamically creates a hidden iframe element and sets the iframe's src attribute to the unified authentication address.

[0087] Step 9: Add a message event listener to the front-end system and start a 30-second timeout timer.

[0088] Step 10: The iframe loads the unified authentication address. Since the user has already logged in to the unified authentication platform, the platform directly generates a new authorization code, code_pqr789, and redirects the user to the callback address https: / / app.example.com / oauth.html?code=code_pqr789.

[0089] Step 11: The iframe loads the oauth.html page. The lightweight callback processing module in oauth.html performs runtime environment identification, confirming that it is running in the iframe environment.

[0090] Step 12: The lightweight callback processing module of oauth.html extracts the code value code_pqr789 and sends it to the parent window via the postMessage method.

[0091] Step 13: The message event listener of the index.html entry control module receives the message, verifies the source, extracts the code value, and assigns it to the window.RHYY_AUTH_CODE variable.

[0092] Step 14: The system creates and triggers the authCodeReceived custom event, cancels the timeout timer, and removes the iframe element.

[0093] Step 15: The route interception and access control module intercepts page redirection. The system determines that the token does not exist, obtains the origin value oauth from the URL parameters, and obtains the code value code_pqr789 from window.RHYY_AUTH_CODE.

[0094] Step 16: The system sends the code value to the backend server for authorized login. The backend server interacts with the unified authentication platform to obtain user information.

[0095] Step 17: The backend server returns the token value token_ghi789jkl012 and user information. The frontend system stores the token in sessionStorage.

[0096] Step 18: The system completes the authorization login, and the user enters the system's main page. Throughout the entire process, the user remains on the subsystem page without any perceptible page redirection.

[0097] Example 4 This embodiment describes the exception handling process for authentication timeout.

[0098] Step 1: The user opens a browser and accesses the subsystem address. The system loads the index.html entry file.

[0099] Step 2: The system determines that the token does not exist and the address source is not OAuth. The system triggers unified authentication verification, obtains the unified authentication address, and creates an iframe to load the unified authentication page.

[0100] Step 3: Add a message event listener to the system and start a 30-second timeout timer.

[0101] Step 4: Due to network failure or abnormality of the unified authentication platform, the iframe failed to load the unified authentication page, oauth.html failed to execute, and code information failed to be sent.

[0102] Step 5: The 30-second timeout timer triggers the callback function.

[0103] Step 6: The system performs cleanup operations in the callback function: remove the iframe element and remove the message event listener.

[0104] Step 7: The system displays an error message to the user, indicating that the authentication timed out and asking them to try again.

[0105] Step 8: The user clicks the retry button, and the system re-executes the authentication process.

[0106] The above detailed implementation methods and embodiments describe the technical solution implementation process of the present invention. The present invention, through a lightweight iframe authentication module, a postMessage cross-window communication mechanism, and route interception permission control, achieves seamless static authentication, on-demand resource loading, security isolation, and event-driven interaction during the unified authentication access process. This effectively solves the problems of multiple page jumps and redundant resource loading in traditional unified authentication access schemes, significantly improving user experience and system loading performance.

[0107] This invention encompasses any substitutions, modifications, equivalent methods, and solutions made within the spirit and scope of this invention. To provide the public with a thorough understanding of this invention, specific details are described in detail in the following preferred embodiments; however, those skilled in the art will fully understand the invention even without these details. Furthermore, to avoid unnecessary misunderstanding of the essence of this invention, well-known methods, processes, procedures, components, and circuits are not described in detail.

[0108] The above description is only a preferred embodiment of the present invention. It should be noted that for those skilled in the art, several improvements and modifications can be made without departing from the principle of the present invention, and these improvements and modifications should also be considered within the scope of protection of the present invention.

Claims

1. A smoother unified authentication access method, characterized in that, Includes the following steps: The entry control module performs a token existence check, retrieving the token information from the session storage using the sessionStorage.getItem method. If the token information exists, the page is rendered directly; otherwise, subsequent authentication steps are executed. The entry control module performs address source determination and obtains the parameter information carried in the URL through the window.location.search method. When the URL does not carry parameters or the parameter value is not oauth, the page is rendered directly. When the parameter value is oauth, subsequent authentication steps are executed. The entry control module sends a unified authentication request to the backend server via the fetch method. The backend server requests the authentication address from the unified authentication platform based on the configured clientId and appKey parameters, and returns the authentication address to the frontend system. The front-end system dynamically creates iframe elements, sets the unified authentication address to the src attribute value of the iframe, and establishes a message listener using the window.addEventListener method; The lightweight callback processing module detects whether the current page is running in an iframe environment, extracts the code information returned by the unified authentication platform callback from the URL parameters, and sends the code information to the parent window through the postMessage method; The message listener of the entry control module receives code information, verifies event.origin, stores the code information in the window.RHYY_AUTH_CODE temporary variable, creates a custom event authCodeReceived through CustomEvent and triggers the event; The route interception and access control module intercepts page redirection requests through route hook functions, checks whether a token exists, and if the token does not exist and the address source is oauth, it obtains the code information and sends an authorization login request to the backend server. The backend server interacts with the unified authentication platform to complete user authentication, and the frontend system stores the returned token in sessionStorage and executes page redirection to the target system page.

2. The more streamlined unified authentication access method according to claim 1, characterized in that, When the entry control module establishes a message listener, it sets a timeout mechanism by using the setTimeout method to set a 30-second timeout timer. If no code information is received within 30 seconds, the iframe element is automatically cleaned up and an error message is displayed to the user.

3. The more streamlined unified authentication access method according to claim 1, characterized in that, The lightweight callback processing module is deployed in the oauth.html file. The conditions for the lightweight callback processing module to detect the running environment are: the current window is not the top-level window, or the parent window exists and the parent window is not equal to the current window. When the running environment meets the above conditions, the code information extraction and sending steps continue to be executed. When the running environment does not meet the conditions, the execution is terminated.

4. The more streamlined unified authentication access method according to claim 1, characterized in that, When the lightweight callback processing module sends code information to the parent window via the postMessage method, it specifies the target source address to ensure that the message is only sent to the intended parent window.

5. A more streamlined unified authentication access method according to claim 1, characterized in that, The steps for the route interception permission control module to obtain code information include: first, checking whether there is a code value in the window.RHYY_AUTH_CODE temporary variable; if a valid code value exists, using that code value directly; if no valid code value exists, obtaining the code value by listening to the authCodeReceived custom event.

6. A more streamlined unified authentication access method according to claim 1, characterized in that, The routing interception permission control module performs the following steps to distinguish the address source: obtain the origin parameter value from the URL parameters, determine whether the origin parameter value is equal to oauth, when the origin parameter value is equal to oauth, identify that the current request comes from the unified authentication callback and continue to execute the code acquisition step, when the origin parameter value is not equal to oauth, execute the normal not logged in processing logic.

7. A more streamlined unified authentication access method according to claim 1, characterized in that, The iframe element dynamically created by the front-end system is set to a hidden state, with a width of 0 pixels, a height of 0 pixels, and no border; the iframe only contains parameter parsing scripts and communication scripts.

8. A more streamlined unified authentication access method according to claim 1, characterized in that, When the front-end system stores the token in sessionStorage, the storage key is named SESSION; when the user closes the browser page, the token stored in sessionStorage is automatically cleared.

Images