Website login method and system

Abstract

The invention discloses a website login method and system, and belongs to the technical field of Internet. The method comprises the following steps: a first server obtains an access request for a target website, locally determines an authorization code interface, and generates an authorization request; the first server side sends an authorization request to a second server side; the second server side generates an authorization response body according to the authorization request and sends the authorization response body to the first server side, and the first server side sends the authorization response body and the single sign-on interface address to the logged-in client side; the logged-in client generates an authentication request based on the authorization response body and the single sign-on interface address, and sends the authentication request to the second server through the browser; the second server side receives the authentication request and obtains a verification result, if the verification result is that verification is passed, a single sign-on session of the target website is generated, and the browser is redirected to the target website for single sign-on. According to the embodiment of the invention, single sign-on between the desktop application and the Web website can be realized.

Description

Technical Field

[0001] This application relates to the field of Internet technology, and in particular to a method and system for logging into a website. Background Technology

[0002] Single Sign-On (SSO) is an authentication mechanism that allows users to authenticate once (e.g., by entering their username and password once) across multiple related but independent application systems. After that, they can seamlessly access other trusted application systems that have integrated SSO functionality, without having to re-authenticate by entering their account and password for each application.

[0003] However, single sign-on solutions are currently mostly used in scenarios involving single sign-on between websites, while their application between desktop applications and websites is relatively rare. For desktop applications in operating systems, such as common desktop applications like chat software, when a link is clicked and a related website needs to be opened in a browser, the user is often required to re-enter their username and password to log in. This not only creates a cumbersome process for users and reduces efficiency, but also poses security risks such as password leakage during the process of repeatedly entering usernames and passwords.

[0004] Therefore, how to achieve single sign-on to a website through a desktop application and improve the efficiency of switching between desktop applications and websites has become an urgent technical problem to be solved. Summary of the Invention

[0005] The purpose of this application is to provide a website login method and system that can effectively realize single sign-on between desktop applications and websites, and improve the efficiency of switching between desktop applications and websites.

[0006] To achieve the above objectives, a first aspect of this application provides a website login method, including:

[0007] The first server obtains an access request for a target URL initiated by a logged-in client. The first server determines the authorization code interface from the local machine based on the access request and generates an authorization request based on the access request.

[0008] The first server calls the authorization code interface to send the authorization request to the second server; the second server is a different server from the first server.

[0009] The second server generates an authorization response body based on the authorization request and sends the authorization response body to the first server. The first server then sends the authorization response body and the single sign-on interface address to the logged-in client.

[0010] The logged-in client generates an authentication request based on the authorization response body and the single sign-on interface address, and sends the authentication request to the second server through the browser;

[0011] The second server receives the authentication request, parses the authentication request to obtain the verification result, and if the verification result is successful, it generates a single sign-on session for the target URL based on the successful verification result and redirects the browser to the target URL for single sign-on.

[0012] Compared with existing technologies, the URL login method provided in this application has the following advantages: First, a first server obtains the access request sent by a logged-in client to a target URL. Then, based on the access request, it determines the authorization code interface locally and generates an authorization request. Next, it calls the authorization code interface to send the authorization request to a second server, which is different from the first server. Upon receiving the authorization request, the second server generates an authorization response body and sends it back to the first server. The first server then transmits the authorization response body and the single sign-on interface address to the logged-in client. The logged-in client generates an authentication request based on this and sends it to the second server through its browser. The second server receives and parses the authentication request to obtain a verification result. If the verification passes, it generates a single sign-on session for the target URL based on this result, and then redirects the browser to the target URL for single sign-on. This application embodiment enables single sign-on between a logged-in client (i.e., desktop application) and a target website (i.e., website) through collaborative interaction between a first server and a second server. This allows users to conveniently access the target website in the logged-in client with only one verification operation, greatly improving the convenience of user login and avoiding the tedious verification process of repeatedly entering account passwords in different systems. On the other hand, this application embodiment can reduce the security risks caused by repeatedly entering account passwords and improve the security of the login process.

[0013] In some embodiments, the second server receives the authentication request, parses the authentication request to obtain a verification result, including:

[0014] The second server receives the authentication request, parses the authentication request, and obtains the authorization code, the client's Internet Protocol address, and the status code.

[0015] The second server verifies the authorization code, the client's Internet Protocol address, and the status code respectively, and obtains the verification results.

[0016] In some embodiments, the second server verifies the authorization code, the client's Internet Protocol address, and the status code respectively, and obtains the verification results, including:

[0017] If the authorization code, the client's Internet Protocol address, and the status code are all valid, then the verification result is "verification passed"; or,

[0018] If any of the authorization code, the client's Internet Protocol address, or the status code is invalid, the verification result is "verification failed," and the second server will redirect the browser to a "verification failed" message page.

[0019] In some embodiments, the step of sending the authorization response body and the single sign-on interface address from the first server to the logged-in client includes:

[0020] The first server determines the single sign-on interface address locally;

[0021] The first server sends the single sign-on interface address and the authorization response body to the logged-in client.

[0022] In some embodiments, the logged-in client generates an authentication request based on the authorization response body and the single sign-on interface address, and sends the authentication request to the second server through a browser, including:

[0023] The authorization response body includes an authorization code and a status code, and the logged-in client generates a request body based on the authorization code and the status code.

[0024] The logged-in client constructs the authentication request based on the request body and the single sign-on interface address;

[0025] The logged-in client opens a browser locally, accesses the single sign-on interface address through the browser, and sends the request body to the second server.

[0026] In some embodiments, before the first server obtains the access request for the target URL initiated by the logged-in client, the method further includes:

[0027] The user enters login information into the client, and the client sends the login information to the first server;

[0028] The first server receives the login information, verifies the user's identity based on the login information, and obtains a verification result. If the verification result is successful, the server switches the client's login status to "logged in" based on the successful verification result.

[0029] To achieve the above objectives, a second aspect of this application provides a website login system, the system including a logged-in client, a first server, a second server, a browser, and a target website; the logged-in client is communicatively connected to the first server, the first server is communicatively connected to the second server, the browser is communicatively connected to the second server, and the browser is communicatively connected to the target website;

[0030] The first server is used to obtain access requests for a target URL initiated by a logged-in client. The first server is also used to determine the authorization code interface from the local machine based on the access request and generate an authorization request based on the access request.

[0031] The first server is also used to call the authorization code interface to send the authorization request to the second server; the second server is a different server from the first server;

[0032] The second server is used to generate an authorization response body according to the authorization request, and send the authorization response body to the first server, and the first server sends the authorization response body and the single sign-on interface address to the logged-in client;

[0033] The logged-in client is used to generate an authentication request based on the authorization response body and the single sign-on interface address, and send the authentication request to the second server through a browser;

[0034] The second server is used to receive the authentication request, parse the authentication request to obtain the verification result, and if the verification result is successful, generate a single sign-on session for the target URL based on the successful verification result, and redirect the browser to the single sign-on session for the target URL.

[0035] In some embodiments, the logged-in client, the first server, the second server, the browser, and the target URL exchange data via the HTTPS communication protocol.

[0036] In some embodiments, the second server is a single sign-on server.

[0037] In some embodiments, the authorization response body generated by the second server is stored in the remote dictionary server of the second server. Attached Figure Description

[0038] Figure 1 This is a flowchart of a URL login method provided in an embodiment of this application;

[0039] Figure 2 This is a flowchart illustrating the client login status switching provided in an embodiment of this application;

[0040] Figure 3 yes Figure 1 A flowchart of step S104 in the process;

[0041] Figure 4 yes Figure 1 A flowchart of step S105 in the process;

[0042] Figure 5 This is another flowchart of the URL login method provided in the embodiments of this application;

[0043] Figure 6 This is a schematic diagram of the structure of the website login system provided in the embodiments of this application. Detailed Implementation

[0044] The technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those of ordinary skill in the art without creative effort are within the scope of protection of this application.

[0045] In the description of this application, it should be understood that the terms "center", "upper", "lower", "front", "rear", "left", "right", "vertical", "horizontal", "top", "bottom", "inner", "outer", etc., indicate the orientation or positional relationship based on the orientation or positional relationship shown in the accompanying drawings. They are only for the convenience of describing this application and simplifying the description, and do not indicate or imply that the device or element referred to must have a specific orientation, or be constructed and operated in a specific orientation. Therefore, they should not be construed as limitations on this application.

[0046] The terms "first" and "second" are used for descriptive purposes only and should not be construed as indicating or implying relative importance or implicitly specifying the number of technical features indicated. Therefore, a feature defined as "first" or "second" may explicitly or implicitly include one or more of that feature. In the description of this application, unless otherwise stated, "a plurality of" means two or more.

[0047] In the description of this application, it should be noted that, unless otherwise expressly specified and limited, the terms "installation," "connection," and "linking" should be interpreted broadly. For example, they can refer to a fixed connection, a detachable connection, or an integral connection; they can refer to a mechanical connection or an electrical connection; they can refer to a direct connection or an indirect connection through an intermediate medium; and they can refer to the internal connection between two components. Those skilled in the art can understand the specific meaning of the above terms in this application based on the specific circumstances.

[0048] Single Sign-On (SSO) is an authentication mechanism that allows users to authenticate once (e.g., by entering their username and password once) across multiple related but independent application systems. After that, they can seamlessly access other trusted application systems that have integrated SSO functionality, without having to re-authenticate by entering their account and password for each application.

[0049] However, single sign-on solutions are currently mostly used in scenarios involving single sign-on between websites, while their application between desktop applications and websites is relatively rare. For desktop applications in operating systems, such as common desktop applications like chat software, when a link is clicked and a related website needs to be opened in a browser, the user is often required to re-enter their username and password to log in. This not only creates a cumbersome process for users and reduces efficiency, but also poses security risks such as password leakage during the process of repeatedly entering usernames and passwords.

[0050] Therefore, how to achieve single sign-on to a website through a desktop application and improve the efficiency of switching between desktop applications and websites has become an urgent technical problem to be solved.

[0051] Please see Figure 1 , Figure 1 This is an optional flowchart of the URL login method provided in the embodiments of this application. Figure 1 The method may include, but is not limited to, steps S101 to S105.

[0052] Step S101: The first server obtains the access request for the target URL initiated by the logged-in client. The first server determines the authorization code interface from the local machine based on the access request and generates an authorization request based on the access request.

[0053] In step S102, the first server calls the authorization code interface to send an authorization request to the second server; the second server is a different server from the first server.

[0054] In step S103, the second server generates an authorization response body based on the authorization request and sends the authorization response body to the first server. The first server then sends the authorization response body and the single sign-on interface address to the logged-in client.

[0055] Step S104: The logged-in client generates an authentication request based on the authorization response body and the single sign-on interface address, and sends the authentication request to the second server through the browser;

[0056] In step S105, the second server receives the authentication request, parses the authentication request to obtain the verification result, and if the verification result is successful, it generates a single sign-on session for the target URL based on the successful verification result and redirects the browser to the target URL for single sign-on.

[0057] In steps S101 to S105 of this embodiment, the first server obtains the access request sent by the logged-in client to the target URL. Based on this access request, it determines the authorization code interface locally and generates an authorization request. Then, it calls the authorization code interface to send the authorization request to a different second server. Upon receiving the authorization request, the second server generates an authorization response body and sends it back to the first server. The first server then transmits the authorization response body and the single sign-on interface address to the logged-in client. The logged-in client generates an authentication request based on this and sends it to the second server via its browser. The second server receives and parses the authentication request to obtain a verification result. If the verification passes, it generates a single sign-on session for the target URL based on this result and redirects the browser to the target URL for single sign-on. This application embodiment enables single sign-on between a logged-in client (i.e., desktop application) and a target website (i.e., website) through collaborative interaction between a first server and a second server. This allows users to conveniently access the target website in the logged-in client with only one verification operation, greatly improving the convenience of user login and avoiding the tedious verification process of repeatedly entering account passwords in different systems. On the other hand, this application embodiment can reduce the security risks caused by repeatedly entering account passwords and improve the security of the login process.

[0058] Please see Figure 2 In some embodiments, prior to step S101, the process of switching the client login state may include, but is not limited to, steps S201 to S202:

[0059] In step S201, the user enters login information into the client, and the client sends the login information to the first server.

[0060] In step S202, the first server receives the login information, verifies the user's identity based on the login information, and obtains the verification result. If the verification result is successful, the client's login status is switched to "logged in" based on the successful verification result.

[0061] In step S201 of some embodiments, the client can be a software program installed on a user terminal device (such as a computer, smartphone, tablet, etc.), which allows the user to conveniently operate the corresponding online service on the local device. The client is the interface for interaction between the user and the backend server, responsible for receiving the user's operation instructions, sending relevant data to the backend server, and displaying the processing results returned by the backend server to the user. The login information can be a username, password, and possibly a device identifier. The login information is a unique identifier for the user. The first server can be the backend server corresponding to the client. The first server can receive various requests from the client, including login requests corresponding to the login information here, and then judge the user's identity based on its own stored data (such as a user registration information database) and set verification rules, and perform corresponding operations based on the verification results, such as allowing login, denying login, etc. The first server can consist of one or more physical servers, deployed according to the business volume and system scalability requirements, without specific limitations here.

[0062] In step S202 of some embodiments, the verification result can be the conclusion reached by the first server after authenticating the user based on the login information. This indicates whether the login information entered by the user meets the requirements for a legitimate user set by the system. Only when the verification result is successful is the user allowed to further use the relevant functions and services provided by the system. The first server detects the corresponding port through the network, receives the login information sent by the client, parses it, and extracts the username and password contained therein. Then, the server matches the extracted username with its stored user registration information database to check if a corresponding record exists. If a corresponding username record is found, the server then compares whether the password of the user stored in the database matches the password sent by the client. The verification result usually has two possibilities: successful verification and unsuccessful verification. When the first server determines that the verification result is successful, it means that the user's legitimate identity has been confirmed. At this time, the client's login status needs to be updated and switched to the logged-in state, that is, the client is now a logged-in client.

[0063] In step S101 of some embodiments, the logged-in client can be a client that has been authenticated by the server and confirmed as a legitimate user, possessing the authority to interact with the first server, request access to relevant resources, and obtain corresponding services or data based on its login status in subsequent operations. The target URL can be the address of a specific network resource that the user expects to access through the logged-in client, and it follows the format specification of a Uniform Resource Locator (URL). Different target URLs correspond to different service content or application scenarios. The access request can be a request sent by the logged-in client to the first server according to the corresponding network protocol (such as HTTPS), containing information related to the target URL. Specifically, the access request includes the target URL (surl), username (userName), client IP address, device ID (deviceId), and authentication token (token).

[0064] It should be noted that the authorization code interface is determined by the first server from its local configuration. The authorization code interface is a program interface for authorization-related interactions between the first and second servers. The first server sends an authorization request to the second server by calling this interface, and the second server receives the request and performs corresponding authorization-related processing and responses based on this interface. The authorization code interface specifies the format and parameter requirements for data transmission between the two parties in the authorization process. The authorization request can be a data packet generated by extracting necessary parameters from the access request and other relevant data, according to a specific data format (such as JSON, XML, etc.), used to request authorization from the second server. Specifically, the authorization request includes the username (userName), client IP address, device ID (deviceId), authentication token (token), and whether to obtain the status code (isNeedState).

[0065] Understandably, before generating an authorization request, the first server can re-verify the identity of the logged-in client based on the preset authentication method and access request, in order to confirm whether the logged-in user is the same person who issued the current access request.

[0066] In step S102 of some embodiments, the second server can be a Single Sign-On (SSO) server, which is a backend component that implements the SSO mechanism. Sending an authorization request to the second server by calling the authorization code interface can be done using the POST method, via HTTPS protocol, by placing the parameters in JSON format in the request body, and sending it to the authorization code interface path corresponding to the specified second server address.

[0067] It should be noted that the authorization code interface uses the POST method to make requests, and its encoding format is UTF-8. Please refer to Table 1 for details. Table 1 shows the processing rules for the request parameters of the authorization code interface provided in this application embodiment.

[0068]

[0069] Table 1

[0070] Among them, the appName and type parameters can be transmitted directly as basic parameters, while the data parameter requires that parameters such as surl, userName, and deviceId be URL encoded in UTF-8 and then concatenated in a specific format: "surl="+URLEncoder.encode(surl,"UTF-8")+"&userName="+URLEncoder.encode(userName,"UTF-8")+"&IP="+IP+"&deviceId="+URLEncoder.encode(deviceId,"UTF-8")+"&token="+"123456"+"&isNeedState=true". Next, a digest is generated based on the concatenated string using the specified MD5 digest algorithm. Then, the concatenated string is encoded using BASE64 and UTF8, and an encrypted string is generated using the DES encryption algorithm (or other symmetric encryption algorithms, such as AES). The digest and encrypted string are then combined into a new data parameter: data = digest & encrypted string (strictly following the format requirement of digest first, encrypted string last). Finally, the three parameters, appName, type, and the processed data, are submitted to the single sign-on interface via POST.

[0071] Regarding the returned results, the response body returned by the single sign-on interface is fully encrypted. It is divided into two parts, digest information and encrypted string, by "&". The encrypted string must be decrypted by DES and decoded by UTF8 and BASE64 to obtain the plaintext response content. Furthermore, the data parameter will only exist in the response content when the response code is 0.

[0072] In step S103 of some embodiments, the authorization response body is a response data packet generated by the second server in response to the authorization request sent by the first server. The authorization response body includes an authorization code authCode and a status code state (if the isNeedState field is true) that are bound to surl, userName, IP, state, etc. Both the authorization code authCode and the status code state are unique.

[0073] It should be noted that the first server sends the authorization response body and the single sign-on interface address to the logged-in client, including the first server determining the single sign-on interface address locally and sending the single sign-on interface address and the authorization response body to the logged-in client.

[0074] It should be noted that the single sign-on interface address (i.e., the CS2BS single sign-on interface address cbUrl) is determined by the first server from its local configuration. The local configuration is a set of configuration information that is pre-set and stored within the first server, and it covers a wide range of client-related settings.

[0075] In step S104 of some embodiments, the single sign-on interface is the SSO service interface, and the single sign-on interface address is the interface address for accessing the SSO service, i.e., the CS2BS single sign-on interface address cbUrl. The authorization response body includes an authorization code and a status code.

[0076] It should be noted that the single sign-on interface uses the POST method to make requests, and its encoding format is UTF-8. Please refer to Table 2 for details. Table 2 shows the processing rules for the request parameters of the single sign-on interface provided in this application embodiment.

[0077]

[0078] Table 2

[0079] When initiating an authentication request to the Single Sign-On (SSO) interface, the authentication request parameters follow specific processing rules: the appName parameter, as a basic parameter, can be transmitted directly. For the data parameter, the authCode and state must first be concatenated to obtain the concatenated string ("authCode=" + authCode + "state="xxx). Then, a digest is generated using the specified MD5 hash algorithm. This concatenated string is then encoded using BASE64 and UTF8, and finally encrypted using the DES encryption algorithm (or other symmetric encryption algorithms such as AES) to generate an encrypted string. This encrypted string is then combined according to the strict format requirement of "data = digest information & encrypted string" to form a new parameter. Finally, the appName and data parameters are submitted to the SSO interface via POST. Regarding the returned result, since the request is initiated on the user's browser and responds via page redirection, the response code is always 302. However, depending on the request result, the SSO server will redirect to different addresses.

[0080] Please see Figure 3 In some embodiments, step S104 may include, but is not limited to, steps S301 to S303:

[0081] Step S301: The logged-in client generates a request body based on the authorization code and status code;

[0082] Step S302: The logged-in client constructs an authentication request based on the request body and the single sign-on interface address;

[0083] Step S303: The logged-in client opens a browser on its local machine, accesses the single sign-on interface address through the browser, and sends a request body to the second server.

[0084] In step S301 of some embodiments, the request body is a data packet formed by the logged-in client organizing and encapsulating authorization codes and status codes in a specific format, such as the data parameter in Table 2 above.

[0085] In step S302 of some embodiments, the authentication request can be a POST request constructed by the logged-in client using the single sign-on interface address as the target address and based on the interface requirements corresponding to the single sign-on interface address and the generated request body.

[0086] In step S303 of some embodiments, the browser is a software application running on the user terminal device, used to parse webpage code, display webpage content, and send requests to and receive responses from the second server. After generating and constructing the authentication request, the logged-in client opens a browser locally, accesses the single sign-on interface address cbUrl through the browser, and sends the aforementioned POST request according to the network communication protocol (HTTPS) agreed between the browser and the second server.

[0087] In step S105 of some embodiments, the verification result is the conclusion reached by the second server after verifying the authentication request sent by the client. It is used to determine whether the logged-in client has legitimate single sign-on (SSO) qualifications. Only when the verification result is successful can subsequent operations such as generating a SSO session and redirection proceed, thus implementing the SSO function. A SSO session is a session mechanism created by the second server for the user to ensure that the user can conveniently and securely access relevant resources at the target website within a certain time frame and under authorized conditions, without needing to repeatedly log in.

[0088] Please see Figure 4 In some embodiments, step S105 may include, but is not limited to, steps S401 to S402:

[0089] Step S401: The second server receives the authentication request, parses the authentication request, and obtains the authorization code, the client's Internet Protocol address, and the status code.

[0090] In step S402, the second server verifies the authorization code, the client's Internet Protocol address, and the status code respectively, and obtains the verification results.

[0091] In step S401 of some embodiments, the client's Internet Protocol address is the aforementioned IP address. The server will use appropriate parsing tools or libraries (such as JSON parsing libraries like Jackson or Gson in a Java development environment to parse JSON formatted request data) to extract the authorization code, client Internet Protocol address, and status code from the authentication request.

[0092] In step S402 of some embodiments, when the authorization code is generated, it is stored in the remote dictionary server Redis on the SSO server, with a validity period of 1 minute. Redis is primarily memory-based, with extremely fast data read and write speeds, enabling it to respond to queries and other operations in a short time. Storing the authorization code in Redis on the SSO server means that when it is necessary to verify the validity of the authorization code later, the relevant information can be quickly retrieved from Redis for comparison. When a user initiates a single sign-on interface request from a desktop application to a website, the system will prioritize querying Redis to quickly verify the validity of the authorization code. Once the authorization code is successfully used in the single sign-on process, that is, it has passed all verification steps and completed the single sign-on operation, in order to fully record the usage of the authorization code and for subsequent traceability, the detailed information of the authorization code (such as the value of the authorization code itself, generation time, usage time, corresponding user account, target URL accessed, etc.) will be written to the authorization code table in the database. At the same time, the status of the record will be clearly marked as "used". Both the generation and usage processes of the authorization code need to record detailed log information, which is of great significance for system troubleshooting. By using asynchronous writing to the database log table, the efficiency of the main process of authorization code generation and use can be avoided due to log recording operations.

[0093] The second server verifies the authorization code, the client's Internet Protocol address, and the status code, and obtains the verification results, which can include the following two cases:

[0094] Scenario 1: If the authorization code, client internet protocol address, and status code are all valid, the verification result is "verification passed"; or,

[0095] Scenario 2: If any of the authorization code, client internet protocol address, or status code is invalid, the verification result will be "verification failed," and the second server will redirect the browser to the verification failure message page.

[0096] In scenario one, the second server compares the authorization code, client internet address, and status code with the previously generated and recorded authorization code (authCode) and status code (state) bound to surl, userName, IP, and state. In some embodiments, if the authorization code, client internet address, and status code are all valid, the verification result is successful. In other embodiments, it first checks if the authorization code is valid. If the authorization code is valid, the second server checks if the status code matches the state. If the status codes match, the verification passes. If there is no status code, the client internet address and IP are checked. If the client internet address and IP match, the verification passes.

[0097] For scenario two, if the authorization code does not exist or has expired, the browser will be redirected to an invalid authorization code page. Further, it will be checked whether the status code matches the state. If they do not match, the verification result is verification failed, and the second server will redirect the browser to a verification failed page. Further, if there is no status code, it will be checked whether the client's internet protocol address in the authentication request matches the IP address bound in the authCode. If they do not match, the verification result is verification failed, and the second server will redirect the browser to a verification failed page.

[0098] Please see Figure 5 This application provides another flowchart of a website login method, including the following steps:

[0099] Step S501: The user clicks the website address surl on the desktop application PC, for example: oa.abc.com;

[0100] In step S502, the desktop application PC client encrypts and submits the target address surl and user information to the desktop application server; the parameters include: surl, userName, IP, deviceId, token, etc.

[0101] Step S503: The desktop application server verifies the identity information transmitted from the desktop application PC client;

[0102] Step S504: The desktop application server calls the CS2BS authorization code interface of the SSO server to request an authorization code; the parameters include: surl, userName, IP, deviceId, token, isNeedState, etc.

[0103] In step S505, after receiving the parameters from step S504, the SSO server generates a one-time authorization code authCode. If isNeedState is true (i.e., a status code is required), a unique status code state is also generated. The authorization code is bound to surl, userName, IP, state, etc., and then the authorization code and status code are returned to the desktop application server.

[0104] Step S506: The desktop application server receives the authorization code authCode and status code state returned by the SSO server.

[0105] Step S507: The desktop application server reads the SSO system CS2BS single sign-on interface address cbUrl from the configuration;

[0106] In step S508, the desktop application server encrypts the received authorization code authCode and status code state, assembles the encryption result together with appName into a request body string, and then returns it to the desktop application PC along with cbUrl.

[0107] Step S509: The desktop application PC client uses the received cbUrl as the target address and parameters such as authCode and state as the request body to encrypt and assemble a POST request.

[0108] Step S510: Open a browser on the desktop application PC, initiate a POST request, and access cbUrl;

[0109] Step S511: The browser sends a POST request to the SSO server.

[0110] In step S512, after the SSO server receives a request from the browser, it retrieves the authCode (authorization code), client IP (Internet Protocol address), and state (status code). Next, the SSO server first checks the validity of the authCode. If the authCode is missing or expired, the browser is redirected to a page displaying an invalid authorization code. If the authCode is valid, the SSO server uses it to further query user information, retrieving the state and the IP associated with the authCode. During this process, the server prioritizes checking if the state matches; if the states match, the IP is not checked. IP checks only occur when no state is available. Subsequently, the server compares the IP in the request with the response content. If they don't match, the verification fails. If they match, the SSO server generates an SSO login session based on the retrieved user information, updates the corresponding authorization code to a used state, and finally redirects the browser to the target address surl.

[0111] Step S513: The SSO server returns the website address to the browser;

[0112] Step S514: The browser accesses the website address surl;

[0113] Step S515, Single Sign-On for Web Site;

[0114] Step S516: Return the website content to the browser;

[0115] Step S517: The browser displays the website content to the user.

[0116] This application's embodiments achieve convenient and secure single sign-on functionality through a complete and rigorous process between the desktop application and the website. After initiating an operation on the desktop application, users can seamlessly access website content using authorization codes and other verification mechanisms, avoiding the tediousness of repeated logins while ensuring the accuracy of user authentication and the security of information exchange during the access process.

[0117] Currently, single sign-on (SSO) solutions are mostly used between websites, with fewer applications between desktop applications and websites. This application's embodiment effectively addresses this shortcoming. In terms of security, end-to-end encryption is employed. User information is encrypted from the desktop application PC to the desktop application server for authorization code encryption, effectively preventing theft and tampering during transmission. Furthermore, the strict authorization code and IP verification mechanism, utilizing the one-time use of the authorization code and its IP-bound verification characteristics, reduces the risk of unauthorized access and enhances system security. Regarding system integration flexibility, the desktop application architecture facilitates the transmission of information and authorization codes, enabling integration with internal enterprise desktop applications. It also offers high customizability, with clear parameter transmission and processing at each step, allowing for flexible parameter adjustments based on different scenarios. In terms of user experience, the process from initiating a request from the desktop application PC to browser SSO is seamless, requiring minimal manual input from the user. Regarding cross-platform compatibility, based on standard network requests and interacting via browser POST requests, it exhibits good compatibility across different browsers and operating systems, making it easy to deploy and use.

[0118] Please see Figure 6 This application also provides a website login system that can implement the above-described website login method. The system includes a logged-in client 601, a first server 602, a second server 603, a browser 604, and a target website 605. The logged-in client 601 is communicatively connected to the first server 602, the first server 602 is communicatively connected to the second server 603, the browser 604 is communicatively connected to the second server 603, and the browser 604 is communicatively connected to the target website 605.

[0119] The first server 602 is used to obtain the access request for the target URL 605 initiated by the logged-in client 601. The first server 602 is also used to determine the authorization code interface from the local machine according to the access request and generate an authorization request based on the access request.

[0120] The first server 602 is also used to call the authorization code interface to send an authorization request to the second server 603; the second server 603 and the first server 602 are different servers;

[0121] The second server 603 is used to generate an authorization response body according to the authorization request, and send the authorization response body to the first server 602. The first server 602 then sends the authorization response body and the single sign-on interface address to the logged-in client 601.

[0122] The logged-in client 601 is used to generate an authentication request based on the authorization response body and the single sign-on interface address, and sends the authentication request to the second server 603 through the browser 604.

[0123] The second server 603 is used to receive authentication requests, parse the authentication requests to obtain the verification results, and if the verification results are successful, generate a single sign-on session for the target URL 605 based on the successful verification results, and redirect the browser 604 to the target URL 605 single sign-on.

[0124] The specific implementation method of this website login system is basically the same as the specific implementation method of the above-mentioned website login method, and will not be described again here.

[0125] It should be noted that the logged-in client 601, the first server 602, the second server 603, the browser 604, and the target website 605 exchange data via the HTTPS communication protocol. The second server 603 is a single sign-on server. The authorization response body generated by the second server 603 is stored in the remote dictionary server of the second server 603.

[0126] Those skilled in the art will understand that all or part of the processes in the above embodiments can be implemented by a computer program instructing related hardware. The program can be stored in a computer-readable storage medium, and when executed, it can include the processes of the embodiments of the above methods. The storage medium can be a magnetic disk, optical disk, read-only memory (ROM), or random access memory (RAM), etc.

[0127] The above description is the preferred embodiment of this application. It should be noted that for those skilled in the art, several improvements and modifications can be made without departing from the principle of this application, and these improvements and modifications are also considered to be within the scope of protection of this application.

Claims

1. A method for logging into a website, characterized in that, include: The first server obtains an access request for a target URL initiated by a logged-in client. The first server determines the authorization code interface from the local machine based on the access request and generates an authorization request based on the access request. The first server calls the authorization code interface to send the authorization request to the second server; The second server is a different server from the first server; The second server generates an authorization response body based on the authorization request and sends the authorization response body to the first server. The first server then sends the authorization response body and the single sign-on interface address to the logged-in client. The logged-in client generates an authentication request based on the authorization response body and the single sign-on interface address, and sends the authentication request to the second server through the browser; The second server receives the authentication request, parses the authentication request to obtain the verification result, and if the verification result is successful, it generates a single sign-on session for the target URL based on the successful verification result and redirects the browser to the target URL for single sign-on.

2. The URL login method as described in claim 1, characterized in that, The second server receives the authentication request, parses the authentication request to obtain the verification result, including: The second server receives the authentication request, parses the authentication request, and obtains the authorization code, the client's Internet Protocol address, and the status code. The second server verifies the authorization code, the client's Internet Protocol address, and the status code respectively, and obtains the verification results.

3. The website login method as described in claim 2, characterized in that, The second server verifies the authorization code, the client's Internet Protocol address, and the status code respectively, and obtains the verification results, including: If the authorization code, the client's Internet Protocol address, and the status code are all valid, then the verification result is "verification passed"; or, If any of the authorization code, the client's Internet Protocol address, or the status code is invalid, the verification result is "verification failed," and the second server will redirect the browser to a "verification failed" message page.

4. The URL login method as described in claim 1, characterized in that, The step of sending the authorization response body and the single sign-on interface address from the first server to the logged-in client includes: The first server determines the single sign-on interface address locally; The first server sends the single sign-on interface address and the authorization response body to the logged-in client.

5. The URL login method as described in claim 4, characterized in that, The logged-in client generates an authentication request based on the authorization response body and the single sign-on interface address, and sends the authentication request to the second server through a browser, including: The authorization response body includes an authorization code and a status code, and the logged-in client generates a request body based on the authorization code and the status code. The logged-in client constructs the authentication request based on the request body and the single sign-on interface address; The logged-in client opens a browser locally, accesses the single sign-on interface address through the browser, and sends the request body to the second server.

6. The website login method as described in claim 1, characterized in that, Before the first server receives the access request for the target URL initiated by the logged-in client, the method further includes: The user enters login information into the client, and the client sends the login information to the first server; The first server receives the login information, verifies the user's identity based on the login information, and obtains a verification result. If the verification result is successful, the server switches the client's login status to "logged in" based on the successful verification result.

7. A website login system, characterized in that, The system includes a logged-in client, a first server, a second server, a browser, and a target URL; the logged-in client is communicatively connected to the first server, the first server is communicatively connected to the second server, the browser is communicatively connected to the second server, and the browser is communicatively connected to the target URL. The first server is used to obtain access requests for a target URL initiated by a logged-in client. The first server is also used to determine the authorization code interface from the local machine based on the access request and generate an authorization request based on the access request. The first server is also used to call the authorization code interface to send the authorization request to the second server; The second server is a different server from the first server; The second server is used to generate an authorization response body according to the authorization request, and send the authorization response body to the first server, and the first server sends the authorization response body and the single sign-on interface address to the logged-in client; The logged-in client is used to generate an authentication request based on the authorization response body and the single sign-on interface address, and send the authentication request to the second server through a browser; The second server is used to receive the authentication request, parse the authentication request to obtain the verification result, and if the verification result is successful, generate a single sign-on session for the target URL based on the successful verification result, and redirect the browser to the single sign-on session for the target URL.

8. The website login system as described in claim 7, characterized in that, The logged-in client, the first server, the second server, the browser, and the target URL exchange data via the HTTPS communication protocol.

9. The website login system as described in claim 7, characterized in that, The second server is a single sign-on server.

10. The website login system as described in claim 9, characterized in that, The authorization response body generated by the second server is stored in the remote dictionary server of the second server.

Images