An authorized login method, device and mobile terminal

Abstract

Embodiments of the present application disclose a method and device for authorized login. In the method, in an authorized login process, an authorized credential issued by a service provider end is directly sent to a background server of an H5 page, so that the authorized credential is invisible to the H5 page, thereby greatly reducing the possibility of an attacker obtaining the authorized credential by forging the H5 page, and reducing the risk of user login information leakage in the H5 page application authorized login process. The device has the same beneficial effects as described above.

Description

Technical Field

[0001] This invention relates to the field of computer technology, and in particular to an authorization login method and apparatus. Background Technology

[0002] Currently, numerous H5 web applications have been integrated into large mobile applications (hereinafter referred to as vendor Apps). These H5 applications authenticate end-users' identities through the authorization login service provided by the vendor Apps, without requiring additional account passwords. In such authorization login services, vendor Apps mostly use the common OAuth 2.0 protocol and have made some degree of adaptation. However, the original design goal of the OAuth 2.0 protocol was to serve user authorization services on PC web pages. Therefore, the adaptations made by vendors may violate the original security design of the protocol and introduce the risk of user account information leakage. Summary of the Invention

[0003] One or more embodiments of this specification provide an authorized login method and apparatus that can avoid the problem of H5 page user information leakage during the process of a mobile terminal logging into an H5 page in a front-end APP through the login status of the front-end APP.

[0004] According to the first aspect, an authorization login method is provided, applicable to service provider terminals, the method comprising:

[0005] When a user logs into the front-end APP of the service provider, in response to the authorization request sent by the H5 page in the front-end APP, an authorization credential is sent to the back-end server of the H5 page.

[0006] In response to the token request sent by the backend server carrying the authorization credentials, a token is issued to the backend server;

[0007] In response to the user login information retrieval request carrying the token sent by the backend server, the user login information of the frontend APP is sent to the backend server so that the backend server can complete the login on the H5 page based on the user login information.

[0008] As an optional implementation of the method described in the first aspect, the method further includes:

[0009] In response to the login on the H5 page, the front-end APP saves the user login status cookie sent by the back-end server; and

[0010] In response to the data access request sent by the H5 page, the front-end APP sends the data access request and the user login status cookie to the back-end server, and sends the response data returned by the back-end server to the H5 page.

[0011] As an optional implementation of the method described in the first aspect, the following steps are performed before issuing the authorization credentials to the backend server:

[0012] Based on the authorization request, extract the domain name information of the H5 page;

[0013] Based on the identifier carried in the authorization request, obtain the callback address submitted by the backend server when registering with the service provider;

[0014] Based on the consistency between the domain name information and the callback address, it is determined whether the H5 page is legitimate.

[0015] According to the second aspect, an authorization login method is provided, applicable to mobile terminals, wherein the mobile terminal has a front-end APP provided by a service provider installed, and the front-end APP embeds an H5 page; the method includes:

[0016] Log in to the front-end APP and initiate an authorization request through the H5 page;

[0017] Obtain the authorization credentials returned by the service provider for the authorization request, and send the authorization credentials to the backend server of the H5 page so that the backend server can request a token from the service provider, obtain the user login information of the frontend APP based on the token, and complete the login on the H5 page based on the user login information.

[0018] As an optional implementation of the method described in the second aspect, the method further includes:

[0019] After logging into the H5 page, the front-end APP caches the user login status cookie returned by the back-end server.

[0020] When the H5 page sends a data retrieval request to the service provider to access the backend server, the frontend APP sends the data retrieval request and the user login status cookie to the backend server together, and sends the response data returned by the backend server to the H5 page.

[0021] According to a third aspect, an authorization device is provided, including a front-end APP and an authorization server, wherein an H5 page is embedded in the front-end APP;

[0022] The front-end APP, when logged in, responds to the authorization request sent by the H5 page, requests authorization credentials from the authorization server, and returns the authorization credentials to the H5 page;

[0023] The authorization server is used to generate the authorization credential in response to the front-end APP's request for the authorization credential and send it to the front-end APP; and to issue a token to the back-end server in response to the token application request carrying the authorization credential sent by the back-end server of the H5 page.

[0024] As an optional implementation of the device described in the third aspect, the front-end APP is further configured to extract the domain name information of the H5 webpage based on the authorization request, and send the domain name information and the identifier carried in the authorization request to the authorization server together.

[0025] Specifically, before generating the authorization credentials, the authorization server also verifies the legitimacy of the H5 page, including:

[0026] Based on the identifier carried in the authorization request, obtain the callback address submitted by the backend server during registration;

[0027] Based on the consistency between the domain name information extracted by the front-end APP and the callback address, it is determined whether the H5 page is legitimate.

[0028] As an optional implementation of the apparatus described in the third aspect, the front-end APP is further configured to cache the user login status cookie sent by the back-end server in response to the login of the H5 page; and when receiving a data access request sent by the H5 page, send the data access request and the user login status cookie together to the back-end server, and send the response data returned by the back-end server to the H5 page.

[0029] According to the fourth aspect, a mobile terminal is provided, which has a front-end APP provided by a service provider installed, wherein an H5 page is embedded in the front-end APP; the mobile terminal logs into the H5 page based on the login status of the front-end APP, specifically including:

[0030] Initiate an authorization request through the H5 page;

[0031] The authorization request is sent to the authorization server of the service provider through the front-end APP;

[0032] The front-end APP obtains the authorization credentials returned by the authorization server for the authorization request, and sends the authorization credentials to the back-end server of the H5 page, so that the back-end server can request a token from the authorization server, obtain the user login information of the front-end APP based on the token, and complete the login on the H5 page based on the user login information.

[0033] As an optional implementation of the fourth aspect, the mobile terminal accesses the backend server in the following manner after logging into the H5 page, specifically including:

[0034] After logging into the H5 page, the front-end APP caches the user login status cookie returned by the back-end server.

[0035] The H5 page initiates a data retrieval request to access the backend server.

[0036] The front-end APP sends the data acquisition request and the user login status cookie to the back-end server, and sends the response data returned by the back-end server to the H5 page.

[0037] The beneficial effect of the authorization login method described in one or more embodiments of this specification is that, in the authorization login process based on the OAuth2.0 protocol, the authorization credentials issued by the service provider are directly sent to the backend server of the H5 page, so that the authorization credentials are not visible to the H5 webpage, thereby greatly reducing the possibility of attackers obtaining authorization credentials by forging the H5 webpage and reducing the risk of user login information leakage during the authorization login process of H5 webpage applications.

[0038] The apparatus described in the embodiments of this specification also has the above-mentioned beneficial effects. Attached Figure Description

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

[0040] Figure 1 This specification provides a structural diagram of an authorized login system provided in one or more embodiments.

[0041] Figure 2 A flowchart illustrating an authorization login method applicable to a service provider, provided for one or more embodiments of this specification;

[0042] Figure 3 This is a flowchart illustrating an authorization login method for a mobile terminal provided in one or more embodiments of this specification.

[0043] Figure 4 This is a schematic diagram illustrating the workflow of the authorization login method provided in one or more embodiments of this specification in one implementation scenario. Detailed Implementation

[0044] Currently, many H5 web applications have been integrated into large mobile applications. These H5 web applications authenticate end-users through the authorization login service provided by the large mobile applications, without requiring additional account passwords. In such authorization login services, large mobile applications mostly use the common OAuth 2.0 protocol and have made some degree of adaptation. However, the original design goal of the OAuth 2.0 protocol was to serve user authorization services for PC web pages. Therefore, the adaptation made by the vendors of large mobile applications may violate the original security design of the protocol and introduce new risks.

[0045] Taking the example of a user logging into a merchant server through the authorization login function provided by the vendor's server, this illustrates the application principle of the OAuth2.0 protocol on a PC. The following describes the authorization login process based on the OAuth2.0 protocol on a PC:

[0046] (101) When a user accesses the client (merchant server), the browser initiates an authorization initialization request to the client.

[0047] (102) The client (merchant server) sends an authorization request to the user (browser) (that is, a 302 redirect request in OAuth 2.0). The authorization request contains the callback address specified by the client and the client's identifier.

[0048] (103) The browser redirects to the authorization page, which is provided by the authorization server. The authorization page provides the user with the relevant information submitted by the merchant server to the authorization server, as well as the scope of access permissions that the merchant server can obtain after authorization. The user authorizes the client through the authorization page, that is, sends the authorization request to the authorization server (vendor server).

[0049] (104) After receiving the authorization request from the user (browser), the authorization server (vendor server) verifies whether the callback address redirect_url in the authorization request is consistent with the callback address submitted by the client during registration, and verifies whether the identifier appid in the authorization request is consistent with the identifier distributed by the vendor server during client registration. If both the callback address redirect_url and the identifier appid are successfully verified, the authorization server (vendor server) generates the authorization credential code.

[0050] (105) The authorization server (vendor server) returns the authorization credential code to the user (browser).

[0051] (106) The user (browser) sends the authorization credential code to the client (merchant server) based on the redirect_url in the authorization request.

[0052] (107) The client (merchant server) uses the authorization credentials to request an access token from the authorization server (vendor server).

[0053] (108) The client (merchant server) uses the access_token token to request resources from the resource server.

[0054] (109) After the resource server verifies that the token is correct, it returns the corresponding resources to the client (merchant server).

[0055] As can be seen from the above process, in the authorization login process based on the OAuth2.0 protocol on the PC, steps (105) to (106) are atomic operations that occur on the browser side and cannot be interfered with or interrupted by external factors. Therefore, it can be guaranteed that the authorization credential code can be transmitted to the legitimate client.

[0056] However, when the OAuth 2.0 protocol is applied to mobile clients, the entire authentication process becomes the following steps:

[0057] (201) Users initiate an authorization login request to the service provider through an H5 page; the service provider consists of the manufacturer's APP and the manufacturer's server.

[0058] (202) The authorization login request initiated by the user is received by the manufacturer's APP. The manufacturer's APP extracts the current domain name current_url based on the authorization login request, and determines the identity of the H5 page based on the extracted domain name current_url and the third-party application identifier appid in the authorization login request.

[0059] (203) After the manufacturer's APP confirms that the H5 page is legitimate, it sends an authorization request (including appid and current_url) to the manufacturer's server.

[0060] (204) The vendor server verifies whether the appid and current_url in the authorization request are consistent with the relevant information submitted when the third-party application is registered. After the verification is successful, the authorization credential code is generated.

[0061] (205) The vendor server sends the authorization credential code to the vendor APP.

[0062] (206) The manufacturer's APP sends the authorization certificate code to the H5 page.

[0063] (207) Users send the authorization credential code to a third-party application via an H5 page.

[0064] (208) The third-party application uses the authorization credential code to request an access token from the vendor's server.

[0065] (209) After the vendor server verifies the access_token, it returns the user login information to the third-party application.

[0066] (210) The third-party application verifies the obtained user login information with the locally stored user login information. After the verification is successful, the login is completed.

[0067] (211) The third-party application returns the user's login status cookie to the H5 page.

[0068] In the above process, the authorization credential code generated by the vendor's server is first sent to the requesting H5 page (steps 205 to 206), rather than directly to the third-party application. Therefore, it is no longer an atomic operation and can be externally controlled and interrupted. For example, in step S2, the vendor's app may be attacked, and the extracted current_url may be a malicious H5 page forged by the attacker. In this case, the authorization credential code generated by the vendor's server would be sent to the malicious H5 page. As a result, the attacker may request and obtain the current user's authorization credential code on another legitimate H5 webpage, leading to the theft of the victim's account in the legitimate H5 application.

[0069] In view of this, one or more embodiments of this specification provide an authorized login method and apparatus to defend against potential account theft attacks.

[0070] To enable those skilled in the art to better understand the technical solutions in this specification, the technical solutions in the embodiments of this specification will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this specification, and not all embodiments. Based on the embodiments in this specification, all other embodiments obtained by those skilled in the art without creative effort should fall within the scope of protection of this specification.

[0071] It should be noted that the steps of the corresponding methods are not necessarily performed in the order shown and described in this specification in other embodiments. In some other embodiments, the methods may include more or fewer steps than described in this specification. Furthermore, a single step described in this specification may be broken down into multiple steps in other embodiments; and multiple steps described in this specification may be combined into a single step in other embodiments.

[0072] Those skilled in the art will understand that the terminology used in the embodiments of the present invention is for the purpose of describing particular embodiments only and is not intended to limit the invention. The singular forms “a,” “the,” and “the” as used in the embodiments of the invention and the appended claims are also intended to include the plural forms unless the context clearly indicates otherwise.

[0073] One or more embodiments of the present invention provide an authorized login method. Please refer to... Figure 1 , Figure 1 An exemplary authorization login system is shown, which can be used to implement this authorization login method. It should be noted that the authorization login method described in one or more embodiments of this application can rely on... Figure 1 The authorized login system shown is an implementation, but is not limited to this authorized login system.

[0074] like Figure 1 As shown, the authorized login system includes a user terminal 10, a backend server 11, and an authorization server 12. The user terminal 10 is connected to both the backend server 11 and the authorization server 12 via communication links, which can be wired or wireless networks. For example, the user terminal 10 can establish a communication connection with the backend server 11 and / or the authorization server 12 using communication methods such as Wi-Fi, Bluetooth, or infrared. Alternatively, the user terminal 10 can also establish a communication connection with the backend server 11 and / or the authorization server 12 via a mobile network, where the mobile network standard can be any one of 2G (GSM), 2.5G (GPRS), 3G (WCDMA, TD-SCDMA, CDMA2000, UTMS), 4G (LTE), 4G+ (LTE+), WiMax, etc.

[0075] User terminal 10 is a mobile terminal, such as a mobile phone, laptop, or iPad. A front-end app provided by the service provider is installed on user terminal 10, and an H5 web application is embedded within the front-end app, providing third-party authorization login functionality to the H5 web application. In other words, the front-end app embeds an H5 page, allowing users to log in to the H5 page based on their login status within the front-end app.

[0076] Backend server 11 is the server for H5 pages, which provides users with an authorization login and service window through H5 pages embedded in the frontend APP. Backend server 11 can be any device, equipment, platform, or device cluster with computing and processing capabilities. In this embodiment, the implementation form of backend server 11 is not limited. For example, backend server 11 can be a single server or a server cluster composed of multiple servers. Backend server 11 can also be a cloud server, also known as a cloud computing server or cloud host, which is a host product in the cloud computing service system.

[0077] Authorization server 12 is a server provided by the service provider to respond to requests from the front-end APP and perform corresponding authorizations. Similarly, authorization server 12 can be any device, equipment, platform, device cluster, virtual server, or cloud server with computing and processing capabilities.

[0078] When implementing the authorization login method described in this embodiment, the user terminal 10, backend server 11, and authorization server 12 of the above-mentioned authorization login system execute the following process:

[0079] S100: After logging into the front-end APP on the mobile terminal 10, the user sends an authorization request to the front-end APP through the H5 page embedded in the front-end APP.

[0080] S102. The front-end APP requests authorization credentials (code) from the authorization server 12 based on the authorization request.

[0081] S104. The authorization server 12 returns the authorization credential code to the front-end APP.

[0082] S105. The front-end APP sends the authorization credential code to the back-end server 11 of the H5 page based on the callback address in the authorization request.

[0083] S106. Backend server 11 requests a token from authorization server 12 based on this authorization credential code.

[0084] S107. After verifying that the authorization credential code is correct, the authorization server 12 issues a token.

[0085] S108. The backend server 11 requests user login information from the authorization server 12 based on this token.

[0086] S109. After the authorization server 12 verifies that the token is correct, it returns the user login information.

[0087] S110 and backend server 11 complete the login process on the H5 page based on the user's login information.

[0088] After login, the backend server 11 can return the user's login status cookie to the frontend app's cache. This login status cookie serves as the access token for the H5 page to access resources on the backend server 11. When a user needs to access data on the backend server 11, the H5 page does not directly access the backend server 11 but instead sends a data retrieval request to the frontend app. The frontend app concatenates the data retrieval request with the user's login status cookie and sends it to the backend server 11. After verifying the user's login status cookie, the backend server 11 returns response data to the frontend app for the data retrieval request. The frontend app then sends the response data to the H5 page.

[0089] Corresponding to the above-described authorization login system, in some embodiments, this specification provides an authorization login method. This method is applicable to the service provider side, which includes a front-end APP and an authorization server 12. Please refer to... Figure 2 The method includes the following steps:

[0090] S200. When a user logs into the front-end APP of the service provider, in response to the authorization request initiated by the H5 page in the front-end APP, an authorization credential code is sent to the back-end server 11 of the H5 page.

[0091] In some embodiments, before sending the authorization credential code to the backend server 11, the authorization server 12 also performs the following steps:

[0092] Extract the domain information current_url of the H5 page based on the authorization request;

[0093] Based on the identifier appid carried in the authorization request, obtain the callback address submitted by the backend server 11 when registering with the service provider;

[0094] The validity of an H5 page is determined by the consistency between the domain name information current_url and the callback address.

[0095] Specifically, if the domain information current_url is consistent with the callback address submitted by the backend server 11 when registering with the service provider, or is one of the multiple callback addresses submitted by the backend server 11 when registering with the service provider, then the H5 page is determined to be valid; otherwise, the H5 page is determined to be invalid.

[0096] After verifying the legitimacy of the H5 page, the authorization server 12 will ask the user whether they agree to the authorization. That is, the H5 page will redirect to the authorization page URL provided by the authorization server 12, and obtain the user's confirmation information for this authorization through the authorization page.

[0097] After the user confirms the authorization, the authorization server 12 will generate an authorization credential code for this request, append the authorization credential code to the end of the callback address, and then send it to the front-end APP in the form of a 302 redirect, and then the front-end APP will send it to the H5 page.

[0098] S202. In response to the token request sent by the backend server 11 carrying the authorization credential code, issue a token to the backend server 11.

[0099] The authorization credential code is an intermediate temporary credential in the authorization process. It serves as a temporary certificate for the user to confirm the authorization operation, and its lifespan is generally short. Within this valid period, the backend server 11 can use this temporary certificate to exchange for an access token from the authorization server 12.

[0100] Authorization server 12 will verify the validity of the authorization credential code. After successful verification, it will issue a token. The token's permissions enable the backend server 11 to obtain user login information from authorization server 12.

[0101] S204. In response to the user login information retrieval request carrying a token sent by the backend server 11, return the user login information of the frontend APP to the backend server 11 so that the backend server 11 can complete the login on the H5 page based on the user login information of the frontend APP.

[0102] After obtaining the token, the backend server 11 will request user login information from the authorization server 12 based on the token. After verifying the token's permissions and authenticity, the authorization server 12 will return the user login information of the frontend APP to the backend server 11, enabling the backend server 11 to complete the login on the H5 page based on the user login information of the frontend APP.

[0103] In some embodiments, after the backend server 11 completes the login on the H5 page, it generates a user login status cookie and sends the user login status cookie as a token to access the backend server 11 to the frontend APP cache.

[0104] When a user sends a data retrieval request to the backend server 11 via an H5 page, the frontend APP will concatenate the data access request with the user's login status cookie and send it to the backend server 11. Then, the response data returned by the backend server 11 will be sent to the H5 page.

[0105] and Figure 2 Corresponding to the method shown, one or more embodiments of this specification also provide an authorization login method, which is applicable to mobile terminals. Please refer to... Figure 3 , Figure 3 A flowchart of the authorization login method is shown, which includes:

[0106] S300: Log in to the front-end APP and initiate an authorization request through the H5 page.

[0107] It should be noted that the mobile terminal has a front-end app provided by the service provider installed, which embeds an H5 page. Therefore, after logging into the front-end app on the mobile terminal, the user can log into the H5 page through the login status of the front-end app. When the user opens the H5 page, the H5 page sends an authorization request to the front-end app on the service provider's side. The authorization request carries the identifier appid obtained by the back-end server 11 of the H5 page when it registered with the authorization server 12 on the service provider's side.

[0108] S302. Obtain the authorization credential code returned by the service provider for the authorization request, and send the authorization credential code to the backend server 11 of the H5 page so that the backend server 11 can apply for a token from the service provider and obtain the user login information of the frontend APP based on the token, so as to complete the login on the H5 page based on the user login information.

[0109] Since the authorization credential code is a short-term valid user authorization credential, it cannot be used directly to request user login information from the authorization server 12. Therefore, after obtaining the authorization credential code, the backend server 11 will use it within the validity period of the authorization credential code to exchange for a long-term valid token from the authorization server 12. This token grants the user login information of the frontend APP in the authorization server 12.

[0110] After obtaining the token, the backend server 11 can use the token to request the user login information of the frontend APP from the authorization server 12. It then matches the obtained user login information with the user information stored locally on the mobile terminal. If the match is successful, the login is completed on the H5 page. After logging in through the H5 page, the user can access the backend server 11.

[0111] In some embodiments, after the backend server 11 completes the login of a third-party application, it generates a user login status cookie and sends the user login status cookie to the frontend APP cache.

[0112] When the H5 page initiates a data retrieval request to the backend server 11, the frontend APP sends the data retrieval request and the user's login status cookie to the backend server, and sends the response data returned by the backend server to the H5 page.

[0113] As described above, the authorization login method improves upon the OAuth 2.0-based authorization login process. It directly sends the authorization credentials issued by the service provider to the backend server 11 of the H5 page, and caches the user login state cookie generated by the backend server 11 in the frontend app. This makes the authorization credentials and the resulting user login state cookie invisible to the H5 page. Even if an attacker successfully obtains the code by forging the H5 page, they cannot consume the victim's user login state cookie because the server domains accessible by the H5 page are subject to strict whitelisting restrictions; a forged H5 page cannot directly access the backend server of a legitimate H5 page. By employing this principle, the security of the authorization login process is improved, preventing the leakage of user account information on legitimate H5 pages.

[0114] and Figure 2 Corresponding to the method shown, one or more embodiments of this specification also provide an authorization device, including a front-end APP and an authorization server 12, wherein an H5 page is embedded in the front-end APP;

[0115] When logged in, the front-end APP responds to the authorization request sent by the H5 page, requests authorization credentials from the authorization server 12, and returns the authorization credentials to the H5 page;

[0116] The authorization server 12 is used to generate authorization credentials in response to the front-end APP's request for authorization credentials and send them to the front-end APP; and to issue a token to the back-end server 11 in response to the token request sent by the back-end server 11 carrying the authorization credentials.

[0117] In some embodiments, the front-end APP is also used to extract the domain name information of the H5 webpage based on the authorization request, and send the domain name information and the identifier carried in the authorization request to the authorization server 12 together.

[0118] Accordingly, before generating authorization credentials, the authorization server 12 also verifies the legitimacy of the H5 page. Specifically, this includes: obtaining the callback address submitted by the backend server 11 during registration based on the identifier carried in the authorization request; and determining the legitimacy of the H5 page based on the consistency between the domain information extracted by the frontend APP and the callback address: if the domain information and the callback address are consistent, the H5 page is deemed legitimate; otherwise, the H5 page is deemed illegitimate.

[0119] In some embodiments, the front-end APP is also used to cache the user login status cookie sent by the back-end server 11 in response to the login of the H5 page; and when it receives the data access request sent by the H5 page, it sends the data access request and the user login status cookie together to the back-end server, and sends the response data returned by the back-end server to the H5 page.

[0120] and Figure 3 Corresponding to the method shown, one or more embodiments of this specification also provide a mobile terminal, which has a front-end APP provided by a service provider installed, and an H5 page embedded in the front-end APP. The mobile terminal can log in to the H5 page based on the login status of the front-end APP, specifically including:

[0121] Initiate the authorization request via the H5 page;

[0122] The authorization request is sent to the authorization server 12 of the service provider through the front-end APP;

[0123] The front-end APP obtains the authorization credentials returned by the authorization server 12 for the authorization request, and sends the authorization credentials to the back-end server 11 of the H5 page, so that the back-end server 11 can request a token from the authorization server 12, obtain the user login information of the front-end APP based on the token, and complete the login on the H5 page based on the user login information.

[0124] In some embodiments, after logging into the H5 page, the mobile terminal can access the backend server 11 in the following ways, specifically including:

[0125] After logging into the H5 page, the user login status cookie returned by the backend server 11 is cached through the front-end APP.

[0126] Initiate a data retrieval request to the backend server 11 via an H5 page;

[0127] The front-end APP sends the data acquisition request and the user login status cookie to the back-end server 11, and sends the response data returned by the back-end server 11 to the H5 page.

[0128] The above-mentioned authorization login method will be explained in the following specific scenarios.

[0129] Please refer to Figure 4 , Figure 4 The flowchart illustrates the process of logging into a merchant's H5 page within a manufacturer's app. For example... Figure 4 As shown, the login process includes the following steps:

[0130] S401. The merchant's H5 page sends an authorization login request carrying the identifier appid to the manufacturer's APP. This appid is issued by the manufacturer's server when the merchant's server requests authorization from the manufacturer's server.

[0131] S402. The manufacturer's APP extracts the current domain name current_url of the merchant's H5 page.

[0132] S403. The manufacturer's app concatenates the identifier appid and the domain name current_url in the authorization login request and sends it to the manufacturer's server.

[0133] S404. After verifying the identifier appid and the domain current_url, the vendor server generates the authorization credential code if the information is correct.

[0134] S405, the vendor server sends the authorization credential code to the vendor app.

[0135] S406, The manufacturer's app sends the authorization credential code to the merchant's server.

[0136] S407. The merchant server requests a token from the vendor server based on the authorization credential code, and then requests the user login information of the vendor's APP from the vendor server based on the token.

[0137] S408 After the vendor server verifies that the token is correct, it sends the user login information of the vendor's APP to the merchant's server.

[0138] S409. After obtaining the user login information from the manufacturer's APP, the merchant server compares it with the user information stored locally. If they match, the authentication is successful, and the merchant server completes the login on the merchant's H5 page.

[0139] S410: After the merchant server completes the login on the merchant's H5 page, it generates a user login status cookie and sends the user login status cookie to the manufacturer's APP.

[0140] S411, The manufacturer's APP caches the user's login status cookie in memory.

[0141] S412. After caching the user's login status cookie, the manufacturer's APP returns the authorization login result (login successful / login unsuccessful) to the merchant's H5 page.

[0142] S413: After logging in, the merchant's H5 page can send a data retrieval request to the manufacturer's APP to access the merchant's server.

[0143] S414. The manufacturer's APP will concatenate the received data acquisition request with the cached user login status cookie and send it to the merchant's server.

[0144] S415, The merchant server returns response data to the manufacturer's APP.

[0145] S416, The manufacturer's APP sends the response data to the merchant's H5 page.

[0146] Those skilled in the art will understand that the modules or steps of the present invention described above can be implemented using general-purpose computing devices. They can be centralized on a single computing device or distributed across a network of multiple computing devices. Optionally, they can be implemented using computer-executable program code, thereby storing them in a storage device for execution by a computing device. In some cases, the steps shown or described can be performed in a different order than those presented herein, or they can be fabricated as separate integrated circuit modules, or multiple modules or steps can be fabricated as a single integrated circuit module. Thus, the present invention is not limited to any particular hardware and software combination.

[0147] The various embodiments in this specification are described in a progressive manner. Similar or identical parts between embodiments can be referred to interchangeably. Each embodiment focuses on describing the differences from other embodiments. In particular, the system embodiments are basically similar to the method embodiments, so the description is relatively simple; relevant parts can be referred to the descriptions in the method embodiments.

[0148] The foregoing has described specific embodiments of this specification. Other embodiments are within the scope of the appended claims. In some cases, the actions or steps recited in the claims may be performed in a different order than that shown in the embodiments and may still achieve the desired result. Furthermore, the processes depicted in the drawings do not necessarily require the specific or sequential order shown to achieve the desired result. In some embodiments, multitasking and parallel processing are possible or may be advantageous.

[0149] It should be noted that the above examples are merely specific embodiments of the present invention, and the present invention is obviously not limited to the above embodiments, with many similar variations. All modifications that can be directly derived or conceived by those skilled in the art from the content disclosed in this invention should fall within the protection scope of this invention.

Claims

1. An authorization login method, applicable to a service provider, the method comprising: When a user logs into the front-end APP of the service provider, in response to the authorization request sent by the H5 page in the front-end APP, an authorization credential is sent to the back-end server of the H5 page so that the authorization credential is not visible to the H5 page; In response to the token request sent by the backend server carrying the authorization credentials, a token is issued to the backend server; In response to the user login information retrieval request carrying the token sent by the backend server, the user login information of the frontend APP is sent to the backend server so that the backend server can complete the login on the H5 page based on the user login information, and the user login status cookie sent by the backend server is saved through the frontend APP. The user login status cookie is not visible to the H5 page. In response to the data access request sent by the H5 page, the front-end APP sends the data access request and the user login status cookie to the back-end server, and sends the response data returned by the back-end server to the H5 page.

2. The method as described in claim 1, further comprising the following steps before issuing the authorization credentials to the backend server: Based on the authorization request, extract the domain name information of the H5 page; Based on the identifier carried in the authorization request, obtain the callback address submitted by the backend server when registering with the service provider; Based on the consistency between the domain name information and the callback address, it is determined whether the H5 page is legitimate.

3. An authorization login method, applicable to a mobile terminal, wherein the mobile terminal has a front-end APP provided by a service provider installed, and the front-end APP embeds an H5 page; the method includes: Log in to the front-end APP and initiate an authorization request through the H5 page; The system obtains the authorization credentials returned by the service provider for the authorization request and sends the authorization credentials to the backend server of the H5 page so that the authorization credentials are not visible on the H5 page. The authorization credentials are used to enable the backend server to request a token from the service provider, obtain the user login information of the frontend APP based on the token, complete the login on the H5 page based on the user login information, and save the user login status cookie sent by the backend server through the frontend APP. The user login status cookie is not visible on the H5 page. In response to the data access request sent by the H5 page, the front-end APP sends the data access request and the user login status cookie to the back-end server, and sends the response data returned by the back-end server to the H5 page.

4. An authorization device, comprising a front-end APP and an authorization server, wherein an H5 page is embedded in the front-end APP; The front-end APP, when logged in, responds to the authorization request sent by the H5 page, requests authorization credentials from the authorization server, and returns the authorization credentials to the back-end server of the H5 page so that the authorization credentials are not visible to the H5 page; The authorization server is used to generate the authorization credential in response to the front-end APP's request for the authorization credential and send it to the front-end APP; and to issue a token to the back-end server in response to the token application request carrying the authorization credential sent by the back-end server of the H5 page. The front-end APP is also used to respond to the login of the H5 page by caching the user login status cookie sent by the back-end server, the user login status cookie being invisible to the H5 page; and when receiving a data access request sent by the H5 page, sending the data access request and the user login status cookie together to the back-end server, and sending the response data returned by the back-end server to the H5 page.

5. The apparatus as described in claim 4, wherein the front-end APP is further configured to extract the domain name information of the H5 page based on the authorization request, and send the domain name information and the identifier carried in the authorization request to the authorization server together.

6. The apparatus of claim 5, wherein before generating the authorization credential, the authorization server further verifies the legality of the H5 page, specifically including: Based on the identifier carried in the authorization request, obtain the callback address submitted by the backend server during registration; Based on the consistency between the domain name information extracted by the front-end APP and the callback address, it is determined whether the H5 page is legitimate.

7. A mobile terminal, having a front-end APP provided by a service provider installed, wherein an H5 page is embedded in the front-end APP; the mobile terminal logs into the H5 page based on the login status of the front-end APP, specifically including: Initiate an authorization request through the H5 page; The authorization request is sent to the authorization server of the service provider through the front-end APP; The front-end APP obtains the authorization credentials returned by the authorization server for the authorization request, and sends the authorization credentials to the back-end server of the H5 page so that the authorization credentials are not visible to the H5 page. The authorization credentials are used to enable the back-end server to request a token from the authorization server, obtain the user login information of the front-end APP based on the token, and complete the login on the H5 page based on the user login information. After logging into the H5 page, the user login status cookie returned by the backend server is cached by the front-end APP. The user login status cookie is not visible to the H5 page. The H5 page initiates a data access request to the backend server. The front-end APP sends the data access request and the user login status cookie to the back-end server, and sends the response data returned by the back-end server to the H5 page.

Images