CN114579951A

CN114579951A - Service access method, electronic device and storage medium

Info

Publication number: CN114579951A
Application number: CN202011285861.0A
Authority: CN
Inventors: 罗振辉
Original assignee: Petal Cloud Technology Co Ltd
Current assignee: Petal Cloud Technology Co Ltd
Priority date: 2020-11-17
Filing date: 2020-11-17
Publication date: 2022-06-03

Abstract

The embodiment of the application provides a service access method, electronic equipment and a storage medium, which relate to the technical field of communication, and the method comprises the following steps: receiving a verification request sent by second electronic equipment, and verifying based on server address information of a second application; in response to the verification of the server address information of the second application passing, performing authority verification based on the authority range of the second application; and responding to the permission verification, returning a verification success message to the second electronic equipment, so that the second electronic equipment allows the second application in the third electronic equipment to perform service access based on the second application permission range. The method provided by the embodiment of the application can degrade the authority of the proxy application, and avoids potential safety hazards caused by service access of the proxy application, so that the safety of personal data of a user is ensured.

Description

Service access method, electronic device and storage medium

Technical Field

The embodiment of the application relates to the technical field of communication, in particular to a service access method, electronic equipment and a storage medium.

Background

Currently, the Open Authentication (OAUTH) protocol provides a secure, Open and simple standard for Authorization of user resources. The difference from the former authorization mode is that the authorization of the OAUTH protocol does not make the third party reach the account information (such as user name and password) of the user, that is, the third party can apply for the authorization of the user resource without using the user name and password. The OAUTH protocol also provides an authentication mode between the servers based on a network check code (Json Web Token, JWT) mode.

Disclosure of Invention

The embodiment of the application provides a service access method, electronic equipment and a storage medium, so as to provide a mode for degrading application permission.

In a first aspect, an embodiment of the present application provides a service access method, which is applied to a first electronic device, and includes:

receiving a verification request sent by second electronic equipment, wherein the verification request is used for verifying a service access request, the service access request is initiated to the second electronic equipment by third electronic equipment based on second application, the second application is called by first application in the third electronic equipment, the verification request comprises a second application permission range and server address information of the second application, and the second application permission range is used for identifying the permission range of service access of the second application; specifically, the first electronic device may be an authentication server, and the authentication server is configured to verify a service access request; the second electronic device may be a business server for servicing access to the proxy application; the third electronic device may be a terminal, and the terminal may include a mobile device such as a mobile phone and a tablet. The first application may be a primary application and the second application may be a proxy application.

The authentication is performed based on the server address information of the second application.

And in response to the verification of the server address information of the second application passing, performing authority verification based on the authority range of the second application.

And responding to the permission verification, returning a verification success message to the second electronic equipment, so that the second electronic equipment allows the second application in the third electronic equipment to perform service access based on the second application permission range.

In the embodiment, the proxy authority is pre-distributed to the proxy application through the authentication server to distinguish the main authority of the main application, the user calls the proxy application in the main application to initiate the service access request, the service access request carries proxy authority information, and the authentication server performs authority verification based on the proxy authority information, so that the service authority of the proxy application can be degraded, and the safety of personal data of the user is further ensured.

In one possible implementation manner, the authentication request further includes second application identity information, and before receiving the authentication request sent by the second electronic device, the method further includes: receiving a registration request of a second application, wherein the registration request comprises server address information of the second application; and generating second application identity information and a corresponding secret key, associating and storing the server address information of the second application with the second application identity information, and sending the second application identity information and the secret key to the second application. Specifically, the server address information may include server address information corresponding to the second application. The identity information may be an identity of the second application, and the identity 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, which is not particularly limited in this embodiment of the present application.

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

In one possible implementation manner, the verifying based on the server address information of the second application includes: inquiring based on the second application identity information to obtain server address information of the second application corresponding to the second application identity information; and comparing the server address information of the second application obtained by inquiry 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.

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, and the security is improved.

In one possible implementation manner, 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 for acquiring a second application permission range, the second application permission request comprises second application identity information and a first application authorization credential, and the first application authorization credential is used for identifying a business access credential of the first application; in particular, the second application permission range may include a service access range of the second application. Inquiring and obtaining a preset authority range of the first application based on the first application authorization credential, wherein the preset authority range of the first application is used for identifying the authority range of the business access of the first application; and inquiring to obtain a corresponding second application authority range based on the preset authority range of the first application, associating and storing the second application authority range and the second application identity information, and sending the second application authority range to the first application. In particular, the second application permission range may include a service access range of the second application. Then, the second application permission range is sent to the first application.

In this embodiment, by acquiring the service access range of the first application, querying the service access range of the second application based on the service access range of the first application, and sending the service access range of the second application to the first application, the first application can call the service access range of the second application when calling the second application, so that the permission degradation of the second application can be realized, and the security is further improved.

In one possible implementation manner, performing permission verification based on the second application permission range includes: querying based on the second application identity information to obtain a second application permission range corresponding to the second application identity information; and comparing the second application permission range obtained by the query with the second application permission range in the verification request to complete permission verification.

In this embodiment, the second application permission range in the verification request is compared with the locally stored second application permission range to complete permission verification of the proxy permission of the second application, so that security can be improved.

In one possible implementation manner, after sending the second application identity information and the secret key to the second application, the method further includes: receiving a second application authorization credential request of a second application, wherein the second application authorization credential request is used for obtaining a second application authorization credential, the second application authorization credential is used for identifying a business access credential of the second application, and the second application authorization credential request includes second application identity information and a secret key; specifically, the second application authorization credential request carries the identity information of the second application and the corresponding key, and since the identity information of the second application and the corresponding key are distributed by the first electronic device, the security can be improved by verifying the identity information of the second application and the corresponding key. Querying based on the second application identity information to obtain a secret key corresponding to the second application identity information; and comparing the key obtained by inquiry with the key in the second application authorization credential request, issuing the second application authorization credential in response to the fact that the key obtained by inquiry is consistent with the key in the second application authorization credential request, and sending the second application authorization credential to the second application. In particular, after the key verification is passed, the second application authorization credential is issued to the second application, so that the security can be improved.

In one possible implementation manner, the verification request further includes a second application authorization credential, and before performing verification based on server address information of the second application, the method further includes: and inquiring whether an authorization credential consistent with the second application authorization credential exists or not so as to complete the verification of the second application authorization credential. Specifically, before the server address information of the second application is verified, the authorization credential of the second application is further verified, so that the security can be improved.

In a second aspect, an embodiment of the present application provides a service access apparatus, including:

the receiving module is used for receiving a verification request sent by second electronic equipment, wherein the verification request is used for verifying a service access request, the service access request is initiated to the second electronic equipment by third electronic equipment based on second application, the second application is called by first application in the third electronic equipment, the verification request comprises a second application permission range and server address information of the second application, and the second application permission range is used for identifying the permission range of service access of the second application;

the first verification module is used for verifying based on the server address information of the second application;

the second verification module is used for responding to the verification of the server address information of the second application and performing authority verification based on the authority range of the second application;

and the sending module is used for responding to the permission verification, returning a verification success message to the second electronic equipment, so that the second electronic equipment allows the second application in the third electronic equipment to perform service access based on the second application permission range.

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

the registration module is used for receiving a registration request of a second application, wherein the registration request comprises server address information of the second application; and generating second application identity information and a corresponding secret key, associating and storing the server address information of the second application with the second application identity information, and sending the second application identity information and the secret key to the second application.

In one possible implementation manner, the first verification module includes:

the first query unit is used for querying based on the second application identity information to obtain server address information of the second application corresponding to the second application identity information;

and the first verification unit is used for comparing the server address information of the second application obtained by inquiry with the server address information of the second application in the verification request so as to finish the verification of the server address information of the second application.

In one possible implementation manner, the apparatus further includes:

the agent permission distribution module is used for receiving a second application permission request sent by the first application, wherein the second application permission request is used for acquiring a second application permission range, the second application permission range comprises second application identity information and a first application authorization credential, and the first application authorization credential is used for identifying a business access credential of the first application; inquiring and obtaining a preset authority range of the first application based on the first application authorization credential, wherein the preset authority range of the first application is used for identifying the authority range of the business access of the first application; inquiring and acquiring a corresponding second application authority range based on a preset authority range of the first application, and associating and storing the second application authority range and second application identity information; and sending the second application permission range to the first application.

In one possible implementation manner, the second verification module includes:

the second query unit is used for querying based on the second application identity information to obtain a second application authority range corresponding to the second application identity information;

and the second verification unit is used for comparing the second application authority range obtained by the query with the second application authority range in the verification request so as to complete the authority verification.

In one possible implementation manner, the apparatus further includes:

the agent credential allocation module is configured to receive a second application authorization credential request of a second application, where the second application authorization credential request is used to obtain a second application authorization credential, the second application authorization credential is used to identify a service access credential of the second application, and the second application authorization credential request includes second application identity information and a secret key; inquiring based on the second application identity information to obtain a secret key corresponding to the second application identity information; and comparing the key obtained by inquiry with the key in the second application authorization credential request, issuing the second application authorization credential in response to the fact that the key obtained by inquiry is consistent with the key in the second authorization credential request, and sending the second application authorization credential to the second application.

In one possible implementation manner, the apparatus further includes:

and the third verification module is used for inquiring whether the authorization credential consistent with the second application authorization credential exists so as to complete the verification of the second application authorization credential.

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

a memory, where the memory is used to store computer program codes, where the computer program codes include instructions, and when the first electronic device reads the instructions from the memory, the first electronic device is caused to execute the following steps:

receiving a verification request sent by second electronic equipment, wherein the verification request is used for verifying a service access request, the service access request is initiated to the second electronic equipment by third electronic equipment based on second application, the second application is called by first application in the third electronic equipment, the verification request comprises a second application permission range and server address information of the second application, and the second application permission range is used for identifying the permission range of service access of the second application;

performing verification based on server address information of the second application;

performing authority verification based on the second application authority range in response to the verification of the server address information of the second application passing;

and responding to the permission verification passing, and returning a verification success message to the second electronic equipment, so that the second electronic equipment allows the second application in the third electronic equipment to perform service access based on the second application permission range.

In one possible implementation manner, the verification request further includes second application identity information, and when the instruction is executed by the first electronic device, before the first electronic device performs the step of receiving the verification request sent by the second electronic device, the following steps are further performed:

receiving a registration request of a second application, wherein the registration request comprises server address information of the second application;

and generating second application identity information and a corresponding secret key, associating and storing the server address information of the second application and the second application identity information, and sending the second application identity information and the secret key to the second application.

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

inquiring based on the second application identity information to obtain server address information of the second application corresponding to the second application identity information;

and comparing the server address information of the second application obtained by inquiry 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.

In one possible implementation manner, when the instruction is executed by the first electronic device, before the first electronic device performs the step of receiving the verification request sent by the second electronic device, the following steps are further performed:

a second application permission request sent by the first application, wherein the second application permission request is used for acquiring a second application permission range, the second application permission range comprises second application identity information and a first application authorization credential, and the first application authorization credential is used for identifying a business access credential of the first application;

inquiring and obtaining a preset authority range of the first application based on the first application authorization credential, wherein the preset authority range of the first application is used for identifying the authority range of the business access of the first application;

and inquiring to obtain a corresponding second application authority range based on the preset authority range of the first application, associating and storing the second application authority range and the second application identity information, and sending the second application authority range to the first application.

In one possible implementation manner, when the instruction is executed by the first electronic device, the step of enabling the first electronic device to perform permission verification based on a second application permission range includes:

querying based on the second application identity information to obtain a second application permission range corresponding to the second application identity information;

and comparing the second application permission range obtained by the query with the second application permission range in the verification request to complete permission verification.

In one possible implementation manner, when the instruction is executed by the first electronic device, after the first electronic device executes the step of sending the second application identity information and the key to the second application, the following step is further executed:

receiving a second application authorization credential request of a second application, wherein the second application authorization credential request is used for obtaining a second application authorization credential, the second application authorization credential is used for identifying a business access credential of the second application, and the second application authorization credential request includes second application identity information and a secret key;

inquiring based on the second application identity information to obtain a secret key corresponding to the second application identity information;

and comparing the key obtained by inquiry with the key in the second application authorization credential request, issuing the second application authorization credential in response to the fact that the key obtained by inquiry is consistent with the key in the second authorization credential request, and sending the second application authorization credential to the second application.

In one possible implementation manner, the verification request further includes a second application authorization credential, and when the instruction is executed by the first electronic device, before the first electronic device performs the step of performing verification based on the server address information of the second application, the following steps are further performed:

and inquiring whether an authorization credential consistent with the second application authorization credential exists or not so as to complete the verification of the second application authorization credential.

In a fourth aspect, embodiments of the present application provide a computer-readable storage medium having stored thereon a computer program, which, when run on a computer, causes the computer to perform the method according to the first aspect.

In a fifth aspect, embodiments of the present application provide a computer program, which is configured to perform the method according to the first aspect when the computer program is executed by a computer.

In a possible design, the program of the fifth aspect may be stored in whole or in part on a storage medium packaged with the processor, or in part or in whole on a memory not packaged with the processor.

Drawings

Fig. 1 is a schematic diagram of an application scenario architecture provided in an embodiment of the present application;

fig. 2A is a schematic diagram of a terminal display interface according to an embodiment provided in the present application;

fig. 2B is a schematic diagram of a terminal display interface according to another embodiment provided in the present application;

fig. 2C is a schematic diagram of a terminal display interface according to still another embodiment of the present application;

fig. 3 is a schematic flowchart of a service access method according to an embodiment of the present application;

fig. 4 is a schematic diagram of a packet format of a service access request according to an embodiment of the present application;

fig. 5 is a schematic flowchart of a service access method according to another embodiment of the present application;

fig. 6 is a schematic diagram of a packet format of a service access request according to another embodiment of the present application;

fig. 7 is a schematic flowchart of a service access method according to still another embodiment of the present application;

fig. 8 is a schematic structural diagram of a service access device according to an embodiment of the present application;

fig. 9 is a schematic structural diagram of an electronic device according to an embodiment of the present application.

Detailed Description

The technical solutions in the embodiments of the present application will be described below with reference to the drawings in the embodiments of the present application. In the description of the embodiments herein, "/" means "or" unless otherwise specified, for example, a/B may mean a or B; "and/or" herein is merely an association relationship describing an associated object, and means that there may be three relationships, for example, a and/or B, and may mean: a exists alone, A and B exist simultaneously, and B exists alone.

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

After a user opens an application program on a terminal, the user can log in through a personal account number, so that the application program can be authorized, and the application program can acquire personal data of the user according to the service authority authorized by the user. For convenience of explanation, the application program is hereinafter referred to as a main application. When a user calls a third-party application (hereinafter referred to as a proxy application) through the host application, for example, after the user opens one host application (e.g., a meal ordering application), the user may call the proxy application (e.g., a payment application) to make a payment; the proxy application shares the service authority authorized by the user with the main application, so that all personal data of the user can be acquired. However, the agent application may only need a part of the personal data to complete the current service, for example, the payment application only needs the personal information such as the bank account of the user to complete the payment service in the payment process, and does not need other personal information.

The embodiment of the application provides a service access method, and the method is used for providing a mode for carrying out permission degradation on the service permission of the proxy application, so that permission degradation on the service permission of the proxy application is realized when the proxy application is called in the main application for carrying out service access, and therefore potential safety hazards caused by the fact that the proxy application has the same service permission as the main application can be avoided, the safety of personal data of a user is guaranteed, and further the loss of the user can be avoided.

The technical scheme provided by the embodiment of the application can be applied to data processing equipment, the data processing equipment can be a server, and the specific form of the data processing equipment for executing the technical scheme is not particularly limited.

The service access method provided by the embodiment of the present application is now described with reference to fig. 1 to 7.

Fig. 1 is a diagram illustrating an application scenario architecture of the service access method of the present application. Referring to fig. 1, a terminal 100 may communicate with a service server 200 and an authentication server 300, respectively. The service server 200 is configured to provide services (e.g., a meal order service, a car calling service, etc.) corresponding to the main application and services (e.g., a payment service) corresponding to the agent application, respectively, so as to realize service access initiated by a user through the main application and the agent application. The authentication server 300 may be used to register the master application and the proxy application, respectively, and to authorize and verify the service rights of the master application and the proxy application, respectively.

As shown in fig. 2A, the display interface 110 of the terminal 100 may include various types of host applications 111, and the user may operate the host applications 111 on the display interface 110 of the terminal 100. For example, the user may click on a music master icon on the display interface 110 of the terminal 100 to open a music master, and thereby may obtain the display interface 120 as shown in fig. 2B to complete service access to the music master. Referring to fig. 2B, the display interface 120 displays a page corresponding to the music master application. Various proxy applications 112 are also included in the display interface 120, and a user can operate the proxy applications 112 on the display interface 120 of the terminal 100. Illustratively, the user may click on the album purchase link in the display interface 120 to invoke the payment interface, whereby the display interface 120 may jump to a page corresponding to the album purchase payment (e.g., the display interface 130 shown in fig. 2C), and in the display interface 130, the user may verify the album purchase by password or by fingerprint to complete the album purchase service.

Fig. 3 is a flowchart illustrating an embodiment of a service access method according to the present application, including:

at step 101, the proxy application 112 sends a registration request to the authentication server 300.

Specifically, the agent application 112 may be a third party application that is invoked in the host application 111, and the agent application 112 may be, for example, an invoked payment application; the agent application 112 may also be other called third-party applications, which is not particularly limited in the embodiment of the present application. The main application 111 may be an application installed by the user on the terminal 100, and for example, the main application 111 may include a social application, a meal ordering application, an e-commerce application, and the like; the host application 111 may also be another application installed on the terminal 100 through a program installation package, and this embodiment of the present application is not particularly limited in this respect. The terminal 100 may be a mobile phone, a tablet, or other device having a communication function. The authentication server 300 may be a server for registering the master application 111 and the agent application 112, and issuing authorization credentials and verification for the business authority of the master application 111 and the agent application 112.

The proxy application 112 may register with the authentication server 300 via a registration interface, and the proxy application 112 may send a registration request to the authentication server 300 via the registration interface, for example. The registration request may include an application type and a server address. The application type may be used to identify the type of the proxy application 112, for example, the type of the proxy application 112 may be set to the proxy application type. The server address is used to identify an address of a server of the proxy application 112, and in a specific implementation, the address of the server may be identified by a server IP address or a domain name, where the number of the IP addresses may be one or more, and the application is not limited thereto.

Taking the rfc7591 protocol as an example, a registration interface of the protocol may be modified to send the registration request to complete registration of the proxy application 112 on the authentication server 300, and obtain the following example codes:

the newly added field client _ type is used for identifying the application type, and the newly added field source is used for identifying the server address. Registration of the proxy application 112 on the authentication server 300 may thus be accomplished, and the registration information of the proxy application 112 may include the application type and the server address.

At step 102, the authentication server 300 generates an identity and a key for the proxy application 112 based on the registration request.

Specifically, after receiving the registration request of the proxy application 112, the authentication server 300 may allocate an identity and a key to the proxy application 112, and the process of allocating the identity and the key may specifically refer to the oauth2.0 protocol, which is not described herein again. The agent application identity may be used to identify the identity of the agent application 112, that is, the agent application identity may be used to identify the agent application 112. The proxy application key may be a symmetric or asymmetric key commonly used in the art, which is not particularly limited in this embodiment of the application.

It is understood that the authentication server 300 may also store the identity, the key, and the server address of the proxy application 112, for example, the authentication server 300 may store the identity, the key, and the server address of the proxy application 112 in a local database after associating them.

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

At step 104, the master application 111 sends a registration request to the authentication server 300.

In particular, the amount of the solvent to be used,

the master application 111 may also register with the authentication server 300 through a registration interface, for example, through an original registration interface of the rfc7591 protocol, and the code is exemplified as follows:

in step 105, the authentication server 300 generates an identity and a key of the master application 111 based on the registration request.

Specifically, after receiving the registration request of the master application 111, the authentication server 300 may allocate an identity and a key to the master application 111, and the process of allocating the identity and the key may specifically refer to the oauth2.0 protocol, which is not described herein again. The primary application identity may be used to identify the identity of the primary application 111, that is, the primary application identity may be used to identify the primary application 111. The master application key may be a symmetric key or an asymmetric key commonly used in the art, which is not particularly limited in this embodiment. .

Further, the authentication server 300 may further store the identity and the key of the master application 111, for example, the authentication server 300 stores the identity and the key of the master application 111 in a local database.

In step 106, the authentication server 300 returns the identity and the key of the master application 111 to the master application 111.

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

In particular, the master authorization credential is used to identify the business rights of the master application 111. The master authorization credential request includes an identity and a key of the master application 111.

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

Specifically, after receiving the master authorization credential request of the master application 111, the authentication server 300 may perform verification based on the identity and the key of the master application 111 in the authorization credential request, for example, the authentication server 300 may compare the identity and the key of the master application 111 with the identity and the key corresponding to the master application 111 stored in the local database, and if the comparison is consistent, the verification passes. For example, the local database may be queried based on the identity of the master application 111 in the master authorization credential request to obtain a key corresponding to the identity of the master application 111, and if the key of the master application 111 in the master authorization credential request is consistent with the key of the master application 111 stored in the local database, the verification is passed. At this time, the authentication server 300 may issue a master authorization credential corresponding to the master application 111 and may transmit the master authorization credential to the master application 111. In addition, the authentication server 300 may further store the master authorization credential, so that the authentication server 300 may verify the validity of the master authorization credential after receiving a request (e.g., a proxy authorization credential request or a service access request) carrying the master authorization credential, thereby improving the security of data transmission.

It is understood 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, and if the master authorization credential exceeds the validity period, the master authorization credential is disabled.

In step 109, the master application 111 requests proxy rights from the authentication server 300.

In particular, the proxy permissions are used to identify a scope of business permissions for the proxy application 112.

The master application 111 may send a proxy right request to the authentication server 300 to obtain the proxy right. The proxy permission request may include, among other things, the permission type, the identity of proxy application 112, and the master authorization credential.

Taking the rfc6749 protocol as an example, the authorization interface of the protocol may be modified to send a proxy permission request, resulting in the following example codes:

POST/token HTTP/1.1

Host:server.example.com

Authorization:Bearer czZCaGRSa3F0MzpnWDFmQmF0M2JW

Content-Type:application/x-www-form-urlencoded

grant_type＝authorization_proxy_token&&proxy_client_id＝xxx

wherein, a Bearer type is added in the field Authorization, and the Bearer type is used for identifying the master Authorization credential of the master application 111; the field grant _ type is added with an authorization _ proxy _ token type, the authorization _ proxy _ token type is used for identifying that the authority type in the proxy authority request is proxy authority, and the field proxy _ client _ id is added with an identity used for identifying the proxy application 112.

In step 110, the authentication server 300 issues the proxy right based on the proxy right request of the host application 111, and sends the proxy right to the host application 111.

Specifically, after receiving the proxy permission request from the master application 111, the authentication server 300 may verify the validity of the master authorization credential. For example, the authentication server 300 may query whether there is an authorization credential that is consistent with the master authorization credential in the proxy authorization credential request. If there is an authorization credential consistent with the master authorization credential in the proxy authorization credential request, the master authorization credential may be considered to be issued by the authentication server 300, that is, the master authorization credential is legal, a range of the preset business authority corresponding to the master application 111 may be obtained based on the master authorization credential, and a range of the business authority corresponding to the proxy application 112 may be obtained based on the range of the business authority of the master application 111. Illustratively, table 1 is the scope of the service authority of the master application 111 and the scope of the service authority of the proxy application 112. It is to be understood that this table 1 may be stored in the authentication server 300 in advance.

TABLE 1

As shown in table 1, the service authority range of the main application 111 may include support of openid.proxy mode, email.proxy mode, profile.proxy mode, push operation, and SMS operation; the scope of the service authority of the proxy application 112 may include support for openid.proxy mode, email.proxy mode, and profile.proxy mode, but not push operation and sms operation. As can be seen from table 1, the scope of the service authority of the proxy application 112 is smaller than that of the master application 111 by the push operation and the sms operation.

Then, the authentication server 300 may generate the proxy right based on the scope of the service right of the proxy application 112, thereby degrading the service right of the proxy application 112 and avoiding a security risk caused by the service right of the proxy application 112 exceeding the scope.

It will be appreciated that the proxy permission corresponds to the identity of the proxy application 112 in the proxy permission request described above. For example, assuming that a host application 111 requests a proxy permission for a proxy application 112 (e.g., a payment application) this time, and the proxy permission request carries an identity of the proxy application 112, the authentication server 300 issues the proxy permission for the proxy application 112 after receiving the proxy permission request.

In step 111, in response to an operation of the user accessing the proxy application 112, the host application 111 calls the proxy application 112.

Specifically, the user may operate on the terminal 100 to open the host application 111. Next, the user may operate in the host application 111, for example, the user may click on a link in the host application 111 corresponding to the proxy application 112 to access the proxy application 112. For example, the user may click on the payment application in the e-commerce application to access the payment application so that the user may initiate a payment transaction. In response to an operation of the user accessing the proxy application 112, the current host application 111 calls the proxy application 112. The main application 111 may carry the proxy authority in the process of invoking the proxy application, so that the proxy application 112 may use the service authority corresponding to the proxy authority, and further may ensure the security of the personal data of the user.

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

In particular, the proxy application 112 may send a service access request to the service server 200 through the authentication interface to implement a corresponding service operation, e.g., initiate a payment service. The service access request may include the identity of the proxy application 112, the server address, and the proxy permission. The service access request may be sent in a JWT manner.

Now taking the rfc7523 protocol as an example, the credential validation interface of the protocol may be modified to send a service access request, resulting in the following example codes:

POST/token.oauth2 HTTP/1.1

Host:authz.example.net

Content-Type:application/x-www-form-urlencoded

grant_type＝urn％3Aietf％3Aparams％3Aoauth％3Agrant-type％3Ajwt-bearer-with-proxy-token

&assertion＝eyJhbGciOiJFUzI1NiIsImtpZCI6IjE2In0.

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

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

wherein, jwt-bearer-with-proxy-token type is newly added in the grant _ type field, and the jwt-bearer-with-proxy-token type is used for identifying the authority type in the service access request as proxy authority.

Fig. 4 is a diagram of a JWT packet 400 of the service access request. The JWT packet 400 may include a header 410 and a payload 420, where the header 410 includes an agent permission field 411, an agent application id field 412, and a server address field 413, the agent permission field 411 is used to identify the location of the agent permission information 421 in the payload 420, the agent application id field 412 is used to identify the location of the agent application id in the payload 420, and the server address field 413 is used to identify the location of the server address information in the payload 420. The payload 420 contains proxy permission information 321 corresponding to the proxy permission field 411, proxy application identification information 422 corresponding to the proxy application identification field 412, and server address information 423 corresponding to the server address field 413, where permission information 421 may include a range of service permissions for the proxy application 112, proxy application identification information 422 may include an identification of the proxy application 411, and server address information 423 may include a server address (e.g., an IP address or domain name of the proxy application server) of the proxy application 112.

It will be appreciated that header 410 may also contain a claim field 414, where claim field 414 is used to identify the location of claim information 424 within payload 420. Payload 420 also contains claim information 424 corresponding to claim field 414. Assertion information 424 can include, among other things, assertion information such as the JWT issuer (e.g., the server address that issued the JWT), the time of issuance, the time of validity of the issuance, etc. In some embodiments, the JWT packet 400 may not include the above-mentioned declaration information, and this is not particularly limited in the embodiments of the present application.

In step 113, the service server 200 calls the authentication interface of the authentication server 300 for verification based on the service access request.

Specifically, the service server 200 may call an authentication interface (e.g., an authentication interface of oauth2.0 protocol) of the authentication server 300, and forward information in the service access request to the authentication server 300 to verify the service access request. For example, the service server 200 may send the identity, server address, and proxy rights of the proxy application 112 to the authentication server 300 for verification.

In step 114, the authentication server 300 verifies the server address.

Specifically, the authentication server 300 already stores the association relationship between the identity of the proxy application 112 and the server address in step 102, so that the authentication server 300 may obtain the corresponding server address according to the identity query of the proxy application 112 forwarded by the service server 200, and may compare the server address forwarded by the service server 200 with the server address stored locally.

If there is a server address matching the server address sent by the service server 200 in the locally stored server addresses, step 116 is executed.

If the locally stored server address does not have a server address that matches the server address sent by the service server 200, step 115 is executed.

In step 115, the authentication server 300 feeds back an authentication failure message to the proxy application 112, and ends the service access.

In step 116, the authentication server 300 performs rights verification on the proxy rights.

Specifically, the authentication server 300 may acquire the scope of the service authority of the proxy application 112 based on the identity of the proxy application 112. For example, the authentication server 300 may perform a query in table 1 based on the identity of the proxy application 112 to obtain the corresponding range of business rights of the proxy application 112. Then, the authentication server 300 may compare the service authority range of the proxy application 112 obtained by the query with the service authority range corresponding to the proxy authority in the service access request, so as to complete verification of the proxy authority.

If the service authority range of the proxy application 112 obtained by the query is consistent with the service authority range corresponding to the proxy authority in the service access request, step 118 is executed.

If the service authority range of the proxy application 112 obtained by the query does not coincide with the service authority range corresponding to the proxy authority in the service access request, step 117 is executed.

It should be noted that, when determining whether the range of the service right of the queried proxy application 112 is consistent with the range of the service right corresponding to the proxy right in the service access request, it may be determined whether the range of the service right corresponding to the proxy right in the service access request is included in the range of the service right of the queried proxy application 112, and if determining that the range of the service right corresponding to the proxy right in the service access request is included in the range of the service right of the queried proxy application 112, the range of the service right of the queried proxy application 112 is consistent with the range of the service right corresponding to the proxy right in the service access request; if the service authority range corresponding to the proxy authority in the service access request is judged not to be included in the service authority range of the proxy application 112 obtained through query, the service authority range of the proxy application 112 obtained through query is inconsistent with the service authority range corresponding to the proxy authority in the service access request. In addition, whether the range of the service authority of the inquired proxy application 112 is the same as the range of the service authority corresponding to the proxy authority in the service access request or not can be judged, and if the range of the service authority corresponding to the proxy authority in the service access request is judged to be the same as the range of the service authority of the inquired proxy application 112, the range of the service authority of the inquired proxy application 112 is consistent with the range of the service authority corresponding to the proxy authority in the service access request; if the service authority range corresponding to the proxy authority in the service access request is judged to be different from the service authority range of the proxy application 112 obtained through query, the service authority range of the proxy application 112 obtained through query is inconsistent with the service authority range corresponding to the proxy authority in the service access request. The embodiment of the present application is not particularly limited to this.

In step 117, the authentication server 300 feeds back an authentication failure message to the proxy application 112, and ends the service access.

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 perform service access, step 118.

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

Specifically, after receiving the verification success message, the service server 200 may perform service processing based on the service access request, for example, if the service access request is a payment request, the service server 200 may complete the payment task of this time, and return a service processing result (for example, a payment result) to the proxy application 112.

In the embodiment of the application, the proxy authority is distributed to the proxy application in advance through the authentication server so as to distinguish the main authority of the main application, when a user calls the proxy application in the main application to perform service access, the proxy authority is carried in a service access request, and the authentication server performs authority verification based on the proxy authority, so that the service authority of the proxy application can be degraded, and the safety of personal data of the user can be further ensured.

Next, a service access method provided in another embodiment of the present application is described with reference to fig. 5 and fig. 6, and fig. 5 is a flowchart of another embodiment of the service access method of the present application, including:

in step 201, the proxy application 112 sends a registration request to the authentication server 300.

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

At step 202, the authentication server 300 generates an identity and a key for the proxy application 112 based on the registration request.

At step 203, the authentication server 300 returns the identity and key of the proxy application 112 to the proxy application 112.

In step 204, the proxy application 112 requests proxy authorization credentials from the authentication server 300 based on the identity of the proxy application 112 and the key.

Specifically, the proxy authorization credential is used to identify the business rights of the proxy application 112.

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

Specifically, the proxy authorization credential may be issued by the authentication server 300, so that the authentication server 300 may verify the validity of the proxy authorization credential after subsequently receiving the proxy authorization credential.

At step 206, the master application 111 sends a registration request to the authentication server 300.

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

In step 207, the authentication server 300 generates the identity and key of the master application 111 based on the registration request.

Specifically, after receiving the registration request of the master application 111, the authentication server 300 may allocate an identity and a key to the master application 111, and the process of allocating the identity and the key may specifically refer to the oauth2.0 protocol, which is not described herein again. The primary application identity may be used to identify the identity of the primary application 111, that is, the primary application identity may be used to identify the primary application 111. The master application key may be a symmetric key or an asymmetric key commonly used in the art, which is not particularly limited in this embodiment.

In step 208, the authentication server 300 returns the identity and key of the master application 111 to the master application 111.

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

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

In step 211, the master application 111 requests proxy rights from the authentication server 300.

The master application 111 may send a proxy permission request to the authentication server 300. The proxy permission request may include, among other things, the permission type, the identity of proxy application 112, and the master authorization credential.

In step 212, the authentication server 300 issues the proxy right based on the request of the host application 111, and sends the proxy right to the host application 111.

Specifically, after receiving the proxy permission request from the master application 111, the authentication server 300 may verify the validity of the master authorization credential. For example, the authentication server 300 may query whether there is an authorization credential that is consistent with the master authorization credential in the proxy authorization credential request. If there is an authorization credential that is consistent with the master authorization credential in the proxy authorization credential request, the master authorization credential may be considered to be issued by the authentication server 300, that is, the master authorization credential is legal, and the range of the business authority corresponding to the master application 111 and the range of the business authority corresponding to the proxy application 112 may be obtained based on the master authorization credential.

In response to the operation of the user invoking the proxy application 112, the host application 111 invokes the proxy application 112, step 213.

In step 214, the proxy application 112 initiates a service access request to the service server 200 based on the identity of the proxy application 112, the proxy authorization credential, the server address, and the proxy permission.

Specifically, the difference between step 214 and step 112 is that the service access request may further include a proxy authorization credential in addition to the identity, the server address, and the proxy permission of the proxy application 112. Wherein the proxy permission may include a scope of the service permission of the proxy application 112.

Fig. 6 is a diagram of a data packet 600 in JWT format for a service access request. The data packet 600 may include a header 610 and a payload 620, where the header 610 includes an agent authorization credential field 611, an agent permission field 612, an agent application identification field 613, and a server address field 614, the agent authorization credential field 611 is used to identify the location of the agent authorization credential information 621 in the payload 620, the agent permission field 612 is used to identify the location of the agent permission information 622 in the payload 620, the agent application identification field 613 is used to identify the location of the agent application identification information 623 in the payload 620, and the server address field 614 is used to identify the location of the server address information 624 in the payload 620. Payload 620 includes proxy authorization credential information 621 corresponding to proxy authorization credential field 611, proxy authorization credential information 622 corresponding to proxy authorization field 612, proxy application identification information 623 corresponding to proxy application identification field 613, and server address information 624 corresponding to server address field 614. The proxy authorization credential information 611 may include a proxy authorization credential issued by the authentication server 300 to the proxy application 112, the proxy permission information 622 may include a range of business permissions of the proxy application 112, the proxy application identification information 623 may include an identification of the proxy application 112, and the server address information 624 may include a server address of the proxy application 112.

It is to be appreciated that the header 610 may also include a claim field 615, the claim field 615 identifying the location of the claim information 625 in the payload 620. Payload 620 also contains declaration information 625 corresponding to declaration field 615. Declaration information 625 may include, among other things, declaration information for the JWT issuer (e.g., the server address from which the JWT was issued), the time of issuance, and the time of validity of the issuance. In some embodiments, the data packet 600 may not include the above-mentioned declaration information, and this is not particularly limited in this embodiment.

In step 215, the service server 200 calls the authentication interface of the authentication server 300 for verification based on the service access request.

Specifically, the service server 200 may call an authentication interface (e.g., an authentication interface of oauth2.0 protocol) of the authentication server 300, and send information in the service access request to the authentication server 300 to verify the service access request. For example, the service server 200 may send the identity of the proxy application 112, the server address of the proxy application 112, the proxy authorization credential, and the proxy right to the authentication server 300 for verification, where the verification may include validity verification and right verification.

At step 216, the authentication server 300 performs validity verification on the proxy authorization credential.

Specifically, the authentication server 300 may perform validity verification based on the proxy authorization credential. For example, authentication server 300 may query whether there is an authorization credential that is consistent with the proxy authorization credential to determine whether the proxy authorization credential was issued by authentication server 300, whereby the legitimacy of the proxy authorization credential may be verified.

If the agent authorization credential is legitimate, step 218 may be further performed.

If the proxy authorization credential is illegal, step 217 may be further performed.

Step 217, the authentication server 300 feeds back an authentication failure message to the proxy application 112, and ends the service access.

The authentication server 300 verifies the server address, step 218.

Specifically, the authentication server 300 already stores the association relationship between the identity of the proxy application 112 and the server address in step 202, so that the authentication server 300 may obtain the corresponding server address according to the identity query of the proxy application 112 forwarded by the service server 200, and may compare the server address forwarded by the service server 200 with the server address stored locally.

If there is a server address matching the server address sent by the service server 200 in the locally stored server addresses, step 220 is executed.

If there is no server address matching the server address sent by the service server 200 among the locally stored server addresses, step 219 is executed.

In step 219, the authentication server 300 feeds back an authentication failure message to the broker application 112, and ends the service access.

In step 220, the authentication server 300 performs a rights verification on the proxy rights.

Specifically, the authentication server 300 may acquire the scope of the service authority of the proxy application 112 based on the identity of the proxy application 112. For example, the authentication server 300 may perform a query in table 1 based on the identity of the proxy application 112 to obtain the corresponding range of business rights of the proxy application 112. Then, the authentication server 300 may compare the service right range of the proxy application 112 obtained by the query with the service right range corresponding to the proxy right in the service access request, so as to complete the right verification of the proxy right.

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

If the service authority range of the proxy application 112 obtained by the query is not consistent with the service authority range corresponding to the proxy authority in the service access request, step 221 is executed.

Step 221, the authentication server 300 feeds back an authentication failure message to the proxy application 112, and ends the service access.

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 perform service access.

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

In the embodiment of the application, the proxy authority is distributed to the proxy application in advance through the authentication server so as to distinguish the main authority of the main application, when a user calls the proxy application in the main application to perform service access, the proxy authority is carried in a service access request, and the authentication server performs authority verification based on the proxy authority, so that the service authority of the proxy application can be degraded, and the safety of personal data of the user can be further ensured. Meanwhile, when the user calls the agent application to access the service, the service access request also carries the agent authorization credential, and the authentication server verifies the agent authorization credential before verifying the authority of the agent, so that the security can be improved, and the security of personal data of the user can be further ensured.

Next, a service access method provided by another embodiment of the present application is described with reference to fig. 7, and fig. 7 is a flowchart of another embodiment of the service access method of the present application, which is applied to a first electronic device and includes:

step 301, the first electronic device receives a registration request sent by the second application, and allocates identity information and a secret key to the second application.

In particular, the second application may be the proxy application 112 described above. The first electronic device may be the authentication server 300 described above. After receiving a registration request of a second application, the first electronic device can generate second application identity information and a secret key corresponding to the second application, store the server address information of the second application after associating the server address information with the second application identity information, and send the second application identity information and the secret key to the second application; the registration request may include server address information of the second application, and the server address information may include, for example, a server address.

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.

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

After receiving a second application authorization credential request sent by a second application, the first electronic device may obtain second application identity information and a secret key in the second application authorization credential request. Then, a query may be performed according to the second application identity information to obtain a key corresponding to the second application identity information. And comparing the key obtained by the query with the key in the second application authorization credential request, issuing a second application authorization credential in response to the key obtained by the query being consistent with the key in the second application authorization credential request, and sending the second application authorization credential to the second application.

Step 303, the first electronic device receives the second application permission request sent by the first application, and sends the second application permission range to the first application.

In particular, the first application may be the master application 111 described above. The second application permission request is used to obtain a second application permission range, which may be a permission range for service access of the second application. The second application permission request comprises a second application identity identifier and a first application authorization credential, and the first application authorization credential is used for identifying a business access credential of the first application. Therefore, the first electronic device can obtain the preset authority range of the first application according to the first application authorization credential. Then, the first electronic device may obtain a corresponding second application permission range based on a preset permission range query of the first application, where the second application permission range may be a permission range for service access of the second application. Then, the first electronic device may associate and store the second application permission range and the second application identity information, and may send the second application permission range to the first application.

In step 304, the first electronic device receives a verification request sent by the second electronic device.

Specifically, the second electronic device may be the service server 200 described above. The verification request is used for verifying a service access request, the service access request is initiated to a second electronic device by a third 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 comprises a second application permission range and server address information of the second application. The third electronic device may be the terminal 100 described above.

In step 305, the first electronic device verifies the second application authorization credential.

Optionally, the verification request may further carry a second application authorization credential, and the first electronic device may verify the second application authorization credential after receiving the verification request. Wherein, the verification mode can be realized by inquiring whether an authorization credential consistent with the second application authorization credential exists.

In step 306, the first electronic device performs authentication based on the server address information of the second application.

Specifically, the first electronic device may perform querying based on the second application identity information to obtain server address information of the second application corresponding to the second application identity information; and then, the first electronic device compares the server address information of the second application obtained by inquiry 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.

And step 307, in response to the verification of the server address information of the second application, the first electronic device performs authority verification based on the second application authority range.

Specifically, the first electronic device may perform querying based on the second application identity information to obtain a second application permission range corresponding to the second application identity information; and then, the first electronic equipment compares the second application authority range obtained by inquiry with the second application authority range in the verification request to complete authority verification.

And step 308, in response to the permission verification passing, 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 perform service access based on the second application permission range.

Fig. 8 is a schematic structural diagram of an embodiment of the service access apparatus of the present application, and as shown in fig. 8, the service access apparatus 80 may include: a receiving module 81, a first verifying module 82, a second verifying module 83 and a sending module 84;

the receiving module 81 is configured to receive a verification request sent by the second electronic device, where the verification request is used to verify a service access request, the service access request is initiated by the third electronic device to the second electronic device based on the second application, the second application is invoked by the first application in the third electronic device, the verification request includes a second application permission range and server address information of the second application, and the second application permission range is used to identify a permission range of service access of the second application;

a first verification module 82, configured to perform verification based on server address information of the second application;

a second verification module 83, configured to perform permission verification based on the second application permission range in response to verification of server address information of the second application passing;

and the sending module 84 is configured to return a verification success message to the second electronic device in response to the permission verification passing, so that the second electronic device allows the second application in the third electronic device to perform service access based on the second application permission range.

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

a registration module 85, configured to receive a registration request of a second application, where the registration request includes server address information of the second application; and generating second application identity information and a corresponding secret key, associating and storing the server address information of the second application and the second application identity information, and sending the second application identity information and the secret key to the second application.

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

a first querying unit 821, configured to perform querying based on the second application identity information to obtain server address information of the second application corresponding to the second application identity information;

the first verifying 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, so as to complete verification of the server address information of the second application.

In a possible implementation manner, the apparatus 80 further includes: an agent rights assignment module 86;

the agent permission allocation module 86 is configured to receive a second application permission request sent by the first application, where the second application permission request is used to obtain a second application permission range, the second application permission range includes second application identity information and a first application authorization credential, and the first application authorization credential is used to identify a service access credential of the first application; inquiring and obtaining a preset authority range of the first application based on the first application authorization credential, wherein the preset authority range of the first application is used for identifying the authority range of the service access of the first application; inquiring and acquiring a corresponding second application authority range based on a preset authority range of the first application, and associating and storing the second application authority range and second application identity information; and sending the second application permission range to the first application.

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

a second query unit 831, configured to perform a query based on the second application identity information to obtain a second application permission range corresponding to the second application identity information;

the second verifying 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, so as to complete permission verification.

In a possible implementation manner, the apparatus 80 further includes: a proxy credential assignment module 87;

the agent credential distribution module 87 is configured to receive a second application authorization credential request of a second application, where the second application authorization credential request is used to obtain a second application authorization credential, the second application authorization credential is used to identify a service access credential of the second application, and the second application authorization credential request includes second application identity information and a key; inquiring based on the second application identity information to obtain a secret key corresponding to the second application identity information; and comparing the key obtained by inquiry with the key in the second application authorization credential request, issuing the second application authorization credential in response to the fact that the key obtained by inquiry is consistent with the key in the second authorization credential request, and sending the second application authorization credential to the second application.

In a possible implementation manner, the apparatus 80 further includes: a third authentication module 88;

a third verifying module 88, configured to query whether there is an authorization credential that is consistent with the second application authorization credential, so as to complete verification of the second application authorization credential.

It should be understood that the division of the modules of the service access apparatus shown in fig. 8 is merely a logical division, and the actual implementation may be wholly or partially integrated into one physical entity or may be physically separated. And these modules can be realized in the form of software called by processing element; or may be implemented entirely in hardware; and part of the modules can be realized in the form of calling by the processing element in software, and part of the modules can be realized in the form of hardware. For example, the detection module may be a separate processing element, or may be integrated into a chip of the electronic device. Other modules are implemented similarly. In addition, all or part of the modules can be integrated together or can be independently realized. In implementation, each step of the above method or each module above may be implemented by an integrated logic circuit of hardware in a processor element or an instruction in the form of software.

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 microprocessors (DSPs), one or more Field Programmable Gate Arrays (FPGAs), etc. For another example, these modules may be integrated together and implemented in the form of a System-On-a-Chip (SOC).

Fig. 9 is a schematic structural diagram of an embodiment of an electronic device 900 according to the present application, wherein the authentication server 300 may be the electronic device 900; as shown in fig. 9, the electronic device 900 may be a data processing device, or may be a circuit device incorporated in the data processing device. The electronic device 900 may be used to perform the functions/steps of the methods provided by the embodiments of the present application illustrated in fig. 1-7.

As shown in fig. 9, the first electronic device 900 is in the form of a general purpose computing device.

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

Wherein the one or more computer programs are stored in the memory, the one or more computer programs including instructions that, when executed by the first electronic device, cause the first electronic device to perform the steps of:

and generating second application identity information and a corresponding secret key, associating and storing the server address information of the second application with the second application identity information, and sending the second application identity information and the secret key to the second application.

In one possible implementation manner, when the instruction is executed by the first electronic device, after the first electronic device performs the step of sending the second application identity information and the key to the second application, the following step is further performed:

It is to be understood that the interfacing relationship between the modules according to the embodiment of the present invention is only illustrative, and does not limit the structure of the first electronic device 900. In other embodiments of the present application, the first electronic device 900 may also adopt different interface connection manners or a combination of multiple interface connection manners in the above embodiments.

It is to be understood that the electronic device and the like described above include a hardware structure and/or a software module for performing each function in order to realize the functions described above. Those of skill in the art will readily appreciate that the various illustrative elements and algorithm steps described in connection with the embodiments disclosed herein may be implemented as hardware or combinations of hardware and computer software. Whether a function is performed as hardware or computer software drives hardware depends upon the particular application and design constraints imposed on the solution. Skilled artisans may implement the described functionality in varying ways for each particular application, but such implementation decisions should not be interpreted as causing a departure from the scope of the embodiments of the present invention.

In the embodiment of the present application, the electronic device and the like may be divided into functional modules according to the method example, for example, each functional module may be divided according to each function, or two or more functions may be integrated into one processing module. The integrated module can be realized in a hardware mode, and can also be realized in a software functional module mode. It should be noted that, the division of the modules in the embodiment of the present invention is schematic, and is only a logic function division, and there may be another division manner in actual implementation.

Through the above description of the embodiments, it is clear to those skilled in the art that, for convenience and simplicity of description, the foregoing division of the functional modules is merely used as an example, and in practical applications, the above function distribution may be completed by different functional modules according to needs, that is, the internal structure of the device may be divided into different functional modules to complete all or part of the above described functions. For the specific working processes of the system, the apparatus and the unit described above, reference may be made to the corresponding processes in the foregoing method embodiments, and details are not described here again.

Each functional unit in each embodiment of the present application may be integrated into one processing unit, or each unit may exist alone physically, or two or more units are integrated into one unit. The integrated unit can be realized in a form of hardware, and can also be realized in a form of a software functional unit.

The integrated unit, if implemented in the form of a software functional unit and sold or used as a stand-alone product, may be stored in a computer readable storage medium. Based on such understanding, the technical solutions of the embodiments of the present application may be essentially implemented or make a contribution to the prior art, or all or part of the technical solutions may be implemented in the form of a software product stored in a storage medium and including several instructions for causing a computer device (which may be a personal computer, a server, or a network device) or a processor to execute all or part of the steps of the methods described in the embodiments of the present application. And the aforementioned storage medium includes: flash memory, removable hard drive, read only memory, random access memory, magnetic or optical disk, and the like.

The above description is only an embodiment of the present application, but the scope of the present application is not limited thereto, and any changes or substitutions within the technical scope disclosed in the present application should be covered within the scope of the present application. Therefore, the protection scope of the present application shall be subject to the protection scope of the claims.

Claims

1. A service access method is applied to a first electronic device, and is characterized in that the method comprises the following steps:

receiving a verification request sent by second electronic equipment, wherein the verification request is used for verifying a service access request, the service access request is initiated to the second electronic equipment by third electronic equipment based on a second application, the second application is called by a first application in the third electronic equipment, the verification request comprises a second application permission range and server address information of the second application, and the second application permission range is used for identifying a permission range of service access of the second application;

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 passing, performing authority verification based on the second application authority range;

and responding to the permission verification, and returning a verification success message to the second electronic device, so that the second electronic device allows a second application in the third electronic device to perform service access based on the second application permission range.

2. The method of claim 1, wherein the authentication request further includes second application identity information, and wherein, prior to receiving the authentication request sent by the second electronic device, further comprising:

receiving a registration request of the second application, wherein the registration request comprises server address information of the second application;

3. The method of claim 1 or 2, wherein the verifying based on the server address information of the second application comprises:

and 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 verification of the server address information of the second application.

4. The method of claim 2, wherein before receiving the request for authentication sent by the second electronic device, the method further comprises:

receiving a second application permission request sent by the first application, wherein the second application permission request is used for acquiring a second application permission range, the second application permission request comprises the second application identity information and a first application authorization credential, and the first application authorization credential is used for identifying a business access credential of the first application;

obtaining a preset authority range of the first application based on the first application authorization credential query;

5. The method according to any of claims 1-4, wherein the performing rights verification based on the second application rights range comprises:

6. The method of claim 2, wherein after sending the second application identity information and the key to the second application, further comprising:

receiving a second application authorization credential request sent by the second application, wherein the second application authorization credential request is used for obtaining a second application authorization credential, the second application authorization credential is used for identifying a business access credential of the second application, and the second application authorization credential request includes the second application identity information and a secret key;

querying based on the second application identity information to obtain a secret key corresponding to the second application identity information;

and comparing the key obtained by inquiry with the key in the second application authorization credential request, issuing the second application authorization credential in response to the key obtained by inquiry being consistent with the key in the second application authorization credential request, and sending the second application authorization credential to the second application.

7. The method of claim 6, wherein the authentication request further comprises a second application authorization credential, and wherein before the authentication based on the server address information of the second application, further comprising:

querying whether an authorization credential consistent with the second application authorization credential exists to complete verification of the second application authorization credential.

8. A first electronic device, comprising: a memory for storing computer program code, the computer program code comprising instructions that, when read from the memory by the first electronic device, cause the first electronic device to perform the steps of:

receiving a verification request sent by a second electronic device, wherein the verification request is used for verifying a service access request, the service access request is initiated to the second electronic device by a third electronic device based on a second application, the second application is called by a first application in the third electronic device, the verification request comprises a second application permission range and server address information of the second application, and the second application permission range is used for identifying a permission range of service access of the second application;

9. The first electronic device of claim 8, wherein the authentication request further includes second application identity information, and wherein the instructions, when executed by the first electronic device, cause the first electronic device to perform the following steps prior to the step of receiving the authentication request sent by the second electronic device:

10. The first electronic device of claim 8 or 9, wherein the instructions, when executed by the first electronic device, cause the first electronic device to perform the step of verifying based on server address information of the second application comprises:

11. The first electronic device of claim 9, wherein the instructions, when executed by the first electronic device, cause the first electronic device to perform the following steps prior to the step of receiving the authentication request sent by the second electronic device:

12. The first electronic device of any of claims 8-11, wherein the instructions, when executed by the first electronic device, cause the first electronic device to perform the step of performing rights verification based on the second application rights range comprises:

13. The first electronic device of claim 9, wherein the instructions, when executed by the first electronic device, cause the first electronic device to perform the step of sending the second application identity information and the key to the second application, further comprising:

and comparing the key obtained by the query with a key in the second application authorization credential request, issuing the second application authorization credential in response to the key obtained by the query being consistent with the key in the second application authorization credential request, and sending the second application authorization credential to the second application.

14. The first electronic device of claim 13, wherein the authentication request further comprises a second application authorization credential, and wherein the instructions, when executed by the first electronic device, cause the first electronic device to perform the following further steps prior to performing the step of authenticating based on the server address information of the second application:

15. A computer readable storage medium comprising computer instructions which, when run on the first electronic device, cause the first electronic device to perform the method of service access of any of claims 1-7.

16. A computer program product, characterized in that it causes a computer to carry out the method of service access according to any one of claims 1-7, when said computer program product is run on the computer.