Service access method, electronic device and storage medium

Abstract

The embodiment of the present application provides a service access method, electronic device and storage medium, which relates to the field of communication technology. The method includes: receiving a verification request sent by a second electronic device, and performing verification based on the server address information of the second application; in response to the verification of the server address information of the second application being successful, performing permission verification based on the permission range of the second application; in response to the permission verification being successful, returning a verification success message to the second electronic device, so that the second electronic device allows the second application in the third electronic device to perform service access based on the permission range of the second application. The method provided by the embodiment of the present application can downgrade the permissions of the proxy application, avoid the security risks caused by the proxy application performing service access, and thus ensure the security of the user's personal data.

Description

Technical Field

[0001] The embodiments of the present application relate to the field of communication technologies, and in particular to a service access method, electronic device, and storage medium. Background Art

[0002] The Open Authorization (OAUTH) protocol currently provides a secure, open, and simple standard for authorizing user resources. Unlike previous authorization methods, OAUTH authorization prevents third parties from accessing user account information (such as username and password). This means third parties can request authorization for user resources without using the user's username and password. The OAUTH protocol also provides a server-to-server authentication method based on a JWT (JSON Web Token). Summary of the Invention

[0003] Embodiments of the present application provide a service access method, an electronic device, and a storage medium to provide a way to downgrade application permissions.

[0004] In a first aspect, an embodiment of the present application provides a service access method, applied to a first electronic device, comprising:

[0005] Receive a verification request sent by a second electronic device, wherein the verification request is used to verify a service access request, the service access request is initiated by a third electronic device to the second electronic device based on a second application, the second application is called by a first application in the third electronic device, and the verification request includes the second application permission range and the server address information of the second application, and the second application permission range is used to identify the service access permission range of the second application; specifically, the first electronic device may be an authentication server, which is used to verify the service access request; the second electronic device may be a service server, which is used to provide services for access to the proxy application; the third electronic device may be a terminal, which may include a mobile device such as a mobile phone or tablet. The first application may be a master application, and the second application may be a proxy application.

[0006] Verification is performed based on the server address information of the second application.

[0007] In response to the verification of the server address information of the second application being successful, permission verification is performed based on the permission scope of the second application.

[0008] In response to the permission verification being successful, a verification success message is returned to the second electronic device, so that the second electronic device allows the second application in the third electronic device to access services based on the second application permission range.

[0009] In this embodiment, the authentication server pre-assigns proxy permissions to the proxy application to distinguish the main permissions of the main application. The user calls the proxy application in the main application to initiate a business access request. The business access request carries the proxy permission information, and the authentication server performs permission verification based on the proxy permission information. In this way, the business permissions of the proxy application can be downgraded, thereby ensuring the security of the user's personal data.

[0010] In one possible implementation, the verification request also includes the second application identity information. Before receiving the verification request sent by the second electronic device, it also includes: receiving a registration request for the second application, wherein the registration request includes the server address information of the second application; generating the second application identity information and the corresponding key, associating the server address information of the second application with the second application identity information and storing them, and sending the second application identity information and the key to the second application. Specifically, the server address information may include the server address information corresponding to the second application. The identity information may be an identity identifier of the second application, and the identity identifier may be a unique identification number of the second application for identifying the second application. The key may be a symmetric key or an asymmetric key, and the embodiment of the present application does not specifically limit this.

[0011] In this embodiment, the second application can be identified and verified by storing the registration information of the second application and allocating identity information and a key to the second application.

[0012] In one possible implementation method, verification based on the server address information of the second application includes: querying based on the second application identity information to obtain the server address information of the second application corresponding to the second application identity information; comparing the server address information of the second application obtained by the query with the server address information of the second application in the verification request to complete the verification of the server address information of the second application.

[0013] In this embodiment, by pre-storing the server address information and comparing the server address information in the verification request with the pre-stored server address information, the verification of the server address information can be effectively completed, thereby improving security.

[0014] In one possible implementation, before receiving the verification request sent by the second electronic device, it also includes: receiving a second application permission request sent by the first application, wherein the second application permission request is used to obtain the second application permission scope, the second application permission request includes the second application identity information and the first application authorization credential, and the first application authorization credential is used to identify the business access credential of the first application; specifically, the second application permission scope may include the business access scope of the second application. Based on the first application authorization credential query, the preset permission scope of the first application is obtained, wherein the preset permission scope of the first application is used to identify the business access permission scope of the first application; based on the preset permission scope of the first application, the corresponding second application permission scope is obtained, the second application permission scope is associated with the second application identity information and stored, and the second application permission scope is sent to the first application. Specifically, the second application permission scope may include the business access scope of the second application. Then, the second application permission scope is sent to the first application.

[0015] In this embodiment, by obtaining the business access scope of the first application, the business access scope of the second application is obtained based on the business access scope of the first application, and the business access scope of the second application is sent to the first application, so that the first application can call the business access scope of the second application when calling the second application, thereby achieving permission downgrade of the second application and improving security.

[0016] In one possible implementation method, performing permission verification based on the second application permission scope includes: querying based on the second application identity information to obtain the second application permission scope corresponding to the second application identity information; comparing the second application permission scope obtained by the query with the second application permission scope in the verification request to complete the permission verification.

[0017] In this embodiment, the permission verification of the proxy permission of the second application is completed by comparing the second application permission range in the verification request with the locally stored second application permission range, thereby improving security.

[0018] In one possible implementation, after sending the second application identity information and key to the second application, the method further includes: receiving a second application authorization credential request from the second application, wherein the second application authorization credential request is used to obtain the second application authorization credential, the second application authorization credential is used to identify the service access credential of the second application, and the second application authorization credential request includes the second application identity information and key; specifically, the second application authorization credential request carries the identity information and corresponding key of the second application. Since the identity information and corresponding key of the second application are allocated by the first electronic device, security can be improved by verifying the identity information and corresponding key of the second application. Based on the second application identity information, a query is performed to obtain a key corresponding to the second application identity information; the key obtained from the query is compared with the key in the second application authorization credential request, and in response to the key obtained from the query being consistent with the key in the second application authorization credential request, a second application authorization credential is issued and sent to the second application. Specifically, when the key verification is successful, the second application authorization credential is issued to the second application, which can improve security.

[0019] In one possible implementation, the verification request also includes a second application authorization credential. Before performing verification based on the server address information of the second application, the verification request further includes querying whether there is an authorization credential consistent with the second application authorization credential to complete verification of the second application authorization credential. Specifically, further verifying the second application authorization credential before verifying the server address information of the second application can improve security.

[0020] In a second aspect, an embodiment of the present application provides a service access device, including:

[0021] a receiving module, configured to receive a verification request sent by a second electronic device, wherein the verification request is used to verify a service access request, the service access request is initiated by a third electronic device to the second electronic device based on a second application, the second application being called by a first application in the third electronic device, the verification request including a permission scope of the second application and server address information of the second application, the second application permission scope being used to identify a permission scope of service access by the second application;

[0022] A first verification module, configured to perform verification based on the server address information of the second application;

[0023] a second verification module, configured to perform permission verification based on the permission range of the second application in response to successful verification of the server address information of the second application;

[0024] The sending module is configured to return a verification success message to the second electronic device in response to the permission verification being passed, so that the second electronic device allows the second application in the third electronic device to access services based on the second application permission range.

[0025] In one possible implementation, the verification request further includes second application identity information, and the apparatus further includes:

[0026] A registration module is used to receive a registration request from a second application, wherein the registration request includes the server address information of the second application; generate second application identity information and a corresponding key, associate the server address information of the second application with the second application identity information and store them, and send the second application identity information and key to the second application.

[0027] In one possible implementation, the first verification module includes:

[0028] A first query unit is configured to query based on the second application identity information to obtain server address information of the second application corresponding to the second application identity information;

[0029] The first verification unit is configured to compare the server address information of the second application obtained through query with the server address information of the second application in the verification request to complete verification of the server address information of the second application.

[0030] In one possible implementation, the apparatus further includes:

[0031] An agent permission allocation module is used to receive a second application permission request sent by a first application, wherein the second application permission request is used to obtain the second application permission scope, the second application permission scope includes the second application identity information and the first application authorization credential, and the first application authorization credential is used to identify the business access credential of the first application; based on the first application authorization credential, a preset permission scope of the first application is obtained, wherein the preset permission scope of the first application is used to identify the business access permission scope of the first application; based on the preset permission scope of the first application, a corresponding second application permission scope is obtained, the second application permission scope is associated with the second application identity information and stored; and the second application permission scope is sent to the first application.

[0032] In one possible implementation, the second verification module includes:

[0033] A second query unit, configured to query based on the second application identity information to obtain a second application permission range corresponding to the second application identity information;

[0034] The second verification unit is configured to compare the second application permission range obtained through the query with the second application permission range in the verification request to complete the permission verification.

[0035] In one possible implementation, the apparatus further includes:

[0036] The proxy credential allocation module is used to receive a second application authorization credential request from a second application, wherein the second application authorization credential request is used to obtain a second application authorization credential, the second application authorization credential is used to identify the business access credential of the second application, and the second application authorization credential request includes the second application identity information and a key; perform a query based on the second application identity information to obtain a key corresponding to the second application identity information; compare the key obtained by the query with the key in the second application authorization credential request, and in response to the key obtained by the query being consistent with the key in the second authorization credential request, issue a second application authorization credential and send the second application authorization credential to the second application.

[0037] In one possible implementation, the apparatus further includes:

[0038] The third verification module is used to query whether there is an authorization credential that is consistent with the second application authorization credential, so as to complete the verification of the second application authorization credential.

[0039] In a third aspect, an embodiment of the present application provides a first electronic device, including:

[0040] A memory, wherein the memory is used to store computer program code, wherein the computer program code includes instructions, and when the first electronic device reads the instructions from the memory, the first electronic device performs the following steps:

[0041] receiving a verification request sent by a second electronic device, wherein the verification request is used to verify a service access request, the service access request is initiated by a third electronic device to the second electronic device based on a second application, the second application is called by a first application in the third electronic device, the verification request includes a permission scope of the second application and server address information of the second application, the second application permission scope is used to identify a service access permission scope of the second application;

[0042] Verifying based on the server address information of the second application;

[0043] In response to the verification of the server address information of the second application being successful, performing permission verification based on the permission scope of the second application;

[0044] In response to the permission verification being successful, a verification success message is returned to the second electronic device, so that the second electronic device allows the second application in the third electronic device to access services based on the second application permission range.

[0045] In one possible implementation, the verification request also includes the second application identity information. When the instruction is executed by the first electronic device, the first electronic device further performs the following steps before receiving the verification request sent by the second electronic device:

[0046] receiving a registration request from a second application, wherein the registration request includes server address information of the second application;

[0047] Generate second application identity information and a corresponding key, associate the server address information of the second application with the second application identity information and store them, and send the second application identity information and the key to the second application.

[0048] In one possible implementation, when the instruction is executed by the first electronic device, the step of causing the first electronic device to perform verification based on the server address information of the second application includes:

[0049] Perform a query based on the second application identity information to obtain server address information of the second application corresponding to the second application identity information;

[0050] The server address information of the second application obtained by the query is compared with the server address information of the second application in the verification request to complete the verification of the server address information of the second application.

[0051] In one possible implementation, when the instruction is executed by the first electronic device, the first electronic device further performs the following steps before receiving the verification request sent by the second electronic device:

[0052] A second application permission request sent by the first application, where the second application permission request is used to obtain a second application permission scope, the second application permission scope includes the second application identity information and the first application authorization credential, and the first application authorization credential is used to identify the service access credential of the first application;

[0053] Obtaining a preset permission range of the first application based on the first application authorization credential query, wherein the preset permission range of the first application is used to identify the permission range of the service access of the first application;

[0054] The corresponding second application permission range is queried based on the preset permission range of the first application, the second application permission range is associated with the second application identity information and then stored, and the second application permission range is sent to the first application.

[0055] In one possible implementation, when the instruction is executed by the first electronic device, the step of causing the first electronic device to perform permission verification based on the second application permission range includes:

[0056] Perform a query based on the second application identity information to obtain a second application permission range corresponding to the second application identity information;

[0057] The second application permission range obtained by the query is compared with the second application permission range in the verification request to complete the permission verification.

[0058] In one possible implementation, when the instruction is executed by the first electronic device, the first electronic device executes the following steps after sending the second application identity information and key to the second application:

[0059] receiving a second application authorization credential request from the second application, wherein the second application authorization credential request is used to obtain the second application authorization credential, the second application authorization credential is used to identify the service access credential of the second application, and the second application authorization credential request includes the second application identity information and key;

[0060] Perform a query based on the second application identity information to obtain a key corresponding to the second application identity information;

[0061] The key obtained by the query is compared with the key in the second application authorization credential request. In response to the key obtained by the query being consistent with the key in the second authorization credential request, a second application authorization credential is issued and sent to the second application.

[0062] In one possible implementation, the verification request also includes a second application authorization credential. When the instruction is executed by the first electronic device, the first electronic device further performs the following steps before performing the verification based on the server address information of the second application:

[0063] Check whether there is an authorization credential that is consistent with the second application authorization credential to complete the verification of the second application authorization credential.

[0064] In a fourth aspect, an embodiment of the present application provides a computer-readable storage medium, which stores a computer program. When the computer-readable storage medium is run on a computer, the computer executes the method described in the first aspect.

[0065] In a fifth aspect, an embodiment of the present application provides a computer program, which, when executed by a computer, is used to execute the method described in the first aspect.

[0066] In one possible design, the program in the fifth aspect may be stored in whole or in part on a storage medium packaged with the processor, or may be stored in whole or in part on a memory not packaged with the processor. BRIEF DESCRIPTION OF THE DRAWINGS

[0067] Figure 1 A schematic diagram of the application scenario architecture provided by the embodiment of the present application;

[0068] Figure 2A A schematic diagram of a terminal display interface according to an embodiment of the present application;

[0069] Figure 2B A schematic diagram of a terminal display interface of another embodiment provided in the embodiments of the present application;

[0070] Figure 2C A schematic diagram of a terminal display interface according to another embodiment of the present application;

[0071] Figure 3 A flowchart of a service access method according to an embodiment of the present invention;

[0072] Figure 4 A schematic diagram of the data packet format of a service access request according to an embodiment of the present application;

[0073] Figure 5 A flowchart of a service access method according to another embodiment of the present invention;

[0074] Figure 6 A schematic diagram of the data packet format of a service access request according to another embodiment of the present application;

[0075] Figure 7 A flowchart of a service access method according to another embodiment of the present application;

[0076] Figure 8 A schematic diagram of the structure of a service access device provided in an embodiment of the present application;

[0077] Figure 9 A schematic diagram of the structure of an electronic device provided in an embodiment of the present application. DETAILED DESCRIPTION

[0078] The following describes the technical solutions in the embodiments of the present application in conjunction with the accompanying drawings. In the description of the embodiments of the present application, unless otherwise specified, " / " represents "or." For example, A / B can represent A or B. "And / or" in this document is merely a description of the association relationship between associated objects, indicating that three relationships can exist. For example, A and / or B can represent: A exists alone, A and B exist simultaneously, or B exists alone.

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

[0080] After a user opens an application on a terminal, he can log in through his personal account, thereby authorizing the application so that the application can obtain the user's personal data according to the business permissions authorized by the user. For the sake of convenience, this application is hereinafter referred to as the main application. When a user calls a third-party application (hereinafter referred to as the proxy application) through the main application, for example, after opening a main application (for example, a meal ordering application), the user can call a proxy application (for example, a payment application) to make a payment; since the proxy application shares the business permissions authorized by the user with the main application, it can also obtain all the user's personal data. However, the proxy application may only need part of the personal data to complete the current business. For example, the payment application only needs the user's bank account and other personal information to complete the payment business during the payment process, and no other personal information is required. Therefore, if all personal data is open to the proxy application, this may cause the user's personal data to be leaked by the proxy application, causing security risks and losses to the user.

[0081] An embodiment of the present application proposes a business access method to provide a way to downgrade the business permissions of a proxy application, so that when the proxy application is called in the main application for business access, the business permissions of the proxy application are downgraded. This can avoid the security risks caused by the proxy application having the same business permissions as the main application, ensure the security of the user's personal data, and thus avoid user losses.

[0082] The technical solution provided in the embodiments of the present application can be applied to a data processing device, which may be a server. The present application does not impose any special restrictions on the specific form of the data processing device that executes the technical solution.

[0083] Now combined Figure 1-Figure 7 The service access method provided in the embodiment of the present application is described.

[0084] like Figure 1 The following is an application scenario architecture diagram of the service access method of this application. Figure 1 Terminal 100 can communicate with service server 200 and authentication server 300, respectively. Service server 200 is used to provide services corresponding to the main application (e.g., restaurant ordering, ride-hailing, etc.) and services corresponding to the proxy application (e.g., payment), so as to enable users to access services initiated by the main application and the proxy application. Authentication server 300 can be used to register the main application and the proxy application, and to authorize and verify the service permissions of the main application and the proxy application, respectively.

[0085] like Figure 2AAs shown, the display interface 110 of the terminal 100 may include various main applications 111, and the user may operate the main applications 111 on the display interface 110 of the terminal 100. For example, the user may click on the music main application icon on the display interface 110 of the terminal 100 to open the music main application, thereby obtaining the following information: Figure 2B The display interface 120 shown is used to complete the service access to the music main application. Figure 2B , the display interface 120 displays the page corresponding to the music main application. Among them, the display interface 120 also includes various proxy applications 112, and the user can operate the proxy application 112 on the display interface 120 of the terminal 100. For example, the user can click on the album purchase link in the display interface 120 to call the payment interface, so that the display interface 120 can jump to the page corresponding to the purchase and payment of the album (for example, Figure 2C In the display interface 130 , the user can complete the album purchase by verifying the password or fingerprint.

[0086] like Figure 3 The flowchart of one embodiment of the service access method of the present application is shown, including:

[0087] In step 101 , the proxy application 112 sends a registration request to the authentication server 300 .

[0088] Specifically, the proxy application 112 can be a third-party application called in the main application 111. For example, the proxy application 112 can be a payment application that is called; the proxy application 112 can also be other third-party applications that are called, and the embodiments of the present application do not specifically limit this. Among them, the main application 111 can be an application that the user has installed on the terminal 100. For example, the main application 111 can include a social application, a food ordering application, an e-commerce application, etc.; the main application 111 can also be other applications installed on the terminal 100 through a program installation package, and the embodiments of the present application do not specifically limit this. The terminal 100 can be a device with communication functions such as a mobile phone and a tablet. The authentication server 300 can be a server for registering the main application 111 and the proxy application 112, and issuing authorization credentials and verification for the business permissions of the main application 111 and the proxy application 112.

[0089] The proxy application 112 can register with the authentication server 300 via a registration interface. For example, the proxy application 112 can send a registration request to the authentication server 300 via the registration interface. The registration request can include an application type and a server address. The application type can be used to identify the type of the proxy application 112. For example, the type of the proxy application 112 can be set to the proxy application type. The server address is used to identify the server address of the proxy application 112. In a specific implementation, the server address can be identified by the server IP address or domain name. The number of IP addresses can be one or more, and this application does not limit this.

[0090] Taking the RFC 7591 protocol as an example, the registration interface of the protocol can be modified to send the above registration request to complete the registration of the proxy application 112 on the authentication server 300, and the following sample code is obtained:

[0091]

[0092] The newly added field client_type is used to identify the application type, and the newly added field source is used to identify the server address. This completes the registration of the proxy application 112 on the authentication server 300. The registration information of the proxy application 112 may include the application type and the server address.

[0093] In step 102 , the authentication server 300 generates an identity identifier and a key for the proxy application 112 based on the registration request.

[0094] Specifically, after receiving the registration request from proxy application 112, authentication server 300 can assign an identity and a key to proxy application 112. The specific process of assigning an identity and a key can be referred to the OAuth2.0 protocol and will not be described in detail here. The proxy application identity can be used to identify the identity of proxy application 112, that is, the proxy application identity can be used to identify proxy application 112. The proxy application key can be a symmetric or asymmetric key commonly used in the art, and this embodiment of the application does not specifically limit this.

[0095] It is understandable that the authentication server 300 may also store the identity, key, and server address of the proxy application 112. For example, the authentication server 300 may associate the identity, key, and server address of the proxy application 112 and store them in a local database.

[0096] In step 103 , the authentication server 300 returns the identity identifier and key of the proxy application 112 to the proxy application 112 .

[0097] In step 104 , the main application 111 sends a registration request to the authentication server 300 .

[0098] Specifically,

[0099] The main application 111 can also register on the authentication server 300 through the registration interface, for example, through the original registration interface of the rfc7591 protocol. The code example is as follows:

[0100]

[0101] In step 105 , the authentication server 300 generates an identity identifier and a key for the primary application 111 based on the registration request.

[0102] Specifically, after receiving the registration request from the primary application 111, the authentication server 300 can assign an identity and a key to the primary application 111. The specific process of assigning an identity and a key can be referred to the OAuth2.0 protocol and will not be described in detail here. The primary application identity can be used to identify the primary application 111, that is, the primary application identity can be used to identify the primary application 111. The primary application key can use a symmetric or asymmetric key commonly used in the art, and this embodiment of the application does not specifically limit this.

[0103] Furthermore, the authentication server 300 may also store the identity identifier and the key of the main application 111 . For example, the authentication server 300 stores the identity identifier and the key of the main application 111 in a local database.

[0104] In step 106 , the authentication server 300 returns the identity identifier and key of the main application 111 to the main application 111 .

[0105] In step 107 , the master application 111 initiates a master authorization credential request to the authentication server 300 based on the identity identifier and key of the master application 111 to obtain the master authorization credential.

[0106] Specifically, the primary authorization credential is used to identify the service authority of the primary application 111. The primary authorization credential request includes the identity and key of the primary application 111.

[0107] In step 108 , the authentication server 300 issues a master authorization credential based on the identity identifier and key of the master application 111 , and sends the master authorization credential to the master application 111 .

[0108] Specifically, after receiving the main authorization credential request from the main application 111, the authentication server 300 can perform verification based on the identity identifier and key of the main application 111 in the authorization credential request. Exemplarily, the authentication server 300 can compare the identity identifier and key of the main application 111 with the identity identifier and key corresponding to the main application 111 stored in the local database. If the above comparison is consistent, the verification is successful. Exemplarily, a query can be performed in the local database based on the identity identifier of the main application 111 in the main authorization credential request to obtain the key corresponding to the identity identifier of the main application 111. If the key of the main application 111 in the main authorization credential request is consistent with the key of the main application 111 stored in the local database, the verification is successful. At this time, the authentication server 300 can issue a main authorization credential corresponding to the main application 111, and can send the main authorization credential to the main application 111. In addition, the authentication server 300 can also store the master authorization credential, so that when the authentication server 300 subsequently receives a request carrying the master authorization credential (for example, a proxy authorization credential request or a service access request), it can verify the legitimacy of the master authorization credential, thereby improving the security of data transmission.

[0109] It is understandable that, in order to ensure the validity and security of the master authorization credential, the authentication server 300 may further set a validity period for the master authorization credential. If the master authorization credential exceeds the validity period, the master authorization credential becomes invalid.

[0110] In step 109 , the main application 111 requests the authentication server 300 for proxy authority.

[0111] Specifically, the proxy authority is used to identify the scope of the service authority of the proxy application 112 .

[0112] The master application 111 may send a proxy permission request to the authentication server 300 to obtain the proxy permission, wherein the proxy permission request may include the permission type, the identity of the proxy application 112 and the master authorization credential.

[0113] Taking the RFC 6749 protocol as an example, the authorization interface of the protocol can be modified to send a proxy permission request, resulting in the following sample code:

[0114] POST / token HTTP / 1.1

[0115] Host:server.example.com

[0116] Authorization:Bearer czZCaGRSa3F0MzpnWDFmQmF0M2JW

[0117] Content-Type:application / x-www-form-urlencoded

[0118] grant_type=authorization_proxy_token&&proxy_client_id=xxx

[0119] Among them, a new Bearer type is added to the Authorization field, which is used to identify the main authorization credentials of the main application 111; a new authorization_proxy_token type is added to the grant_type field, which is used to identify that the permission type in the proxy permission request is a proxy permission; a new field proxy_client_id is added, and the field proxy_client_id is used to identify the identity of the proxy application 112.

[0120] In step 110 , the authentication server 300 issues a proxy authority based on the proxy authority request of the main application 111 , and sends the proxy authority to the main application 111 .

[0121] Specifically, after the authentication server 300 receives the proxy permission request from the main application 111, it can verify the legitimacy of the main authorization credential. Exemplarily, the authentication server 300 can query whether there is an authorization credential that is consistent with the main authorization credential in the proxy authorization credential request. If there is an authorization credential that is consistent with the main authorization credential in the proxy authorization credential request, it can be considered that the main authorization credential is issued by the authentication server 300, that is, the main authorization credential is legal, and the scope of the preset business authority corresponding to the main application 111 can be obtained based on the main authorization credential, and the scope of the business authority corresponding to the proxy application 112 can be obtained based on the scope of the business authority of the main application 111. Exemplarily, Table 1 is the scope of the business authority of the main application 111 and the scope of the business authority of the proxy application 112. It can be understood that Table 1 can be pre-stored in the authentication server 300.

[0122] Table 1

[0123]

[0124] As shown in Table 1, the service permissions of main application 111 may include support for openid.proxy mode, email.proxy mode, profile.proxy mode, push operations, and SMS operations. The service permissions of proxy application 112 may include support for openid.proxy mode, email.proxy mode, and profile.proxy mode, but not support for push operations and SMS operations. As can be seen from Table 1, the service permissions of proxy application 112 are less limited to push operations and SMS operations than those of main application 111.

[0125] Next, the authentication server 300 may generate proxy permissions based on the scope of the service permissions of the proxy application 112 , thereby downgrading the service permissions of the proxy application 112 and avoiding security risks caused by the service permissions of the proxy application 112 exceeding the scope.

[0126] It is understood that the proxy permission corresponds to the identity of the proxy application 112 in the proxy permission request. For example, assuming that a main application 111 requests proxy permission for a proxy application 112 (e.g., a payment application), and the proxy permission request carries the identity of the proxy application 112, the authentication server 300 will issue proxy permission to the proxy application 112 after receiving the proxy permission request.

[0127] Step 111 : In response to a user accessing the proxy application 112 , the main application 111 calls the proxy application 112 .

[0128] Specifically, the user can operate on the terminal 100 to open the main application 111. Then, the user can operate in the main application 111. For example, the user can click on the link corresponding to the proxy application 112 in the main application 111 to access the proxy application 112. For example, the user can click on the payment application in the e-commerce application to access the payment application, so that the user can initiate a payment transaction. In response to the user's operation of accessing the proxy application 112, the current main application 111 calls the proxy application 112. In the process of calling the proxy application, the main application 111 can carry the proxy permission, thereby allowing the proxy application 112 to use the business permission corresponding to the proxy permission, thereby ensuring the security of the user's personal data.

[0129] In step 112 , the proxy application 112 initiates a service access request to the service server 200 based on the proxy authority.

[0130] Specifically, the proxy application 112 can send a service access request to the service server 200 through the verification interface to implement the corresponding service operation, such as initiating a payment service. The service access request can include the identity of the proxy application 112, the server address, and the proxy authority. The service access request can be sent in the form of a JWT.

[0131] Taking the RFC 7523 protocol as an example, the credential verification interface of the protocol can be modified to send a service access request, resulting in the following sample code:

[0132] POST / token.oauth2 HTTP / 1.1

[0133] Host:authz.example.net

[0134] Content-Type:application / x-www-form-urlencoded

[0135] grant_type=urn%3Aietf%3Aparams%3Aoauth%3Agrant-type%3Ajwt-bearer-with-proxy-token

[0136] &assertion=eyJhbGciOiJFUzI1NiIsImtpZCI6IjE2In0.

[0137] eyJpc3Mi[...omitted for brevity...].

[0138] J9l-ZhwP[...omitted for brevity...]

[0139] The grant_type field adds the jwt-bearer-with-proxy-token type, which is used to identify the permission type in the business access request as proxy permission.

[0140] like Figure 4FIG. 4 is a schematic diagram of a JWT packet 400 for the aforementioned service access request. JWT packet 400 may include a header 410 and a payload 420. Header 410 includes a proxy permission field 411, a proxy application identity field 412, and a server address field 413. Proxy permission field 411 is used to identify the location of proxy permission information 421 within payload 420. Proxy application identity field 412 is used to identify the location of the proxy application identity within payload 420. Server address field 413 is used to identify the location of the server address information within payload 420. Payload 420 includes proxy permission information 321 corresponding to proxy permission field 411, proxy application identity information 422 corresponding to proxy application identity field 412, and server address information 423 corresponding to server address field 413. Permission information 421 may include the scope of service permissions for proxy application 112, proxy application identity information 422 may include the identity of proxy application 411, and server address information 423 may include the server address of proxy application 112 (e.g., the IP address or domain name of the proxy application server).

[0141] It is understandable that the header 410 may also include a declaration field 414, which is used to identify the location of the declaration information 424 in the payload 420. The payload 420 also includes declaration information 424 corresponding to the declaration field 414. The declaration information 424 may include declaration information such as the JWT issuer (for example, the server address that issued the JWT), the issuance time, and the issuance validity period. In some embodiments, the JWT data packet 400 may not include the above-mentioned declaration information, and this embodiment of the present application does not specifically limit this.

[0142] In step 113 , the service server 200 calls the authentication interface of the authentication server 300 to perform verification based on the service access request.

[0143] Specifically, the business server 200 can call the authentication interface of the authentication server 300 (for example, the authentication interface of the OAuth2.0 protocol) and forward the information in the service access request to the authentication server 300 to verify the service access request. For example, the business server 200 can send the identity identifier, server address, and proxy authority of the proxy application 112 to the authentication server 300 for verification.

[0144] Step 114: The authentication server 300 verifies the server address.

[0145] Specifically, the authentication server 300 has stored the association between the identity identifier of the proxy application 112 and the server address in step 102. Therefore, the authentication server 300 can obtain the corresponding server address based on the identity identifier query of the proxy application 112 forwarded by the business server 200, and can compare the server address forwarded by the business server 200 with the server address stored locally.

[0146] If there is a server address in the locally stored server addresses that is consistent with the server address sent by the business server 200, step 116 is executed.

[0147] If the locally stored server address does not contain a server address that is consistent with the server address sent by the service server 200 , step 115 is executed.

[0148] In step 115 , the authentication server 300 feeds back an authentication failure message to the proxy application 112 , ending the service access.

[0149] In step 116 , the authentication server 300 performs authorization verification on the proxy authorization.

[0150] Specifically, the authentication server 300 may obtain the scope of the service permissions of the proxy application 112 based on the identity of the proxy application 112. For example, the authentication server 300 may query Table 1 based on the identity of the proxy application 112 to obtain the corresponding scope of the service permissions of the proxy application 112. The authentication server 300 may then compare the scope of the service permissions of the proxy application 112 obtained from the query with the scope of the service permissions corresponding to the proxy permissions in the service access request to complete the verification of the proxy permissions.

[0151] If the scope of the service authority of the proxy application 112 obtained through the query is consistent with the scope of the service authority corresponding to the proxy authority in the service access request, step 118 is executed.

[0152] If the scope of the service authority of the proxy application 112 obtained through the query is inconsistent with the scope of the service authority corresponding to the proxy authority in the service access request, step 117 is executed.

[0153] It should be noted that, when determining whether the scope of the business permissions of the proxy application 112 obtained by the query is consistent with the scope of the business permissions corresponding to the proxy permissions in the business access request, it can be determined whether the scope of the business permissions corresponding to the proxy permissions in the business access request is included in the scope of the business permissions of the proxy application 112 obtained by the query. If it is determined that the scope of the business permissions corresponding to the proxy permissions in the business access request is included in the scope of the business permissions of the proxy application 112 obtained by the query, then the scope of the business permissions of the proxy application 112 obtained by the query is consistent with the scope of the business permissions corresponding to the proxy permissions in the business access request; if it is determined that the scope of the business permissions corresponding to the proxy permissions in the business access request is not included in the scope of the business permissions of the proxy application 112 obtained by the query, then the scope of the business permissions of the proxy application 112 obtained by the query is inconsistent with the scope of the business permissions corresponding to the proxy permissions in the business access request. In addition, it is also possible to determine whether the scope of the business permissions of the proxy application 112 obtained by the query is the same as the scope of the business permissions corresponding to the proxy permissions in the business access request. If it is determined that the scope of the business permissions corresponding to the proxy permissions in the business access request is the same as the scope of the business permissions of the proxy application 112 obtained by the query, then the scope of the business permissions of the proxy application 112 obtained by the query is consistent with the scope of the business permissions corresponding to the proxy permissions in the business access request; if it is determined that the scope of the business permissions corresponding to the proxy permissions in the business access request is not the same as the scope of the business permissions of the proxy application 112 obtained by the query, then the scope of the business permissions of the proxy application 112 obtained by the query is inconsistent with the scope of the business permissions corresponding to the proxy permissions in the business access request. The embodiments of the present application do not make special limitations on this.

[0154] In step 117 , the authentication server 300 feeds back an authentication failure message to the proxy application 112 , ending the service access.

[0155] In step 118 , the authentication server 300 returns a verification success message to the service server 200 , so that the service server 200 allows the proxy application 112 to access the service.

[0156] In step 119 , the service server 200 returns the service processing result to the proxy application 112 based on the service access request.

[0157] Specifically, after receiving the verification success message, the business server 200 can perform business processing based on the business access request. For example, if this business access request is a payment request, the business server 200 can complete the payment task and return the business processing result (for example, payment result) to the proxy application 112.

[0158] In an embodiment of the present application, proxy permissions are pre-assigned to the proxy application by the authentication server to distinguish the main permissions of the main application. When the user calls the proxy application in the main application to access a business, the business access request carries the proxy permissions, and the authentication server performs permission verification based on the proxy permissions. This can downgrade the business permissions of the proxy application, thereby ensuring the security of the user's personal data.

[0159] Then combine Figure 5 and Figure 6 Another embodiment of the present invention provides a method for accessing services. Figure 5 FIG. 1 is a flow chart of another embodiment of the service access method of the present application, including:

[0160] In step 201 , the proxy application 112 sends a registration request to the authentication server 300 .

[0161] Specifically, the proxy application 112 can be a third-party application called in the main application 111. For example, the proxy application 112 can be a payment application that is called; the proxy application 112 can also be other third-party applications that are called, and the embodiments of the present application do not specifically limit this. Among them, the main application 111 can be an application that the user has installed on the terminal 100. For example, the main application 111 can include a social application, a food ordering application, an e-commerce application, etc.; the main application 111 can also be other applications installed on the terminal 100 through a program installation package, and the embodiments of the present application do not specifically limit this. The terminal 100 can be a device with communication functions such as a mobile phone and a tablet. The authentication server 300 can be a server for registering the main application 111 and the proxy application 112, and issuing authorization credentials and verification for the business permissions of the main application 111 and the proxy application 112.

[0162] The proxy application 112 can register with the authentication server 300 via a registration interface. For example, the proxy application 112 can send a registration request to the authentication server 300 via the registration interface. The registration request can include an application type and a server address. The application type can be used to identify the type of the proxy application 112. For example, the type of the proxy application 112 can be set to the proxy application type. The server address is used to identify the server address of the proxy application 112. In a specific implementation, the server address of the proxy application 112 can be identified by a server IP address or domain name, which is not limited in this application.

[0163] In step 202 , the authentication server 300 generates an identity identifier and a key for the proxy application 112 based on the registration request.

[0164] Specifically, after receiving the registration request from proxy application 112, authentication server 300 can assign an identity and a key to proxy application 112. The specific process of assigning an identity and a key can be referred to the OAuth2.0 protocol and will not be described in detail here. The proxy application identity can be used to identify the identity of proxy application 112, that is, the proxy application identity can be used to identify proxy application 112. The proxy application key can be a symmetric or asymmetric key commonly used in the art, and this embodiment of the application does not specifically limit this.

[0165] It is understandable that the authentication server 300 may also store the identity, key, and server address of the proxy application 112. For example, the authentication server 300 may associate the identity, key, and server address of the proxy application 112 and store them in a local database.

[0166] In step 203 , the authentication server 300 returns the identity identifier and key of the proxy application 112 to the proxy application 112 .

[0167] In step 204 , the proxy application 112 requests a proxy authorization credential from the authentication server 300 based on the identity identifier and key of the proxy application 112 .

[0168] Specifically, the proxy authorization credential is used to identify the service authority of the proxy application 112 .

[0169] In step 205 , the authentication server 300 issues a proxy authorization credential based on the identity identifier and key of the proxy application 112 , and sends the proxy authorization credential to the proxy application 112 .

[0170] Specifically, the proxy authorization credential may be issued by the authentication server 300 , so that the authentication server 300 can verify the legitimacy of the proxy authorization credential after subsequently receiving the proxy authorization credential.

[0171] In step 206 , the main application 111 sends a registration request to the authentication server 300 .

[0172] Specifically, the main application 111 may register on the authentication server 300 through a registration interface, for example, through an original registration interface of the rfc7591 protocol.

[0173] In step 207 , the authentication server 300 generates an identity identifier and a key for the primary application 111 based on the registration request.

[0174] Specifically, after receiving the registration request from the main application 111, the authentication server 300 can assign an identity and a key to the main application 111. The specific process of assigning an identity and a key can be referred to the OAuth2.0 protocol and will not be described in detail here. Among them, the main application identity can be used to identify the identity of the main application 111, that is, the main application identity can be used to identify the main application 111. The main application key can adopt a symmetric or asymmetric key commonly used in the field, and the embodiments of the present application do not specifically limit this.

[0175] Furthermore, the authentication server 300 may also store the identity identifier and the key of the main application 111 . For example, the authentication server 300 stores the identity identifier and the key of the main application 111 in a local database.

[0176] In step 208 , the authentication server 300 returns the identity identifier and key of the main application 111 to the main application 111 .

[0177] In step 209 , the master application 111 requests a master authorization credential from the authentication server 300 based on the identity identifier and key of the master application 111 .

[0178] Specifically, the primary authorization credential is used to identify the service authority of the primary application 111. The primary authorization credential request includes the identity and key of the primary application 111.

[0179] In step 210 , the authentication server 300 issues a master authorization credential based on the identity identifier and key of the master application 111 , and sends the master authorization credential to the master application 111 .

[0180] Specifically, after receiving the main authorization credential request from the main application 111, the authentication server 300 can perform verification based on the identity identifier and key of the main application 111 in the authorization credential request. Exemplarily, the authentication server 300 can compare the identity identifier and key of the main application 111 with the identity identifier and key corresponding to the main application 111 stored in the local database. If the above comparison is consistent, the verification is successful. Exemplarily, a query can be performed in the local database based on the identity identifier of the main application 111 in the main authorization credential request to obtain the key corresponding to the identity identifier of the main application 111. If the key of the main application 111 in the main authorization credential request is consistent with the key of the main application 111 stored in the local database, the verification is successful. At this time, the authentication server 300 can issue a main authorization credential corresponding to the main application 111, and can send the main authorization credential to the main application 111. In addition, the authentication server 300 can also store the master authorization credential, so that when the authentication server 300 subsequently receives a request carrying the master authorization credential (for example, a proxy authorization credential request or a service access request), it can verify the legitimacy of the master authorization credential, thereby improving the security of data transmission.

[0181] It is understandable that, in order to ensure the validity and security of the master authorization credential, the authentication server 300 may further set a validity period for the master authorization credential. If the master authorization credential exceeds the validity period, the master authorization credential becomes invalid.

[0182] In step 211 , the main application 111 requests the authentication server 300 for proxy authority.

[0183] Specifically, the proxy authority is used to identify the scope of the service authority of the proxy application 112 .

[0184] The main application 111 may send a proxy permission request to the authentication server 300. The proxy permission request may include the permission type, the identity of the proxy application 112, and the main authorization credential.

[0185] In step 212 , the authentication server 300 issues a proxy authority based on the request of the main application 111 and sends the proxy authority to the main application 111 .

[0186] Specifically, after the authentication server 300 receives the proxy permission request from the main application 111, it can verify the legitimacy of the main authorization credential. Exemplarily, the authentication server 300 can query whether there is an authorization credential that is consistent with the main authorization credential in the proxy authorization credential request. If there is an authorization credential that is consistent with the main authorization credential in the proxy authorization credential request, it can be considered that the main authorization credential is issued by the authentication server 300, that is, the main authorization credential is legal, and the scope of the business authority corresponding to the main application 111 and the scope of the business authority corresponding to the proxy application 112 can be obtained based on the main authorization credential.

[0187] Next, the authentication server 300 may generate proxy permissions based on the scope of the service permissions of the proxy application 112 , thereby downgrading the service permissions of the proxy application 112 and avoiding security risks caused by the service permissions of the proxy application 112 exceeding the scope.

[0188] It is understood that the proxy permission corresponds to the identity of the proxy application 112 in the proxy permission request. For example, assuming that a main application 111 requests proxy permission for a proxy application 112 (e.g., a payment application), and the proxy permission request carries the identity of the proxy application 112, the authentication server 300 will issue proxy permission to the proxy application 112 after receiving the proxy permission request.

[0189] Step 213 : In response to the user's operation of calling the proxy application 112 , the main application 111 calls the proxy application 112 .

[0190] Specifically, the user can operate on the terminal 100 to open the main application 111. Then, the user can operate in the main application 111. For example, the user can click on the link corresponding to the proxy application 112 in the main application 111 to access the proxy application 112. For example, the user can click on the payment application in the e-commerce application to access the payment application, so that the user can initiate a payment transaction. In response to the user's operation of accessing the proxy application 112, the current main application 111 calls the proxy application 112. In the process of calling the proxy application, the main application 111 can carry the proxy permission, thereby allowing the proxy application 112 to use the business permission corresponding to the proxy permission, thereby ensuring the security of the user's personal data.

[0191] In step 214 , the proxy application 112 initiates a service access request to the service server 200 based on the identity identifier, proxy authorization credentials, server address, and proxy authority of the proxy application 112 .

[0192] Specifically, the difference between step 214 and step 112 is that the service access request may include a proxy authorization credential in addition to the identity identifier, server address, and proxy authority of the proxy application 112. The proxy authority may include the scope of the service authority of the proxy application 112.

[0193] Figure 6 Schematic diagram of a data packet 600 in JWT format for a service access request. Data packet 600 may include a header 610 and a payload 620. Header 610 includes a proxy authorization credentials field 611, a proxy permission field 612, a proxy application identity field 613, and a server address field 614. The proxy authorization credentials field 611 is used to identify the location of proxy authorization credentials information 621 within payload 620. The proxy permission data field 612 is used to identify the location of proxy permission information 622 within payload 620. The proxy application identity field 613 is used to identify the location of proxy application identity information 623 within payload 620. The server address field 614 is used to identify the location of server address information 624 within payload 620. Payload 620 includes proxy authorization credentials information 621 corresponding to the proxy authorization credentials field 611, proxy permission information 622 corresponding to the proxy permission field 612, proxy application identity information 623 corresponding to the proxy application identity field 613, and server address information 624 corresponding to the server address field 614. Among them, the proxy authorization credential information 611 may include the proxy authorization credential issued by the authentication server 300 to the proxy application 112, the proxy permission information 622 may include the scope of the business authority of the proxy application 112, the proxy application identity information 623 may include the identity of the proxy application 112, and the server address information 624 may include the server address of the proxy application 112.

[0194] It is understood that the header 610 may also include a declaration field 615, which is used to identify the location of the declaration information 625 in the payload 620. The payload 620 also includes declaration information 625 corresponding to the declaration field 615. The declaration information 625 may include declaration information such as the JWT issuer (for example, the server address that issued the JWT), the issuance time, and the issuance validity period. In some embodiments, the data packet 600 may not include the above-mentioned declaration information, and this embodiment of the application does not specifically limit this.

[0195] In step 215 , the service server 200 calls the authentication interface of the authentication server 300 to perform verification based on the service access request.

[0196] Specifically, the business server 200 can call the authentication interface of the authentication server 300 (for example, the authentication interface of the OAuth2.0 protocol) and send the information in the service access request to the authentication server 300 to verify the service access request. For example, the business server 200 can send the identity of the proxy application 112, the server address of the proxy application 112, the proxy authorization credentials, and the proxy permissions to the authentication server 300 for verification, wherein the above verification can include legitimacy verification and permission verification.

[0197] In step 216, the authentication server 300 verifies the legitimacy of the proxy authorization credential.

[0198] Specifically, the authentication server 300 can perform legitimacy verification based on the proxy authorization credential. For example, the authentication server 300 can query whether there is an authorization credential consistent with the proxy authorization credential to determine whether the proxy authorization credential is issued by the authentication server 300, thereby verifying the legitimacy of the proxy authorization credential.

[0199] If the proxy authorization credential is legal, step 218 may be further executed.

[0200] If the proxy authorization credential is illegal, step 217 may be further executed.

[0201] In step 217 , the authentication server 300 feeds back an authentication failure message to the proxy application 112 , ending the service access.

[0202] In step 218, the authentication server 300 verifies the server address.

[0203] Specifically, the authentication server 300 has stored the association between the identity identifier of the proxy application 112 and the server address in step 202. Therefore, the authentication server 300 can obtain the corresponding server address based on the identity identifier query of the proxy application 112 forwarded by the business server 200, and can compare the server address forwarded by the business server 200 with the server address stored locally.

[0204] If there is a server address in the locally stored server addresses that is consistent with the server address sent by the service server 200, step 220 is executed.

[0205] If there is no server address in the locally stored server addresses that is consistent with the server address sent by the service server 200 , step 219 is executed.

[0206] In step 219 , the authentication server 300 feeds back an authentication failure message to the proxy application 112 , ending the service access.

[0207] In step 220 , the authentication server 300 performs authorization verification on the proxy authorization.

[0208] Specifically, the authentication server 300 may obtain the scope of the service permissions of the proxy application 112 based on the identity of the proxy application 112. For example, the authentication server 300 may query Table 1 based on the identity of the proxy application 112 to obtain the scope of the service permissions of the corresponding proxy application 112. The authentication server 300 may then compare the scope of the service permissions of the proxy application 112 obtained from the query with the scope of the service permissions corresponding to the proxy permissions in the service access request to complete the authorization verification of the proxy permissions.

[0209] If the scope of the service authority of the proxy application 112 obtained by the query is consistent with the scope of the service authority corresponding to the proxy authority in the service access request, step 222 is executed.

[0210] If the scope of the service authority of the proxy application 112 obtained by query is inconsistent with the scope of the service authority corresponding to the proxy authority in the service access request, step 221 is executed.

[0211] In step 221 , the authentication server 300 feeds back an authentication failure message to the proxy application 112 , ending the service access.

[0212] In step 222 , the authentication server 300 returns a verification success message to the service server 200 , so that the service server 200 allows the proxy application 112 to access the service.

[0213] In step 223 , the service server 200 returns the service processing result to the proxy application 112 based on the service access request.

[0214] Specifically, after receiving the verification success message, the business server 200 can perform business processing based on the business access request. For example, if this business access request is a payment request, the business server 200 can complete the payment task and return the business processing result (for example, payment result) to the proxy application 112.

[0215] In an embodiment of the present application, the authentication server pre-assigns proxy permissions to the proxy application to distinguish it from the primary permissions of the main application. When a user calls the proxy application from the main application to access a service, the service access request includes the proxy permissions, and the authentication server performs permission verification based on the proxy permissions. This allows the proxy application's service permissions to be downgraded, thereby ensuring the security of the user's personal data. Furthermore, when the user calls the proxy application to access a service, the service access request also includes proxy authorization credentials. The authentication server verifies the proxy authorization credentials before performing permission verification on the proxy permissions, thereby improving security and further ensuring the security of the user's personal data.

[0216] Then combine Figure 7 The service access method provided in another embodiment of the present application is described as follows: Figure 7 FIG. 1 is a flow chart of another embodiment of the service access method of the present application, which is applied to a first electronic device and includes:

[0217] Step 301: The first electronic device receives a registration request sent by a second application and allocates identity information and a key to the second application.

[0218] Specifically, the second application may be the proxy application 112. The first electronic device may be the authentication server 300. Upon receiving the registration request from the second application, the first electronic device may generate second application identity information and a key corresponding to the second application, associate the server address information of the second application with the second application identity information, and store the associated information. The second application identity information and the key may be sent to the second application. The registration request may include the server address information of the second application. Exemplarily, the server address information may include a server address.

[0219] Step 302: The first electronic device receives a second application authorization credential request sent by the second application, and issues a second application authorization credential to the second application.

[0220] Optionally, the first electronic device may also issue a second application authorization credential to the second application. The second application authorization credential is used to identify the service access credential of the second application. The second application authorization credential request may include the second application identity and key.

[0221] When the first electronic device receives a second application authorization credential request from the second application, it can obtain the second application identity information and key in the second application authorization credential request. It can then query the second application identity information to obtain the key corresponding to the second application identity information. The key obtained from the query is compared with the key in the second application authorization credential request. If the key obtained from the query is consistent with the key in the second application authorization credential request, the first electronic device issues a second application authorization credential and sends it to the second application.

[0222] Step 303: The first electronic device receives the second application permission request sent by the first application, and sends the second application permission scope to the first application.

[0223] Specifically, the first application may be the above-mentioned main application 111. The second application permission request is used to obtain the second application permission scope, and the second application permission scope may be the permission scope of the business access of the second application. The second application permission request includes the second application identity and the first application authorization credential, and the first application authorization credential is used to identify the business access credential of the first application. Therefore, the first electronic device can obtain the preset permission scope of the first application based on the first application authorization credential. Then, the first electronic device can query and obtain the corresponding second application permission scope based on the preset permission scope of the first application, wherein the second application permission scope may be the permission scope of the business access of the second application. Then, the first electronic device can store the second application permission scope after associating it with the second application identity information, and can send the second application permission scope to the first application.

[0224] Step 304: The first electronic device receives a verification request sent by the second electronic device.

[0225] Specifically, the second electronic device may be the aforementioned service server 200. The verification request is used to verify a service access request, which is initiated by a third electronic device to the second electronic device based on a second application, where the second application is invoked by a first application in the third electronic device. The verification request includes the second application's permission scope and the second application's server address information. The third electronic device may be the aforementioned terminal 100.

[0226] Step 305: The first electronic device verifies the second application authorization credential.

[0227] Optionally, the verification request may also carry a second application authorization credential, and the first electronic device may verify the second application authorization credential after receiving the verification request. The verification may be achieved by querying whether there is an authorization credential that is consistent with the second application authorization credential.

[0228] Step 306: The first electronic device performs verification based on the server address information of the second application.

[0229] Specifically, the first electronic device can perform a query based on the second application identity information to obtain the server address information of the second application corresponding to the second application identity information; then, the first electronic device compares the server address information of the second application obtained by the query with the server address information of the second application in the verification request to complete the verification of the server address information of the second application.

[0230] Step 307 : In response to the verification of the server address information of the second application being successful, the first electronic device performs permission verification based on the permission range of the second application.

[0231] Specifically, the first electronic device can query based on the second application identity information to obtain the second application permission range corresponding to the second application identity information; then, the first electronic device compares the second application permission range obtained by the query with the second application permission range in the verification request to complete the permission verification.

[0232] Step 308: In response to the permission verification being successful, the first electronic device returns a verification success message to the second electronic device, so that the second electronic device allows the second application in the third electronic device to access services based on the second application permission range.

[0233] Figure 8 This is a structural diagram of an embodiment of the service access device of this application, such as Figure 8 As shown, the service access device 80 may include: a receiving module 81, a first verification module 82, a second verification module 83 and a sending module 84;

[0234] a receiving module 81 configured to receive a verification request sent by a second electronic device, wherein the verification request is used to verify a service access request, the service access request being initiated by a third electronic device to the second electronic device based on a second application, the second application being called by a first application in the third electronic device, the verification request including the second application permission scope and server address information of the second application, the second application permission scope being used to identify the service access permission scope of the second application;

[0235] A first verification module 82, configured to perform verification based on the server address information of the second application;

[0236] A second verification module 83 is configured to perform permission verification based on the permission range of the second application in response to the verification of the server address information of the second application being successful;

[0237] The sending module 84 is configured to return a verification success message to the second electronic device in response to the permission verification being passed, so that the second electronic device allows the second application in the third electronic device to access services based on the second application permission range.

[0238] In a possible implementation, the verification request further includes the second application identity information, and the apparatus 80 further includes: a registration module 85;

[0239] The registration module 85 is used to receive a registration request from the second application, wherein the registration request includes the server address information of the second application; generate the second application identity information and the corresponding key, associate the server address information of the second application with the second application identity information and store them, and send the second application identity information and the key to the second application.

[0240] In a possible implementation, the first verification module 82 includes: a first query unit 821 and a first verification unit 822;

[0241] The first query unit 821 is configured to query based on the second application identity information to obtain the server address information of the second application corresponding to the identity information of the second application;

[0242] The first verification unit 822 is configured to compare the server address information of the second application obtained through the query with the server address information of the second application in the verification request to complete verification of the server address information of the second application.

[0243] In a possible implementation, the apparatus 80 further includes: an agent authority allocation module 86;

[0244] The proxy permission allocation module 86 is used to receive a second application permission request sent by the first application, wherein the second application permission request is used to obtain the second application permission scope, the second application permission scope includes the second application identity information and the first application authorization credential, and the first application authorization credential is used to identify the business access credential of the first application; based on the first application authorization credential query, obtain the preset permission scope of the first application, wherein the preset permission scope of the first application is used to identify the business access permission scope of the first application; based on the preset permission scope of the first application query, obtain the corresponding second application permission scope, associate the second application permission scope with the second application identity information and store it; and send the second application permission scope to the first application.

[0245] In a possible implementation, the second verification module 83 includes: a second query unit 831 and a second verification unit 832;

[0246] The second query unit 831 is configured to query based on the second application identity information to obtain a second application permission range corresponding to the second application identity information;

[0247] The second verification unit 832 is configured to compare the second application permission range obtained through the query with the second application permission range in the verification request to complete the permission verification.

[0248] In a possible implementation, the apparatus 80 further includes: a proxy credential allocation module 87;

[0249] The proxy credential allocation module 87 is used to receive a second application authorization credential request from a second application, wherein the second application authorization credential request is used to obtain a second application authorization credential, the second application authorization credential is used to identify the business access credential of the second application, and the second application authorization credential request includes the second application identity information and a key; perform a query based on the second application identity information to obtain a key corresponding to the second application identity information; compare the key obtained from the query with the key in the second application authorization credential request, and in response to the key obtained from the query being consistent with the key in the second authorization credential request, issue a second application authorization credential and send the second application authorization credential to the second application.

[0250] In a possible implementation, the apparatus 80 further includes: a third verification module 88;

[0251] The third verification module 88 is used to query whether there is an authorization credential that is consistent with the second application authorization credential, so as to complete the verification of the second application authorization credential.

[0252] It should be understood that the above Figure 8 The division of the various modules of the service access device shown is merely a division of logical functions. In actual implementation, they can be fully or partially integrated into a single physical entity, or physically separated. Furthermore, these modules can be implemented entirely in the form of software called through a processing element; or entirely in the form of hardware; or some modules can be implemented in the form of software called through a processing element, and some modules can be implemented in the form of hardware. For example, the detection module can be a separate processing element, or it can be integrated into a chip of an electronic device. The implementation of other modules is similar. Furthermore, these modules can be fully or partially integrated together, or implemented independently. During implementation, each step of the above method or each of the above modules can be completed by hardware integrated logic circuits in the processor element or by software instructions.

[0253] For example, the above modules may be one or more integrated circuits configured to implement the above methods, such as one or more application-specific integrated circuits (ASICs), one or more digital signal processors (DSPs), or one or more field programmable gate arrays (FPGAs). For another example, these modules may be integrated together to implement a system-on-a-chip (SOC).

[0254] Figure 9This is a structural diagram of an embodiment of the electronic device 900 of the present application, wherein the authentication server 300 may be the electronic device 900; Figure 9 As shown, the electronic device 900 can be a data processing device or a circuit device built into the data processing device. The electronic device 900 can be used to execute the present application. Figure 1-Figure 7 The illustrated embodiments provide functions / steps in the method.

[0255] like Figure 9 As shown, the first electronic device 900 is in the form of a general-purpose computing device.

[0256] The first electronic device 900 may include: one or more processors 910; a communication interface 920; a memory 930; a communication bus 940 connecting different system components (including the memory 930 and the processor 910), a database 950; and one or more computer programs.

[0257] The one or more computer programs are stored in the memory, and the one or more computer programs include instructions. When the instructions are executed by the first electronic device, the first electronic device performs the following steps:

[0258] receiving a verification request sent by a second electronic device, wherein the verification request is used to verify a service access request, the service access request is initiated by a third electronic device to the second electronic device based on a second application, the second application is called by a first application in the third electronic device, the verification request includes a permission scope of the second application and server address information of the second application, the second application permission scope is used to identify a service access permission scope of the second application;

[0259] Verifying based on the server address information of the second application;

[0260] In response to the verification of the server address information of the second application being successful, performing permission verification based on the permission scope of the second application;

[0261] In response to the permission verification being successful, a verification success message is returned to the second electronic device, so that the second electronic device allows the second application in the third electronic device to access services based on the second application permission range.

[0262] In one possible implementation, the verification request also includes the second application identity information. When the instruction is executed by the first electronic device, the first electronic device further performs the following steps before receiving the verification request sent by the second electronic device:

[0263] receiving a registration request from a second application, wherein the registration request includes server address information of the second application;

[0264] Generate second application identity information and a corresponding key, associate the server address information of the second application with the second application identity information and store them, and send the second application identity information and the key to the second application.

[0265] In one possible implementation, when the instruction is executed by the first electronic device, the step of causing the first electronic device to perform verification based on the server address information of the second application includes:

[0266] Perform a query based on the second application identity information to obtain server address information of the second application corresponding to the second application identity information;

[0267] The server address information of the second application obtained by the query is compared with the server address information of the second application in the verification request to complete the verification of the server address information of the second application.

[0268] In one possible implementation, when the instruction is executed by the first electronic device, the first electronic device further performs the following steps before receiving the verification request sent by the second electronic device:

[0269] A second application permission request sent by the first application, where the second application permission request is used to obtain a second application permission scope, the second application permission scope includes the second application identity information and the first application authorization credential, and the first application authorization credential is used to identify the service access credential of the first application;

[0270] Obtaining a preset permission range of the first application based on the first application authorization credential query, wherein the preset permission range of the first application is used to identify the permission range of the service access of the first application;

[0271] The corresponding second application permission range is queried based on the preset permission range of the first application, the second application permission range is associated with the second application identity information and then stored, and the second application permission range is sent to the first application.

[0272] In one possible implementation, when the instruction is executed by the first electronic device, the step of causing the first electronic device to perform permission verification based on the second application permission range includes:

[0273] Perform a query based on the second application identity information to obtain a second application permission range corresponding to the second application identity information;

[0274] The second application permission range obtained by the query is compared with the second application permission range in the verification request to complete the permission verification.

[0275] In one possible implementation, when the instruction is executed by the first electronic device, the first electronic device executes the following steps after sending the second application identity information and key to the second application:

[0276] receiving a second application authorization credential request from the second application, wherein the second application authorization credential request is used to obtain the second application authorization credential, the second application authorization credential is used to identify the service access credential of the second application, and the second application authorization credential request includes the second application identity information and key;

[0277] Perform a query based on the second application identity information to obtain a key corresponding to the second application identity information;

[0278] The key obtained by the query is compared with the key in the second application authorization credential request. In response to the key obtained by the query being consistent with the key in the second authorization credential request, a second application authorization credential is issued and sent to the second application.

[0279] In one possible implementation, the verification request also includes a second application authorization credential. When the instruction is executed by the first electronic device, the first electronic device further performs the following steps before performing the verification based on the server address information of the second application:

[0280] Check whether there is an authorization credential that is consistent with the second application authorization credential to complete the verification of the second application authorization credential.

[0281] It is understood that the interface connection relationship between the modules illustrated in the embodiment of the present invention is merely an illustrative illustration and does not constitute a structural limitation on the first electronic device 900. In other embodiments of the present application, the first electronic device 900 may also adopt a different interface connection method from the above embodiment, or a combination of multiple interface connection methods.

[0282] It is understandable that, in order to realize the above functions, the above-mentioned electronic devices and the like include hardware structures and / or software modules corresponding to the execution of each function. Those skilled in the art should easily realize that, in combination with the units and algorithm steps of each example described in the embodiments disclosed herein, the embodiments of the present application can be implemented in the form of hardware or a combination of hardware and computer software. Whether a function is executed in the form of hardware or computer software driving hardware depends on the specific application and design constraints of the technical solution. Professional and technical personnel can use different methods to implement the described functions for each specific application, but such implementation should not be considered to exceed the scope of the embodiments of the present invention.

[0283] The embodiment of the present application can divide the functional modules of the above-mentioned electronic device etc. according to the above-mentioned method example. For example, each functional module can be divided corresponding to each function, or two or more functions can be integrated into one processing module. The above-mentioned integrated module can be implemented in the form of hardware or in the form of software functional modules. It should be noted that the division of modules in the embodiment of the present invention is schematic and is only a logical function division. There may be other division methods in actual implementation.

[0284] Through the description of the above embodiments, those skilled in the art will clearly understand that for the sake of convenience and brevity, only the division of the above functional modules is used as an example. In actual applications, the above functions can be assigned to different functional modules as needed, that is, the internal structure of the device can be divided into different functional modules to complete all or part of the functions described above. The specific working processes of the above-described systems, devices, and units can refer to the corresponding processes in the aforementioned method embodiments and will not be repeated here.

[0285] The functional units in the various embodiments of the present application may be integrated into a single processing unit, or each unit may exist physically separately, or two or more units may be integrated into a single unit. The aforementioned integrated units may be implemented in the form of hardware or software functional units.

[0286] If the integrated unit is implemented in the form of a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of the embodiment of the present application is essentially or the part that contributes to the prior art or all or part of the technical solution can be embodied in the form of a software product, and the computer software product is stored in a storage medium, including a number of instructions for enabling a computer device (which can be a personal computer, a server, or a network device, etc.) or a processor to perform all or part of the steps of the method described in each embodiment of the present application. The aforementioned storage medium includes: various media that can store program codes, such as flash memory, mobile hard disk, read-only memory, random access memory, magnetic disk or optical disk.

[0287] The above is only a specific embodiment of the present application, but the scope of protection of this application is not limited to this. Any changes or substitutions within the technical scope disclosed in this application should be included in the scope of protection of this application. Therefore, the scope of protection of this application should be based on the scope of protection of the claims.

Claims

1. A service access method, applied to a first electronic device, characterized in that: The method comprises: receiving a verification request sent by a second electronic device, wherein the verification request is used to verify a service access request, the service access request is initiated by a third electronic device to the second electronic device based on a second application, the second application is called by a first application in the third electronic device, the verification request includes a second application permission scope and server address information of the second application, the second application permission scope is used to identify a service access permission scope of the second application; Verifying based on the server address information of the second application; In response to the verification of the server address information of the second application being successful, performing permission verification based on the permission scope of the second application; In response to the permission verification being successful, returning a verification success message to the second electronic device, so that the second electronic device allows the second application in the third electronic device to access services based on the permission scope of the second application; Before receiving the verification request sent by the second electronic device, the method further includes: receiving a second application permission request sent by the first application, wherein the second application permission request is used to obtain a second application permission scope, the second application permission request includes second application identity information and first application authorization credentials, and the first application authorization credentials are used to identify service access credentials of the first application; Obtaining a preset permission scope of the first application based on the first application authorization credential query; Based on the preset permission scope of the first application, a corresponding second application permission scope is queried and obtained, the second application permission scope is associated with the second application identity information and stored, and the second application permission scope is sent to the first application.

2. The method according to claim 1, characterized in that The verification request also includes second application identity information. Before receiving the verification request sent by the second electronic device, the method further includes: receiving a registration request from the second application, wherein the registration request includes server address information of the second application; Generate second application identity information and a corresponding key, associate the server address information of the second application with the second application identity information and store them, and send the second application identity information and the key to the second application.

3. The method according to claim 1, characterized in that The verification based on the server address information of the second application includes: Performing a query based on the second application identity information to obtain server address information of the second application corresponding to the second application identity information; The server address information of the second application obtained by the query is compared with the server address information of the second application in the verification request to complete the verification of the server address information of the second application.

4. The method according to any one of claims 1 to 3, characterized in that The performing permission verification based on the second application permission range includes: Performing a query based on the second application identity information to obtain a second application permission scope corresponding to the second application identity information; The second application permission range obtained by the query is compared with the second application permission range in the verification request to complete the permission verification.

5. The method according to claim 2, characterized in that After sending the second application identity information and the key to the second application, the method further includes: receiving a second application authorization credential request sent by the second application, wherein the second application authorization credential request is used to obtain a second application authorization credential, the second application authorization credential is used to identify the service access credential of the second application, and the second application authorization credential request includes the second application identity information and key; Perform a query based on the second application identity information to obtain a key corresponding to the second application identity information; The key obtained by the query is compared with the key in the second application authorization credential request. In response to the key obtained by the query being consistent with the key in the second application authorization credential request, the second application authorization credential is issued and sent to the second application.

6. The method according to claim 5, characterized in that The verification request also includes a second application authorization credential. Before performing the verification based on the server address information of the second application, the following steps are also included: Check whether there is an authorization credential that is consistent with the second application authorization credential to complete the verification of the second application authorization credential.

7. A first electronic device, characterized in that: include: A memory, the memory being configured to store computer program code, the computer program code including instructions, and when the first electronic device reads the instructions from the memory, causing the first electronic device to perform the following steps: receiving a verification request sent by a second electronic device, wherein the verification request is used to verify a service access request, the service access request is initiated by a third electronic device to the second electronic device based on a second application, the second application is called by a first application in the third electronic device, the verification request includes a second application permission scope and server address information of the second application, the second application permission scope is used to identify a service access permission scope of the second application; Verifying based on the server address information of the second application; In response to the verification of the server address information of the second application being successful, performing permission verification based on the permission scope of the second application; In response to the permission verification being successful, returning a verification success message to the second electronic device, so that the second electronic device allows the second application in the third electronic device to access services based on the permission scope of the second application; Before receiving the verification request sent by the second electronic device, the method further includes: receiving a second application permission request sent by the first application, wherein the second application permission request is used to obtain a second application permission scope, the second application permission request includes second application identity information and first application authorization credentials, and the first application authorization credentials are used to identify service access credentials of the first application; Obtaining a preset permission scope of the first application based on the first application authorization credential query; Based on the preset permission scope of the first application, a corresponding second application permission scope is queried and obtained, the second application permission scope is associated with the second application identity information and stored, and the second application permission scope is sent to the first application.

8. The first electronic device according to claim 7, characterized in that: The verification request also includes second application identity information. When the instruction is executed by the first electronic device, the first electronic device further performs the following steps before performing the step of receiving the verification request sent by the second electronic device: receiving a registration request from the second application, wherein the registration request includes server address information of the second application; Generate second application identity information and a corresponding key, associate the server address information of the second application with the second application identity information and store them, and send the second application identity information and the key to the second application.

9. The first electronic device according to claim 7, wherein: When the instruction is executed by the first electronic device, the step of causing the first electronic device to perform verification based on the server address information of the second application includes: Performing a query based on the second application identity information to obtain server address information of the second application corresponding to the second application identity information; The server address information of the second application obtained by the query is compared with the server address information of the second application in the verification request to complete the verification of the server address information of the second application.

10. The first electronic device according to any one of claims 7 to 9, characterized in that: When the instruction is executed by the first electronic device, the step of causing the first electronic device to perform permission verification based on the second application permission range includes: Performing a query based on the second application identity information to obtain a second application permission scope corresponding to the second application identity information; The second application permission range obtained by the query is compared with the second application permission range in the verification request to complete the permission verification.

11. The first electronic device according to claim 8, characterized in that: When the instruction is executed by the first electronic device, the first electronic device executes the following steps after executing the step of sending the second application identity information and the key to the second application: receiving a second application authorization credential request sent by the second application, wherein the second application authorization credential request is used to obtain a second application authorization credential, the second application authorization credential is used to identify the service access credential of the second application, and the second application authorization credential request includes the second application identity information and key; Perform a query based on the second application identity information to obtain a key corresponding to the second application identity information; The key obtained by the query is compared with the key in the second application authorization credential request. In response to the key obtained by the query being consistent with the key in the second application authorization credential request, the second application authorization credential is issued and sent to the second application.

12. The first electronic device according to claim 11, characterized in that: The verification request also includes a second application authorization credential. When the instruction is executed by the first electronic device, the first electronic device further performs the following steps before performing the step of verifying based on the server address information of the second application: Check whether there is an authorization credential that is consistent with the second application authorization credential to complete the verification of the second application authorization credential.

13. A computer-readable storage medium, characterized in that The method comprises computer instructions, which, when executed on the first electronic device, enable the first electronic device to execute the service access method according to any one of claims 1 to 6.

14. A computer program product, characterized in that When the computer program product is run on a computer, the computer is enabled to execute the service access method according to any one of claims 1 to 6.

Images