Browser switching method combined with single sign-on

Abstract

The invention discloses a browser switching method combined with single sign-on, which relates to the technical field of browser switching, and comprises the following steps: judging a user login state of an initial application, performing login authentication processing by utilizing single sign-on verification to obtain a session identifier of the initial application, and writing the session identifier into a session credential of an initial browser; transmitting a target application access parameter according to a click result, performing browser jump judgment by utilizing single sign-on, and generating a session token, anti-opening equipment multiplexing relational data and a browser switching front-end page; starting a target browser, generating an optimized target address, generating a synchronous session front-end page, and calling a session setting interface of single sign-on to transmit a session token; and establishing a target browser session, and redirecting to the optimized target address for target application login. According to the cross-browser login-free switching method and the cross-browser login-free switching device, the problem that the traditional single sign-on cannot share the login state in a cross-browser manner is solved by synchronizing the front-end page of the session, and the safe and seamless cross-browser login-free switching is realized.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of browser switching, in particular to a browser switching method combined with single sign-on. BACKGROUND

[0002] Due to the early development of individual application systems, only old browsers such as IE8 can be used for access. While new systems are mostly developed based on new browsers such as chrome, the new system wants to call the link of the old system or develop the navigation function to jump to the old system, which will be limited by the browser isolation. The biggest obstacle is the synchronization of user session state, different browser cookies are not shared, and different browsers will cause the user to need to log in again. And the existing browser switching mainly relies on the following technical paths to solve this problem: technical scheme one is that the user manually transmits the link, that is, the user opens the chrome browser, accesses the A system address, logs in to the A system, the A system generates the access link of the B system, the user copies the link, opens the IE browser, inputs the copied link, the user logs in to the B system, jumps to the target address, and completes the access; technical scheme two is a cookie copying scheme, that is, the user opens the chrome browser, installs a browser extension plug-in, accesses the A system address, logs in to the A system, the A system calls the extension plug-in, the extension plug-in copies the user cookie information in the chrome browser, opens and imports the IE browser, the IE browser jumps to the target address, and completes the access; technical scheme three is a shared token transmission scheme, in which the SSO system is connected to the system, specifically, the user opens the chrome browser, the A system attaches the token containing user information issued by the SSO to the B system link, and automatically opens the IE browser to access the B system address with the token information, the B system exchanges the user information with the SSO using the token to establish the user session state, complete the login, jump to the target address, and complete the access.

[0003] Under the background of pursuing efficient and convenient enterprise applications, browser switching between systems needs to achieve fast and convenient user experience. In the existing technical scheme, technical scheme one is the simplest and does not require additional development, but it relies on the user to manually copy the link and switch the browser to log in again, which is cumbersome and has poor experience, and it is difficult to meet the convenience requirements; technical scheme two can realize automatic jump and session reuse through the browser extension plug-in, avoiding repeated login, but it highly depends on the compatibility of the plug-in to the browser type and version, and requires the user to actively install and configure, which has high promotion cost and is difficult to popularize in a large-scale environment; technical scheme three does not require client plug-in, and transmits user identity information between systems through SSO token, which can realize automatic jump and login-free, and has good user experience, but requires the source system to generate the token, the target system to support token verification and exchange user information, which involves more system modification, and has high development and integration cost.

[0004] The prior art has the above problems. SUMMARY

[0005] The present application provides a browser switching method combined with single sign-on to overcome the above technical problems of the prior art.

[0006] To this end, the present application adopts the following specific technical solutions:

[0007] A browser switching method combined with single sign-on, the method comprising the following steps:

[0008] S1, judging the user login state of the initial application, performing login authentication processing based on the single sign-on verification result according to the user login state judgment result, obtaining the session identifier of the initial application, and writing the session identifier of the initial application into the session credential of the initial browser;

[0009] S2, transmitting target application access parameters according to the click result of the target application link in the initial application, judging browser jump based on the target application access parameters and access request header data using single sign-on, and generating a session token according to the browser jump judgment result and the session identifier of the initial application;

[0010] S3, generating anti-device multiplexing relationship data based on the session identifier of the initial application, the session token, and the access request header data, generating a browser switching front-end page according to the target application access parameters and the session token as parameters of a script execution function;

[0011] S4, starting the target browser using the script execution function and generating an optimized target address, generating a synchronous session front-end page using single sign-on according to the session token and the optimized target address, and calling the set session interface of single sign-on to input the session token into the synchronous session front-end page;

[0012] S5, querying the corresponding anti-device multiplexing relationship data according to the input session token, comparing with the obtained session request data, establishing a target browser session according to the comparison result, and redirecting the synchronous session front-end page to the optimized target address for target application login.

[0013] Further, the judgment of the user login state of the initial application comprises:

[0014] Obtaining the session identifier of the user access request, and judging the user login state of the initial application according to the session identifier of the user access request to obtain the user login state judgment result.

[0015] Further, the target application access parameters include: target application number, target browser type, and target application access address.

[0016] Further, the target application access parameter is transmitted according to a click result of the target application link in the initial application, browser jump judgment is performed based on the target application access parameter and the access request header data by using single sign-on, and a session token is generated according to a browser jump judgment result and a session identifier of the initial application, including:

[0017] S21, transmitting the target application access parameter by using a browser switching interface of the single sign-on called by the initial application according to a click result of the target application link in the initial application;

[0018] S22, obtaining an initial browser type by using the single sign-on based on a user agent of the access request header data, comparing the initial browser type with a target browser type, and performing browser jump judgment according to a comparison result to obtain a browser jump judgment result;

[0019] S23, generating a session token according to a session identifier of the initial application when the browser jump judgment result is jump.

[0020] Further, the anti-device multiplexing relationship data is generated based on the session identifier of the initial application, the session token, and the access request header data, the browser switching front-end page is generated according to the target application access parameter and the session token as parameters of a script execution function, including:

[0021] S31, extracting a client address by using the single sign-on according to the access request header data, and obtaining device information of the user agent in the access request header data;

[0022] S32, storing a corresponding relationship between the session token and the session identifier of the initial application, the client address, and the device information of the user agent in a cache to obtain the anti-device multiplexing relationship data;

[0023] S33, generating the browser switching front-end page according to the target browser type, the target application access address, and the session token as parameters of the script execution function.

[0024] Further, the target browser is started by using the script execution function, and the optimized target address is generated, including:

[0025] The session token and the target application access address are accessed by using the script execution function of the browser switching front-end page to splice an access path to obtain the optimized target address;

[0026] A browser jump prompt mode is obtained according to the target browser type, and the target browser is started according to an obtaining result of the browser jump prompt mode.

[0027] Further, the corresponding anti-device-multiplexing relationship data is queried according to the incoming session token, and the obtained session request data is compared, a target browser session is established according to the comparison result, and the synchronous session front-end page is redirected to the optimized target address for target application login, including:

[0028] S51, querying the corresponding anti-device-multiplexing relationship data in the cache according to the incoming session token, obtaining the queried anti-device-multiplexing relationship data;

[0029] S52, comparing the queried anti-device-multiplexing relationship data with the obtained session request data, and obtaining the session identifier of the initial application in the queried anti-device-multiplexing relationship data according to the comparison result;

[0030] S53, setting the session credential of the target browser through the session identifier of the initial application, and establishing the target browser session;

[0031] S54, redirecting the synchronous session front-end page to the optimized target address, and processing the authorization request of the target browser according to the session credential of the target browser using single sign-on, and completing the target application login.

[0032] Further, the session request data includes: session request address and session request device information.

[0033] Further, comparing the queried anti-device-multiplexing relationship data with the obtained session request data includes:

[0034] Comparing the client address in the queried anti-device-multiplexing relationship data with the obtained session request address to obtain an address comparison result;

[0035] Comparing the client address in the queried anti-device-multiplexing relationship data with the obtained session request device information to obtain a device information comparison result;

[0036] Integrating the address comparison result and the device information comparison result to obtain a device consistency comparison result.

[0037] Further, according to the session credential of the target browser, the authorization request of the target browser is processed using single sign-on to complete the target application login, including:

[0038] According to the session credential of the target browser, the user session information is identified, and based on the identification result of the user session information, the authorization request of the target browser is processed using single sign-on to complete the target application login.

[0039] The beneficial effects of the present application are:

[0040] 1. The application solves the pain point that the traditional single sign-on cannot share the login state across browsers by synchronizing the session front-end page, and realizes safe and seamless cross-browser login-free switching. The problem that different browsers cannot share is solved by cross-browser session synchronization, that is, the problem that the session cannot be shared due to the isolation of session credentials between two browsers is solved, and the transmission of user login state between heterogeneous browsers is realized.

[0041] 2. The application realizes browser switching and login-free function by single sign-on, has high convenience, wide applicability and does not need additional development; compared with the existing scheme, the user does not need to manually copy the link or switch the browser, and does not need to log in repeatedly, and can automatically complete browser switching and session migration, improve the convenience of user use, and significantly improve the use experience; compared with the scheme depending on the browser plug-in, the application does not depend on the plug-in, has strong compatibility, and is not limited by the browser version; compared with the scheme that needs to modify the code of the access system, the application only needs to encapsulate the initial application link as a single sign-on jump interface, and realizes it by single sign-on, greatly reduces the access cost, simplifies the deployment process, has stronger popularization and practicality. BRIEF DESCRIPTION OF DRAWINGS

[0042] In order to more clearly illustrate the technical solutions in the embodiments of the present application or the prior art, the drawings needed in the embodiments will be briefly introduced as follows. Obviously, the drawings in the following description only constitute some embodiments of the present application, and for those skilled in the art, other drawings can also be obtained without creative labor on the basis of these drawings.

[0043] Figure 1 is a flow chart of a browser switching method combined with single sign-on according to an embodiment of the present application;

[0044] Figure 2 is a flow chart of a browser switching method combined with single sign-on in actual application according to an embodiment of the present application. DETAILED DESCRIPTION

[0045] In order to further illustrate the embodiments, the present application provides drawings, which are part of the disclosure of the present application, mainly used to illustrate the embodiments, and can explain the operating principle of the embodiments in conjunction with the related description of the specification. With reference to these contents, those skilled in the art should understand other possible embodiments and advantages of the present application.

[0046] According to an embodiment of the present application, a browser switching method combined with single sign-on is provided.

[0047] The present application will be further described in conjunction with the drawings and specific embodiments, such as Figure 1As shown, according to an embodiment of the present invention, a browser switching method combined with single sign-on includes the following steps:

[0048] A browser switching method combined with single sign-on, characterized in that the method includes:

[0049] S1. Determine the user login status of the initial application. Based on the user login status determination result, use single sign-on verification to perform login authentication processing, obtain the session identifier of the initial application, and write the session identifier of the initial application into the session credentials of the initial browser.

[0050] Specifically, determining the initial user login status for the application includes:

[0051] Obtain the session identifier of the user access request, and perform an initial user login status determination based on the session identifier of the user access request to obtain the user login status determination result.

[0052] Specifically, in this invention, both the initial application and the target application have been integrated into a single sign-on (SSO) system based on the standard OAuth 2.0 authorization protocol. OAuth 2.0, as an industry standard protocol, has broad applicability. The specific process is as follows: Figure 2 As shown, it is stipulated that system A (i.e., the initial application) is only accessible to browser A (i.e., the initial browser), and system B (i.e., the target application) is only accessible to browser B (i.e., the target browser).

[0053] Specifically, when a user accesses system A, that is, the user launches browser A and visits system A's homepage, SSO login verification is performed. This means system A has implemented SSO (Single Sign-On). System A checks the user's login status on system A. If it detects that the user is not logged in, it triggers the standard SSO authentication process. After the user successfully logs in, the SSO system writes a sessionId containing the user's information into browser A's cookie (the initial browser session credential).

[0054] Specifically, different systems maintain user login status in different ways, such as the common session method or token method. Taking the session method as an example, firstly, a user accesses the address of system A. System A checks whether the request carries system A's sessionId. If it does, and the sessionId is valid and has not expired, then the user is determined to be logged in, and access is granted directly; the user completes the access. If it does not carry the sessionId or the sessionId has expired, then the user is determined not to be logged in, and the standard SSO authentication process is entered. After the user logs in, system A obtains the user information through SSO, generates a sessionId based on the user information, inserts a cookie into the request response, and returns it to the user's browser (i.e., the initial browser).

[0055] S2. Based on the click results of the target application link in the initial application, pass the target application access parameters. Based on the target application access parameters and access request header data, use single sign-on to determine browser redirection. Generate a session token based on the browser redirection determination result and the session identifier of the initial application.

[0056] Specifically, the target application access parameters include: target application ID, target browser type, and target application access address.

[0057] Specifically, based on the click result of the target application link in the initial application, the target application access parameters are passed. Single sign-on is used to determine browser redirection based on the target application access parameters and access request header data. A session token is generated based on the browser redirection determination result and the session identifier of the initial application, including:

[0058] S21. Based on the click results of the target application link in the initial application, use the browser switching interface of single sign-on in the initial application to pass the target application access parameters.

[0059] S22. The user agent uses single sign-on to obtain the initial browser type based on the access request header data, compares the initial browser type with the target browser type, and makes a browser redirection judgment based on the comparison result to obtain the browser redirection judgment result.

[0060] S23. When the browser's redirection judgment result is a redirection, a session token is generated based on the session identifier of the initial application.

[0061] Specifically, based on the initial click result of the target application link in the application, access to System B is initiated, meaning the user clicks a link pointing to System B on the System A interface. System A calls the SSO browser switching interface / sso / browserSwitch, passing parameters (i.e., target application access parameters). These parameters include clientId=C19, which is the encoding of the target System B, and can be used for subsequent optimization to reduce the number of redirects and improve user experience; browser=IE, which specifies the target browser type; and url=http%3A%2F%2Fwww.B.com, which is the access address of the target System B.

[0062] Specifically, generating a session token involves SSO retrieving the original browser type from the User-Agent header (i.e., the user agent) and the target browser type from the input parameter `browser`. If the browser type remains the same, the browser redirection decision is made to redirect directly to the URL shown in the input parameter without needing to redirect to a different browser. If the browser types are different, the browser redirection decision is made to redirect, and a 12-bit random session token is generated based on the initial application's session identifier.

[0063] S3. Generate anti-opening device reuse relationship data based on the initial application's session identifier, session token, and access request header data. Generate the browser switching front-end page based on the target application's access parameters and session token as parameters of the script execution function.

[0064] Specifically, based on the initial application's session identifier, session token, and access request header data, anti-tampering device reuse relationship data is generated. Using the target application's access parameters and session token as parameters for the script execution function, the browser switching front-end page is generated, including:

[0065] S31. Extract the client address using single sign-on based on the access request header data, and obtain the device information of the user agent in the access request header data;

[0066] S32. Store the correspondence between the session token and the session identifier, client address and device information of the user agent of the initial application into the cache to obtain the anti-opening device reuse relationship data.

[0067] S33. Generate a browser switching front-end page based on the target browser type, target application access address, and session token as parameters of the script execution function.

[0068] Specifically, SSO first extracts the sessionId from the request's cookie, then retrieves the source IP (client address) and device information from the User-Agent from the request header (i.e., access request header data). The mapping between the session token and the sessionId, source IP, and device information in the User-Agent is stored in Redis (i.e., cache) to obtain anti-device reuse relationship data, and an expiration time of 5 seconds is set. Normal browser switching is fast, and setting a shorter expiration time helps reduce the risk of interception and impersonation. Finally, the browser type (browser), target access URL, and generated session token are passed as parameters to a blank front-end page containing only JavaScript, serving as input parameters for the script execution function to initiate the target browser's startup process. Switching the browser to the front-end page returns to the initial browser front-end.

[0069] S4. Use the script execution function to launch the target browser and generate an optimized target address. Based on the session token and the optimized target address, use single sign-on to generate a synchronous session front-end page. Call the single sign-on session settings interface to the synchronous session front-end page and pass the session token.

[0070] Specifically, using script execution functions to launch the target browser and generate an optimized target URL includes:

[0071] By using the browser's script execution function to switch the front-end page, the session token and the target application access address are concatenated to obtain the optimized target address;

[0072] Obtain the browser redirection hint based on the target browser type, and launch the target browser based on the result of obtaining the browser redirection hint.

[0073] Specifically, the target browser, i.e., the front-end page in browser A, launches browser B via a JavaScript script. The script performs the following tasks:

[0074] First, the path to be accessed after redirecting to the browser at the concatenation point ( / sso / queryAndSetSessionId.html?sessionId=xxx&targetUrl=xxx) is appended to the URL with the token and target address as parameters. Second, different browser launch methods are executed depending on the browser type. For example, if redirecting to Google Chrome, the Google Chrome browser is opened at the target address via ActiveXObject command line (cmd.exe / c start chrome.exe url). If redirecting to Internet Explorer, a custom protocol (openIE:url) is required. This is achieved by defining the openIE protocol in the registry, and accessing the protocol opens Internet Explorer via command line.

[0075] Specifically, the process involves requesting a session synchronization page, meaning browser B accesses the SSO session synchronization page (e.g., / sso / queryAndSetSessionId.html?sessionId=xxx&targetUrl=xxx). Here, the parameter `sessionId` is the session token obtained in the previous step, and `targetUrl` is an optimized target address designed to reduce subsequent redirects. Then, a synchronization page is returned; SSO returns the front-end page `queryAndSetSessionId.html` used for session synchronization. This returned page is also blank, containing only JavaScript code, within which ` / sso / setSession` is executed. Finally, the session setting interface is called; this front-end page calls the SSO session setting interface ` / sso / setSession?sessionId=xxx`, passing in the session token.

[0076] S5. Query the corresponding anti-opening device reuse relationship data based on the incoming session token, compare it with the obtained session request data, establish a target browser session based on the comparison result, and redirect the synchronous session front-end page to the optimized target address for target application login.

[0077] Specifically, based on the incoming session token, the corresponding anti-tampering device reuse relationship data is queried and compared with the obtained session request data. Based on the comparison result, a target browser session is established, and the synchronous session front-end page is redirected to the optimized target address for target application login, including:

[0078] S51. Based on the incoming session token, query the corresponding anti-opening device reuse relationship data in the cache to obtain the queried anti-opening device reuse relationship data;

[0079] S52. Compare the queried anti-opening device reuse relationship data with the obtained session request data, and obtain the session identifier of the initial application in the queried anti-opening device reuse relationship data based on the comparison result.

[0080] Specifically, the session request data includes: the session request address and the session request device information.

[0081] Specifically, comparing the queried anti-opening device reuse relationship data with the obtained session request data includes:

[0082] The client address in the queried anti-opening device reuse relationship data is compared with the obtained session request address to obtain the address comparison result;

[0083] The client address in the queried anti-opening device reuse relationship data is compared with the obtained session request device information to obtain the device information comparison result;

[0084] The results of address comparison and device information comparison are integrated to obtain the comparison results of device consistency.

[0085] S53. Set the target browser's session credentials using the session identifier of the initial application, and establish a session for the target browser.

[0086] S54. Redirect the synchronous session front-end page to the optimized target address, and use single sign-on to process the target browser's authorization request based on the target browser's session credentials to complete the target application login.

[0087] Specifically, based on the target browser's session credentials, single sign-on is used to process the target browser's authorization request and complete the login for the target application, including:

[0088] The system identifies user session information based on the target browser's session credentials, and uses single sign-on to process the target browser's authorization request based on the identification results, thus completing the login for the target application.

[0089] Specifically, a session is established for browser B. SSO uses the incoming session token to look up the corresponding user session information and sets a cookie in the response, writing the sessionId to browser B. The token is then used to query the corresponding sessionId, IP address, and device information from Redis. This information is compared with the IP address (session request address) and device information (session request device information) from the previous request (session request data). If the device consistency comparison is successful, it is considered to be the same device, and a cookie (the target browser's session credential) is set in the response, writing the sessionId to browser B.

[0090] Specifically, optimize authorization redirection, that is, redirect the front-end page to the optimized target address targetUrl.

[0091] The specific content of targetUrl, for example:

[0092] https: / / uac.a.sit / sso / authorize / code?client_id=C19&redirect_uri=http%3A%2F%2Fwww.B.com.

[0093] Here, ` / authorize / code` is the interface used to obtain the authorization code in the standard SSO authentication process. In this step, SSO directly initiates the authorization code request on behalf of System B. Compared to the standard process where System B's address is redirected to SSO's ` / authorize / code` interface, this reduces one redirection and significantly improves the user experience.

[0094] Specifically, SSO achieves login-free access by using the cookie carried by browser B to identify valid user session information when processing browser B's authorization request. This allows users to bypass the login process and access system B from browser A to browser B without logging in. Since a sessionId has already been written to browser B, browser B's authorization request will include this sessionId. After SSO verifies its validity, it can retrieve the user session information stored in Redis using the sessionId.

[0095] Specifically, the process involves Session Token relay: In browser A, SSO generates a short-lived, one-time security token based on the verified sessionId. Inter-browser communication occurs when browser A's front-end page (JavaScript) launches the target browser B and passes a URL containing the token and the target address to browser B. Target browser session establishment occurs when browser B submits the token by accessing a dedicated synchronization page provided by SSO. After verifying the token's validity, SSO writes the original Session ID to browser B's cookie, thus establishing the same login session as the user in browser B. SSO's proactive authorization request delivery optimization reduces the number of redirects in cross-browser scenarios for the standard OAuth 2.0 authorization code process, significantly improving user experience and redirection efficiency. Specifically, the targetUrl parameter is optimized so that SSO pre-constructs the target system's (system B) OAuth 2.0 / authorize / code request URL (containing parameters such as client_id and redirect_uri) when generating the synchronization page URL, and passes it as the targetUrl to browser B. The SSO proxy authorization request, meaning that after browser B's session synchronization is successful, the front-end page is directly redirected to this pre-constructed targetUrl, which is the SSO / authorize / code interface. This skips the intermediate step in the standard process of first redirecting to system B, and then system B redirecting to SSO / authorize / code. It optimizes the two redirects that originally required browser B into one, reducing the number of redirects from the session synchronization page, system B, and SSO authorization page to just the session synchronization page and the SSO authorization page, thus eliminating one browser redirection.

[0096] Specifically, the security token transmission and verification mechanism securely and reliably transmits session credentials between untrusted browser environments. Token generation and binding involve SSO generating a unique, encrypted, and time-limited Session Token based on the currently verified user's sessionId upon receiving a browserSwitch request, and associating it with that session. Token usage is limited; the Session Token is used only for a single session synchronization operation, specifically through the ` / sso / setSession` interface, and becomes invalid once used or expired. Token verification, within the ` / sso / setSession` interface, strictly verifies the validity of the incoming Session Token, specifically checking its existence, expiration, and matching the bound session. Only after successful verification is the associated sessionId written to browser B's cookie.

[0097] Specifically, browser-type targeted startup means that, based on business rules, such as allowing system B to only access the target browser via browser B, the startup of the target browser is precisely controlled. The `browser` parameter specifies the target browser's identifier, for example, `browser=IE`, in the `browserSwitch` interface call. Front-end script execution means that the front-end page in browser A executes a specific script or command to launch the specified target browser based on the received `browser` parameter, for example, through a registry protocol or system command call.

[0098] Specifically, Single Sign-On (SSO) is an authentication mechanism that allows users to log in to multiple related but independent software systems using a single set of credentials, such as a username and password, without needing to authenticate separately in each system. Its core concept is that once a user logs in from one place, they can access all mutually trusted applications.

[0099] In summary, the browser switching and single sign-on (SSO) functions in this invention are implemented by the SSO system, offering advantages such as convenience, wide applicability, and no need for additional development. Compared to the existing technical solution one, this invention eliminates the need for users to manually copy links, switch browsers, or log in again. It automatically implements script-based browser switching and login-free functionality based on user session migration, significantly improving user convenience and enhancing the user experience. Compared to the existing technical solution two, this invention does not rely on browser plugins and does not require consideration of whether different browser versions support the installation and use of related plugins, thus offering wide applicability. Compared to the technical solution three, this invention does not require any code-level modifications to existing SSO systems. It only requires simply wrapping the target system address with an interface and replacing the original link. Specifically, the original link is replaced as follows:

[0100] The original address of system B was https: / / www.B.com. Now, we only need to change the address of system B to http: / / sso.com / browserSwitch?client_url=C19&url=https: / / www.B.com&browser=IE. This modification will be done by the SSO system, saving a significant amount of work on modifying other systems.

[0101] This invention addresses the pain point of traditional SSO's inability to share login status across browsers, achieving secure and seamless cross-browser login-free switching. It solves the problem of different browsers being unable to share data through cross-browser session synchronization, such as the inability to share sessions due to cookie isolation between browser A and browser B, thus enabling the transfer of user login status between different browsers.

[0102] In summary, by utilizing the above-mentioned technical solution of this invention, the present invention solves the pain point of traditional single sign-on (SSO) being unable to share login status across browsers by synchronizing the session front-end page, achieving secure and seamless cross-browser login-free switching. By solving the problem of different browsers being unable to share data through cross-browser session synchronization, it addresses the issue of session credential isolation between two browsers preventing session sharing, enabling the transfer of user login status between different browsers. This invention unifies browser switching and login-free functionality through SSO, offering high convenience, wide applicability, and requiring no additional development. Compared to existing solutions, users do not need to manually copy links or switch browsers, nor do they need to log in repeatedly; browser switching and session migration are automatically completed, improving user convenience and significantly enhancing the user experience. Compared to solutions relying on browser plugins, this invention does not rely on plugins, has strong compatibility, and is not limited by browser versions. Compared to solutions requiring code modification of the access system, this invention only needs to encapsulate the initial application link as a SSO redirect interface, centrally implemented by SSO, significantly reducing access costs, simplifying deployment processes, and possessing stronger scalability and practicality.

[0103] The above description is only a preferred embodiment of the present invention and is not intended to limit the present invention. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of the present invention should be included within the protection scope of the present invention.

Claims

1. A method for browser switching in conjunction with single sign-on, characterized by, The method comprises: S1, judging the user login state of the initial application, performing login authentication processing based on the user login state judgment result using single sign-on verification, obtaining the session identifier of the initial application, and writing the session identifier of the initial application into the session credential of the initial browser; S2, transmitting target application access parameters according to the click result of the target application link in the initial application, performing browser jump judgment based on the target application access parameters and the access request header data using single sign-on, and generating a session token according to the browser jump judgment result and the session identifier of the initial application; S3, generating anti-device multiplexing relationship data based on the session identifier of the initial application, the session token and the access request header data, generating a browser switching front-end page according to the target application access parameters and the session token as parameters of a script execution function; S4, starting the target browser using the script execution function and generating an optimized target address, generating a synchronous session front-end page using single sign-on according to the session token and the optimized target address, and calling the set session interface of single sign-on to the synchronous session front-end page to input the session token; S5, querying the corresponding anti-device multiplexing relationship data according to the input session token, comparing with the obtained session request data, establishing a target browser session according to the comparison result, and redirecting the synchronous session front-end page to the optimized target address for target application login.

2. The method of claim 1, wherein, The judgment of the user login state of the initial application comprises: Obtaining the session identifier of the user access request, and judging the user login state of the initial application according to the session identifier of the user access request to obtain the user login state judgment result.

3. The method of claim 1, wherein the method further comprises: The target application access parameters include: target application number, target browser type and target application access address.

4. The method of claim 3, wherein, According to the click result of the target application link in the initial application, the initial application calls the browser switching interface of single sign-on to transmit the target application access parameters; S22, based on the user agent of the access request header data, the initial browser type is obtained using single sign-on, the initial browser type is compared with the target browser type, and browser jump judgment is performed according to the comparison result to obtain the browser jump judgment result; S23, when the browser jump judgment result is jump, the session token is generated according to the session identifier of the initial application. S31, according to the access request header data, the client address is extracted using single sign-on, and the device information of the user agent in the access request header data is obtained; 5. The method of claim 3, wherein the browser switching method is combined with single sign-on. ​ ​ S32. Store the correspondence between the session token and the session identifier, client address and device information of the user agent of the initial application into the cache to obtain the anti-opening device reuse relationship data; S33. Generate a browser switching front-end page based on the target browser type, target application access address, and session token as parameters of the script execution function.

6. The method of claim 3, wherein the method further comprises: The step of launching the target browser and generating an optimized target address using a script execution function includes: By using the browser's script execution function to switch the front-end page, the session token and the target application access address are concatenated to obtain the optimized target address; Obtain the browser redirection hint based on the target browser type, and launch the target browser based on the result of obtaining the browser redirection hint.

7. The method of claim 1, wherein the method further comprises: The step of querying the corresponding anti-opening device reuse relationship data based on the input session token, comparing it with the obtained session request data, establishing a target browser session based on the comparison result, and redirecting the synchronous session front-end page to the optimized target address for target application login includes: S51. Based on the incoming session token, query the corresponding anti-opening device reuse relationship data in the cache to obtain the queried anti-opening device reuse relationship data; S52. Compare the queried anti-opening device reuse relationship data with the obtained session request data, and obtain the session identifier of the initial application in the queried anti-opening device reuse relationship data based on the comparison result. S53. Set the target browser's session credentials using the session identifier of the initial application, and establish a target browser session; S54. Redirect the synchronous session front-end page to the optimized target address, and use single sign-on to process the target browser's authorization request based on the target browser's session credentials to complete the target application login.

8. The method of claim 7, wherein, The session request data includes: session request address and session request device information.

9. The method of claim 8, wherein, The comparison of the queried anti-opening device reuse relationship data with the obtained session request data includes: The client address in the queried anti-opening device reuse relationship data is compared with the obtained session request address to obtain the address comparison result; The client address in the queried anti-opening device reuse relationship data is compared with the obtained session request device information to obtain the device information comparison result; The results of address comparison and device information comparison are integrated to obtain the comparison results of device consistency.

10. The method of claim 7, wherein the method further comprises: The step of processing the target browser's authorization request using single sign-on based on the target browser's session credentials to complete the target application login includes: The system identifies user session information based on the target browser's session credentials, and uses single sign-on to process the target browser's authorization request based on the identification results, thus completing the login for the target application.

Images