Authorization login method and apparatus

Abstract

Disclosed in the embodiments of the present application are an authorization login method and apparatus. In the method, during an authorization login process, an authorization credential issued by a service supplier end is directly sent to a backend server of an H5 page, such that the authorization credential is invisible to an H5 webpage, thereby greatly reducing the possibility of an attacker acquiring the authorization credential by means of forging the H5 webpage, and reducing the risk of user login information being leaked during an authorization login process of an application via the H5 webpage. The apparatus provided in the embodiments of the present application also has the above beneficial effects.

Description

Authorized login method and device Technical Field

[0001] The present invention relates to the field of computer technology, and in particular to an authorized login method and device. Background Art

[0002] Currently, many HTML5 web applications have been integrated into large mobile applications (hereinafter referred to as manufacturer apps). These H5 applications authenticate end users through the authorized login service provided by the manufacturer app, eliminating the need to enter a separate account or password. For this authorized login service, most manufacturer apps use the universal OAuth2.0 protocol and have undergone some degree of adaptation. However, the OAuth2.0 protocol was originally designed to serve user authorization services on PC web pages. Therefore, these adaptations by manufacturers may violate the original security design of the protocol and introduce the risk of user account information leakage.

[0003] Summary of the Invention

[0004] One or more embodiments of this specification provide an authorized login method and device, which can avoid the problem of H5 page user information leakage that occurs when a mobile terminal logs in to the H5 page in the front-end APP through the login status of the front-end APP.

[0005] According to a first aspect, a method for authorized login is provided, applicable to a service provider, the method comprising:

[0006] When a user logs in to the front-end APP of the service provider, in response to the authorization request sent by the H5 page in the front-end APP, the authorization credentials are issued to the back-end server of the H5 page; in response to the token application request carrying the authorization credentials sent by the back-end server, the token is issued to the back-end server; in response to the user login information acquisition request carrying the token sent by the back-end server, the user login information of the front-end APP is issued to the back-end server, so that the back-end server can complete the login on the H5 page based on the user login information.

[0007] As an optional implementation of the method described in the first aspect, the method also includes: in response to the login of the H5 page, saving the user login status cookie sent by the background server through the front-end APP; and in response to the data access request sent by the H5 page, sending the data access request and the user login status cookie to the background server through the front-end APP, and sending the response data returned by the background server to the H5 page.

[0008] As an optional implementation of the method described in the first aspect, before issuing the authorization credentials to the background server, the following steps are also performed: extracting the domain name information of the H5 page based on the authorization request; obtaining the callback address submitted by the background server when registering on the service provider side based on the identifier carried in the authorization request; and determining whether the H5 page is legal based on the consistency of the domain name information and the callback address.

[0009] According to the second aspect, an authorization login method is provided, which is applicable to a mobile terminal, wherein the mobile terminal is installed with a front-end APP provided by a service provider, and an H5 page is embedded in the front-end APP; the method includes: logging in to the front-end APP and initiating an authorization request through the H5 page; obtaining the authorization credentials returned by the service provider for the authorization request, and sending the authorization credentials to the background server of the H5 page, so that the background server can apply for a token from the service provider, 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.

[0010] As an optional implementation of the method described in the second aspect, the method also includes: after logging into the H5 page, caching the user login status cookie returned by the background server through the front-end APP; when the H5 page sends a data acquisition request to the service provider to access the background server, the data acquisition request and the user login status cookie are sent to the background server through the front-end APP, and the response data returned by the background server is sent to the H5 page.

[0011] 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; the front-end APP is used to, in a logged-in state, respond to an authorization request sent by the H5 page, apply for authorization credentials from the authorization server, and return the authorization credentials to the H5 page; the authorization server is used to respond to the front-end APP's request for the authorization credentials, generate the authorization credentials, and issue them to the front-end APP; and, respond to a token application request carrying the authorization credentials sent by the back-end server of the H5 page, issue a token to the back-end server.

[0012] As an optional implementation of the device described in the third aspect, the front-end APP is also used to extract the domain name information of the H5 web page based on the authorization request, and send the domain name information and the identifier carried in the authorization request to the authorization server.

[0013] Specifically, before generating the authorization credential, the authorization server also reviews the legitimacy of the H5 page, specifically including: obtaining the callback address submitted by the backend server during registration based on the identifier carried in the authorization request; and determining whether the H5 page is legal based on the consistency between the domain name information extracted by the front-end APP and the callback address.

[0014] As an optional implementation of the device described in the third aspect, the front-end APP is also used to cache the user login status cookie sent by the background server in response to the login of the H5 page; and when receiving the data access request sent by the H5 page, the data access request and the user login status cookie are sent to the background server together, and the response data returned by the background server is sent to the H5 page.

[0015] According to the fourth aspect, a mobile terminal is provided, which is installed with a front-end APP provided by a service provider, and an H5 page is embedded in the front-end APP; the mobile terminal logs in to the H5 page based on the login status of the front-end APP, specifically including: initiating an authorization request through the H5 page; sending the authorization request to the authorization server of the service provider through the front-end APP; obtaining the authorization credentials for the authorization request returned by the authorization server through the front-end APP, and sending the authorization credentials to the back-end server of the H5 page, so that the back-end server applies for a token from the authorization server, obtains the user login information of the front-end APP based on the token, and completes the login on the H5 page based on the user login information.

[0016] 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: after logging into the H5 page, caching the user login status cookie returned by the backend server through the front-end APP; initiating a data acquisition request to access the backend server through the H5 page; sending the data acquisition request and the user login status cookie to the backend server through the front-end APP, and sending the response data returned by the backend server to the H5 page.

[0017] The beneficial effect of the authorized login method described in one or more embodiments of this specification is that, during the authorized 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 invisible to the H5 web page, thereby greatly reducing the possibility of an attacker obtaining the authorization credentials by forging the H5 web page, and reducing the risk of user login information leakage during the authorized login process of the H5 web application.

[0018] The device described in the embodiments of this specification also has the above-mentioned beneficial effects. BRIEF DESCRIPTION OF THE DRAWINGS

[0019] In order to more clearly illustrate the embodiments of this specification or the technical solutions in the prior art, the following briefly introduces the drawings required for use in the embodiments or the description of the prior art. Obviously, the drawings described below are some embodiments of this specification. For ordinary technicians in this field, other drawings can be obtained based on these drawings without paying any creative work.

[0020] FIG1 is a structural diagram of an authorized login system provided by one or more embodiments of this specification;

[0021] FIG2 is a flow chart of an authorized login method applicable to a service provider provided in one or more embodiments of this specification;

[0022] FIG3 is a flow chart of an authorized login method applicable to a mobile terminal provided in one or more embodiments of this specification;

[0023] FIG4 is a schematic diagram of the workflow of the authorized login method provided in one or more embodiments of this specification in an implementation scenario. DETAILED DESCRIPTION

[0024] Currently, many H5 web applications have been integrated into large mobile applications. These H5 web applications will authenticate the identity of end users through the authorization login service provided by large mobile application apps, without the need to enter additional account passwords. In such authorization login services, most large mobile application apps use the universal OAuth2.0 protocol and have made a certain degree of adaptation. However, the original design goal of the OAuth2.0 protocol was to serve user authorization services on PC web pages. Therefore, the adaptation made by the manufacturers of large mobile application apps may violate the original security design of the protocol and introduce new risks.

[0025] This article uses the example of a user logging into a merchant server through the authorized login function provided by the manufacturer's server to illustrate the application principles of the OAuth2.0 protocol on a PC. The following describes the OAuth2.0 authorization login process on a PC.

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

[0027] (102) The client (merchant server) sends an authorization request (also known as a 302 redirect request in OAuth2.0) to the user (browser). The authorization request includes the callback address specified by the client and the client identifier.

[0028] (103) The browser jumps 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 and the scope of access rights 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 (manufacturer server).

[0029] (104) After receiving the authorization request from the user (browser), the authorization server (manufacturer 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 manufacturer server during client registration. If both the callback address redirect_url and the identifier appid are successfully verified, the authorization server (manufacturer server) generates an authorization credential code.

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

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

[0032] (107) The client (merchant server) uses the authorization credentials to apply for a token access_token from the authorization server (manufacturer server).

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

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

[0035] From the above process, we can see that in the authorization login process based on the OAuth2.0 protocol on the PC side, steps (105) to (106) are an atomic operation that occurs on the browser side and cannot be interfered or interrupted by the outside world. Therefore, it can be guaranteed that the authorization credential code can be transmitted to the legitimate client.

[0036] However, when the OAuth2.0 protocol is applied to the mobile client, the entire authentication process becomes the following steps.

[0037] (201) The user initiates an authorization login request to the service provider through the H5 page; the service provider consists of the manufacturer's APP and the manufacturer's server.

[0038] (202) The authorization login request initiated by the user is received by the manufacturer APP, and the manufacturer 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.

[0039] (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.

[0040] (204) The manufacturer's 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 passed, an authorization credential code is generated.

[0041] (205) The manufacturer server sends the authorization certificate code to the manufacturer APP.

[0042] (206) The manufacturer’s APP sends the authorization credential code to the H5 page.

[0043] (207) The user sends the authorization credential code to the third-party application through the H5 page.

[0044] (208) The third-party application uses the authorization credential code to apply for the token access_token from the manufacturer server.

[0045] (209) After verifying the access_token, the manufacturer server returns the user login information to the third-party application.

[0046] (210) The third-party application verifies the acquired user login information with the locally stored user login information, and completes the login after the verification is passed.

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

[0048] In the above process, the authorization credential code generated by the manufacturer's server will first be sent to the H5 page that initiated the request (steps 205 to 206), rather than being sent directly to the third-party application. Therefore, it is no longer an atomic operation and may be controlled and interrupted by external parties. For example: in step S2, the manufacturer's APP may be attacked, and the extracted current_url may be a malicious H5 page forged by the attacker. In this way, the authorization credential code generated by the manufacturer's server will be sent to the malicious H5 page. As a result, the attacker may apply for and obtain the current user's authorization credential code on another legitimate H5 web page, and cause the victim's account in the legitimate H5 application to be stolen.

[0049] 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.

[0050] To help those skilled in the art better understand the technical solutions in this specification, the following will provide a clear and complete description of the technical solutions in the embodiments of this specification, in conjunction with the accompanying drawings. Obviously, the described embodiments are only part of the embodiments of this specification, not all of them. All other embodiments obtained by those skilled in the art based on the embodiments in this specification without creative work should fall within the scope of protection of this specification.

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

[0052] Those skilled in the art will appreciate that the terms used in the embodiments of the present invention are for the purpose of describing specific embodiments only and are not intended to limit the present invention. The singular forms "a," "an," "the," and "the" used in the embodiments of the present invention and the appended claims are intended to include the plural forms, unless the context clearly indicates otherwise.

[0053] One or more embodiments of the present invention provide an authorized login method. Please refer to Figure 1, which exemplifies an authorized login system that can be used to implement the authorized login method. It should be noted that the authorized login method described in one or more embodiments of the present application can be implemented based on the authorized login system shown in Figure 1, but is not limited to the authorized login system.

[0054] As shown in Figure 1, 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 the backend server 11 and the authorization server 12 respectively through a communication link, and the communication link can be a wired network or a wireless network. For example, the user terminal 10 can establish a communication connection with the backend server 11 and / or the authorization server 12 using a communication method such as WIFI, Bluetooth, infrared, etc. Alternatively, the user terminal 10 can also establish a communication connection with the backend server 11 and / or the authorization server 12 through a mobile network, wherein the network standard of the mobile network can be any one of 2G (GSM), 2.5G (GPRS), 3G (WCDMA, TD-SCDMA, CDMA2000, UTMS), 4G (LTE), 4G+ (LTE+), WiMax, etc.

[0055] User terminal 10 is a mobile terminal, such as a mobile phone, laptop, or iPad. A front-end app provided by a service provider is installed on user terminal 10. The front-end app hosts an HTML5 web application and provides third-party authorized login functionality to the HTML5 web application. This means that the HTML5 page is embedded in the front-end app, allowing users to log in to the HTML5 page based on their login status within the front-end app.

[0056] The backend server 11 is the server for the H5 page, which provides users with a window for authorized login and service through the H5 page embedded in the front-end APP. The backend server 11 can be any device, equipment, platform, or device cluster with computing and processing capabilities. In this embodiment, the implementation form of the backend server 11 is not limited. For example, the backend server 11 can be a single server or a server cluster composed of multiple servers. The 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.

[0057] The authorization server 12 is a server provided by the service provider for responding to requests from the front-end APP and performing corresponding authorization. Similarly, the authorization server 12 can be any device, equipment, platform, equipment cluster, virtual server or cloud server with computing and processing capabilities.

[0058] When the above-mentioned authorized login system implements the authorized login method described in this embodiment, the user terminal 10, the backend server 11 and the authorization server 12 execute the following processes S100 to S110.

[0059] S100. After the user logs in to the front-end APP on the mobile terminal 10, an authorization request is sent to the front-end APP through the H5 page embedded in the front-end APP.

[0060] S102. The front-end APP applies for an authorization credential code from the authorization server 12 based on the authorization request.

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

[0062] 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.

[0063] S106: The backend server 11 applies for a token from the authorization server 12 based on the authorization credential code.

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

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

[0066] S109: After verifying that the token is correct, the authorization server 12 returns the user login information.

[0067] S110. The backend server 11 completes the login on the H5 page based on the user login information.

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

[0069] Corresponding to the above-mentioned authorized login system, in some embodiments, this specification provides an authorized login method, which is applicable to a service provider side, which includes a front-end APP and an authorization server 12. Referring to Figure 2, the method includes the following steps S200 to S204.

[0070] S200. When a user logs in to 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.

[0071] In some embodiments, before issuing the authorization credential code to the backend server 11, the authorization server 12 also performs the following steps: extracting the domain name information current_url of the H5 page based on the authorization request; obtaining the callback address submitted by the backend server 11 when registering on the service provider side based on the identifier appid carried in the authorization request; and determining whether the H5 page is legal based on the consistency of the domain name information current_url and the callback address.

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

[0073] After verifying the legitimacy of the H5 page, the authorization server 12 will ask the user whether to agree to the authorization, that is, the H5 page will jump to the authorization page URL provided by the authorization server 12, and obtain the user's confirmation information on this authorization through the authorization page.

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

[0075] S202 : In response to the token application request carrying the authorization credential code sent by the backend server 11 , a token is issued to the backend server 11 .

[0076] The authorization credential code is an intermediate temporary credential of the authorization process. It is a temporary certificate for the user to confirm the authorization of this operation. Its life cycle is generally short. During this effective time period, the backend server 11 can use this temporary certificate to exchange for an access token from the authorization server 12.

[0077] The authorization server 12 will verify the validity of the authorization credential code. After the verification is passed, a token will be issued. The authority of the token can enable the backend server 11 to obtain the user login information in the authorization server 12.

[0078] S204. In response to the user login information acquisition request carrying the token sent by the background server 11, the user login information of the front-end APP is returned to the background server 11, so that the background server 11 can complete the login on the H5 page based on the user login information of the front-end APP.

[0079] After the backend server 11 obtains the token, it will request the user login information from the authorization server 12 based on the token. After the authorization server 12 verifies the authority and authenticity of the token, it will return the user login information of the front-end 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 front-end APP.

[0080] 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 to the frontend APP cache as a token for accessing the backend server 11.

[0081] When a user sends a data acquisition request to access the backend server 11 through the H5 page, the front-end APP will splice the data access request and the user login status cookie and send them together to the backend server 11, and then send the response data returned by the backend server 11 to the H5 page.

[0082] Corresponding to the method shown in Figure 2, one or more embodiments of this specification further provide an authorized login method, which is applicable to a mobile terminal. Please refer to Figure 3, which shows a flow chart of the authorized login method, which includes steps S300 to S302.

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

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

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

[0086] Since the authorization credential code is a short-term user authorization credential, it cannot be used to directly request user login information from the authorization server 12. Therefore, after obtaining the authorization credential code, the backend server 11 will use it to exchange for a long-term token from the authorization server 12 within the validity period of the authorization credential code. The token has the authority to obtain the user login information of the front-end app in the authorization server 12.

[0087] After obtaining the token, the backend server 11 can use the token to request the user login information of the front-end APP from the authorization server 12, and then match 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 the user logs in to the H5 page, he can access the backend server 11 through the H5 page.

[0088] In some embodiments, after completing the third-party application login, the backend server 11 generates a user login status cookie and sends the user login status cookie to the front-end APP cache.

[0089] When the H5 page initiates a data acquisition request to access the backend server 11, the data acquisition request and the user login status cookie are sent to the backend server through the front-end APP, and the response data returned by the backend server is sent to the H5 page.

[0090] It can be seen from the above-mentioned authorization login method that this method is an improvement on 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 11 of the H5 page, and the user login status cookie generated by the backend server 11 is cached in the front-end APP, so that the authorization credentials related to the authorization login and the finally derived user login status cookie are not visible to the H5 page. Even if the attacker can successfully obtain the code by forging an H5 page, he cannot consume the victim's user login status cookie, because the server domain name that the H5 page can access has strict whitelist restrictions, and the forged H5 page cannot directly access the backend server of the legitimate H5 page. The above principle can improve the security of the authorization login process and avoid the leakage of the user's account information in the legitimate H5 page.

[0091] Corresponding to the method shown in Figure 2, one or more embodiments of this specification also provide an authorization device, including a front-end APP and an authorization server 12, and an H5 page is embedded in the front-end APP; the front-end APP is used to, in a logged-in state, respond to the authorization request sent by the H5 page, apply for authorization credentials from the authorization server 12, and return the authorization credentials to the H5 page; the authorization server 12 is used to respond to the front-end APP's request for authorization credentials, generate authorization credentials, and issue them to the front-end APP; and, respond to the token application request carrying the authorization credentials sent by the back-end server 11, issue a token to the back-end server 11.

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

[0093] Accordingly, before generating the authorization credential, 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. Based on the consistency between the domain name information extracted by the front-end app and the callback address, the H5 page is determined to be legitimate. If the domain name information and the callback address are consistent, the H5 page is determined to be legitimate; otherwise, the H5 page is determined to be illegitimate.

[0094] In some embodiments, the front-end APP is also used to respond to the login of the H5 page and cache the user login status cookie sent by the background server 11; and when receiving the data access request sent by the H5 page, the data access request and the user login status cookie are sent to the background server together, and the response data returned by the background server is sent to the H5 page.

[0095] Corresponding to the method shown in FIG3 , one or more embodiments of this specification further provide a mobile terminal, which is installed with a front-end APP provided by a service provider, and an H5 page is 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: initiating an authorization request through the H5 page; sending the authorization request to the authorization server 12 on the service provider side through the front-end APP; obtaining the authorization credentials for the authorization request returned by the authorization server 12 through the front-end APP, and sending the authorization credentials to the back-end server 11 of the H5 page, so that the back-end server 11 can apply for 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.

[0096] In some embodiments, after logging into the H5 page, the mobile terminal can access the backend server 11 in the following manner, specifically including: after logging into the H5 page, caching the user login status cookie returned by the backend server 11 through the front-end APP; initiating a data acquisition request to access the backend server 11 through the H5 page; sending the data acquisition request and the user login status cookie to the backend server 11 through the front-end APP, and sending the response data returned by the backend server 11 to the H5 page.

[0097] The following describes the above authorized login method in conjunction with specific scenarios.

[0098] Please refer to Figure 4, which shows a flow chart of logging into a merchant H5 page in a manufacturer APP. As shown in Figure 4, the login process includes the following steps S401 to S416.

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

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

[0101] S403: The manufacturer's APP concatenates the identifier appid and the domain name current_url into an authorization login request and sends it to the manufacturer's server.

[0102] S404: After verifying the identifier appid and the domain name current_url, the manufacturer server generates an authorization credential code if they are correct.

[0103] S405: The manufacturer server sends the authorization credential code to the manufacturer APP.

[0104] S406: The manufacturer APP sends the authorization credential code to the merchant server.

[0105] S407: The merchant server applies to the manufacturer server for a token based on the authorization credential code, and requests the manufacturer server for the user login information of the manufacturer APP based on the token.

[0106] S408: After verifying that the token is correct, the manufacturer server sends the user login information of the manufacturer APP to the merchant server.

[0107] S409. After the merchant server obtains the user login information of the manufacturer APP, it compares it with the user information stored locally. If they are consistent, the authentication is successful, and the merchant server completes the login on the merchant H5 page.

[0108] S410. After completing the login on the merchant H5 page, the merchant server generates a user login status cookie and sends the user login status cookie to the manufacturer APP.

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

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

[0111] S413. After logging in, the merchant H5 page can send a data acquisition request to the manufacturer APP to access the merchant server.

[0112] S414: The manufacturer's APP concatenates the received data acquisition request and the cached user login status cookie, and sends the concatenation to the merchant's server.

[0113] S415. The merchant server returns response data to the manufacturer APP.

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

[0115] Those skilled in the art will appreciate that the various modules or steps of the present invention described above can be implemented using a general-purpose computing device, can be centralized on a single computing device, or can be distributed across a network of multiple computing devices. Alternatively, they can be implemented using program code executable by a computing device, and thus, can be stored in a storage device and executed by the computing device. In some cases, the steps shown or described herein can be performed in a different order than that described herein, or 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 combination of hardware and software.

[0116] The various embodiments in this specification are described in a progressive manner. Similar parts between the various embodiments can be referred to in conjunction with each other. Each embodiment focuses on the differences between the other embodiments. In particular, the system embodiments are generally similar to the method embodiments, so the description is relatively simple. For relevant parts, refer to the description of the method embodiments.

[0117] The foregoing description of this specification describes specific embodiments. Other embodiments are within the scope of the appended claims. In some cases, the actions or steps recited in the claims can be performed in an order different from that described in the embodiments and still achieve the desired results. Furthermore, the processes depicted in the accompanying drawings do not necessarily require the specific order shown or the sequential order to achieve the desired results. In certain embodiments, multitasking and parallel processing are also possible or may be advantageous.

[0118] It should be noted that the above examples are merely specific embodiments of the present invention. Obviously, the present invention is not limited to the above examples, and many similar variations are possible. All variations directly derived from or associating with the present invention by those skilled in the art are intended to fall within the scope of protection of the present invention.

Claims

1. An authorized login method, applicable to a service provider, comprising: When the user logs in to the front-end APP of the service provider, in response to the authorization request sent by the H5 page in the front-end APP, the authorization credential is sent to the back-end server of the H5 page; In response to the token application request carrying the authorization credential sent by the backend server, issuing a token to the backend server; In response to the user login information acquisition request carrying the token sent by the background server, the user login information of the front-end APP is sent to the background server, so that the background server completes the login on the H5 page based on the user login information.

2. The method of claim 1, further comprising: In response to the login of the H5 page, the user login status Cookie sent by the backend server is saved through the front-end APP; as well as In response to the data access request sent by the H5 page, the data access request and the user login status Cookie are sent to the backend server through the front-end APP, and the response data returned by the backend server is sent to the H5 page.

3. The method according to claim 1, further comprising the steps of: before sending the authorization credential to the backend server: Extracting domain name information of the H5 page based on the authorization request; Based on the identifier carried in the authorization request, obtaining 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, determine whether the H5 page is legal.

4. An authorized login method, applicable to a mobile terminal, wherein the mobile terminal is installed with a front-end APP provided by a service provider, and an H5 page is embedded in the front-end APP; the method comprises: Log in to the front-end APP and initiate an authorization request through the H5 page; Obtain the authorization credentials returned by the service provider for the authorization request, and send the authorization credentials to the background server of the H5 page, so that the background server can apply for a token from the service provider, 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.

5. The method of claim 4, further comprising: After logging into the H5 page, the user login status Cookie returned by the backend server is cached by the front-end APP; When the H5 page sends a data acquisition request to the service provider to access the backend server, the data acquisition request and the user login status Cookie are sent to the backend server through the front-end APP, and the response data returned by the backend server is sent to the H5 page.

6. 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 is used to apply for authorization credentials from the authorization server in response to the authorization request sent by the H5 page in the logged-in state, and return the authorization credentials 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 issue it to the front-end APP; and, in response to the token application request carrying the authorization credential sent by the back-end server of the H5 page, issue a token to the back-end server.

7. In the device as described in claim 6, 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 together.

8. The device according to claim 7, wherein the authorization server further verifies the legitimacy of the H5 page before generating the authorization credential, specifically including: Based on the identifier carried in the authorization request, obtaining 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, determine whether the H5 page is legal.

9. In the device as described in claim 6, the front-end APP is also used to respond to the login of the H5 page, cache the user login status Cookie sent by the background server; and when receiving the data access request sent by the H5 page, send the data access request together with the user login status Cookie to the background server, and send the response data returned by the background server to the H5 page.

10. A mobile terminal is installed with a front-end APP provided by a service provider, wherein an H5 page is embedded in the front-end APP; the mobile terminal logs in to the H5 page based on the login status of the front-end APP, specifically comprising: Initiate an authorization request through the H5 page; Sending the authorization request to the authorization server of the service provider through the front-end APP; The authorization credentials for the authorization request returned by the authorization server are obtained through the front-end APP, and the authorization credentials are sent to the background server of the H5 page, so that the background server can apply for 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.

11. The mobile terminal according to claim 10, wherein after logging into the H5 page, the mobile terminal accesses the backend server in the following manner, specifically comprising: After logging into the H5 page, the user login status Cookie returned by the backend server is cached by the front-end APP; Initiate a data acquisition request to access the backend server through the H5 page; The data acquisition request and the user login status Cookie are sent to the backend server through the front-end APP, and the response data returned by the backend server is sent to the H5 page.

Images