Access authorization method and device, diagnosis authorization method and device and electronic equipment

Abstract

The invention is suitable for the technical field of computers, and provides an access authorization method, a diagnosis authorization method, a diagnosis authorization device and electronic equipment, and the method comprises the steps: carrying out the identity verification of a request user corresponding to an authorization request under the condition of obtaining the authorization request sent by a client, the authorization request is used for requesting the authorization server to authorize the requesting user to obtain diagnostic software resources; under the condition that the identity verification is passed, a target equipment identifier corresponding to target diagnosis equipment is obtained, and the target diagnosis equipment is registered diagnosis equipment corresponding to the request user; generating an access token according to the target device identifier; and sending the access token to the client, wherein the client is used for acquiring the diagnostic software resource corresponding to the target diagnostic equipment from a resource server according to the access token. The risk that diagnosis software is pirated can be reduced.

Description

Technical Field

[0001] The present application belongs to the field of computer technology, and in particular, relates to an access authorization method, a diagnosis authorization method, a device, an electronic device, and a computer-readable storage medium. Background Art

[0002] Diagnostic equipment is a hardware tool designed to detect, analyze and solve problems of various mechanical equipment or electronic equipment. It usually needs to be used in conjunction with diagnostic software to achieve efficient and accurate detection and troubleshooting of the equipment.

[0003] Since diagnostic equipment often needs to be used with authorized diagnostic software to fully exert its functions, after obtaining the diagnostic equipment, the user usually needs to bind the diagnostic equipment to the user account. After logging into the user account, the user can download the corresponding authorized diagnostic software and install the obtained authorized diagnostic software on the user device or diagnostic equipment such as a mobile phone, so as to control the diagnostic equipment to diagnose the device to be diagnosed through the authorized diagnostic software. However, the user account and password are easy to be leaked or cracked by illegal users. If the illegal user obtains the user account and password, he can decompile the diagnostic software installation package through reverse engineering, achieve the piracy of the diagnostic software, and use the pirated diagnostic software on other devices. Summary of the invention

[0004] The embodiments of the present application provide an access authorization method, a diagnosis authorization method, a device, and an electronic device, which can reduce the risk of the diagnosis software being stolen.

[0005] In a first aspect, an embodiment of the present application provides an access authorization method, which is applied to an authorization server, including:

[0006] In the case of obtaining an authorization request sent by the client, performing identity verification on the requesting user corresponding to the authorization request, wherein the authorization request is used to request the authorization server to authorize the requesting user to obtain diagnostic software resources;

[0007] In the case where the identity verification passes, obtaining a target device identifier corresponding to a target diagnostic device, the target diagnostic device being a registered diagnostic device corresponding to the requesting user;

[0008] Generate an access token according to the target device identifier;

[0009] The access token is sent to the client, and the client is used to obtain the diagnostic software resource corresponding to the target diagnostic device from a resource server according to the access token.

[0010] In a second aspect, an embodiment of the present application provides a diagnosis authorization method, including:

[0011] Acquire device information of a diagnostic device, wherein the device information at least includes a device identification of the diagnostic device;

[0012] Obtaining an access token, wherein the access token includes a verification device identifier used for verification;

[0013] In the case where the verification device identifier is identical to the device identifier, the diagnostic resource is opened to the diagnostic device, and the diagnostic device is used to diagnose the device to be diagnosed according to the diagnostic resource.

[0014] In a third aspect, an embodiment of the present application provides an access authorization device, including:

[0015] A verification module, used to verify the identity of a requesting user corresponding to the authorization request upon obtaining the authorization request sent by the client, wherein the authorization request is used to request the authorization server to authorize the requesting user to obtain the diagnostic software resource;

[0016] An identification acquisition module, used to acquire a target device identification corresponding to a target diagnostic device if the identity verification passes, the target diagnostic device being a registered diagnostic device corresponding to the requesting user;

[0017] A token generation module, used to generate an access token according to the target device identifier;

[0018] The token sending module is used to send the access token to the client, and the client is used to obtain the diagnostic software resource corresponding to the target diagnostic device from the resource server according to the access token.

[0019] In a fourth aspect, an embodiment of the present application provides a diagnosis authorization device, including:

[0020] A device information acquisition module, used to acquire device information of a diagnostic device, wherein the device information at least includes a device identification of the diagnostic device;

[0021] A token acquisition module, used to acquire an access token, wherein the access token includes a verification device identifier used for verification;

[0022] The resource opening module is used to open the diagnostic resources to the diagnostic device when the verification device identifier and the device identifier are the same, and the diagnostic device is used to diagnose the device to be inspected according to the diagnostic resources.

[0023] In a fifth aspect, an embodiment of the present application provides an electronic device, comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein when the processor executes the computer program, the steps of the access authorization method described in the first aspect or the steps of the diagnostic authorization method described in the second aspect are implemented.

[0024] In a sixth aspect, an embodiment of the present application provides a computer-readable storage medium, wherein the computer storage medium stores a computer program, and when the computer program is executed by a processor, the steps of the access authorization method described in the first aspect or the steps of the diagnosis authorization method described in the second aspect are implemented.

[0025] In a seventh aspect, an embodiment of the present application provides a computer program product, which, when executed on an electronic device, enables the electronic device to execute the steps of the access authorization method described in the first aspect or the steps of the diagnosis authorization method described in the second aspect.

[0026] Compared with the prior art, the embodiments of the present invention have the following beneficial effects:

[0027] In the embodiment of the present application, when the authorization server obtains the authorization request sent by the client, it will first perform identity verification on the requesting user corresponding to the authorization request. If the identity verification passes, that is, after confirming that the requesting user is a legal user, subsequent processing will be performed to intercept the request of illegal users and reduce the risk of diagnostic software resources being pirated. After the identity verification passes, an access token is generated according to the target device identifier corresponding to the diagnostic device registered by the requesting user, and then the access token is sent to the client. Since the access token includes the target device identifier of the authorized target diagnostic device, the diagnostic software resource obtained by the requesting user from the resource server through the access token on the client is the software resource corresponding to the target diagnostic device. In addition, through the access token, the diagnostic software corresponding to the target diagnostic device and its corresponding diagnostic software resource can be bound, and the diagnostic software can only be used in conjunction with the authorized target diagnostic device. Illegal users cannot obtain other diagnostic software resources from the resource server, nor can they pirate the obtained diagnostic software resources to other devices for use, effectively reducing the risk of diagnostic software being pirated. BRIEF DESCRIPTION OF THE DRAWINGS

[0028] In order to more clearly illustrate the technical solutions in the embodiments of the present application, the drawings required for use in the embodiments or the description of the prior art are briefly introduced below.

[0029] Figure 1 This is a system architecture diagram of access authorization and access authorization application provided by an embodiment of the present application;

[0030] Figure 2 It is a flowchart of an access authorization method provided in an embodiment of the present application;

[0031] Figure 3 It is a flowchart of another access authorization method provided in an embodiment of the present application;

[0032] Figure 4 It is a flowchart of a diagnosis authorization method provided in an embodiment of the present application;

[0033] Figure 5 is a schematic diagram of the structure of an access authorization device provided in an embodiment of the present application;

[0034] Figure 6 is a schematic diagram of the structure of a diagnostic authorization device provided in an embodiment of the present application;

[0035] Figure 7 It is a schematic diagram of the structure of an electronic device provided in an embodiment of the present application. DETAILED DESCRIPTION

[0036] In the following description, specific details such as specific system structures, technologies, etc. are provided for the purpose of illustration rather than limitation, so as to provide a thorough understanding of the embodiments of the present application. However, it should be clear to those skilled in the art that the present application may also be implemented in other embodiments without these specific details. In other cases, detailed descriptions of well-known systems, devices, circuits, and methods are omitted to prevent unnecessary details from obstructing the description of the present application.

[0037] It should be understood that when used in the present specification and the appended claims, the term "comprising" indicates the presence of described features, wholes, steps, operations, elements and / or components, but does not exclude the presence or addition of one or more other features, wholes, steps, operations, elements, components and / or combinations thereof.

[0038] It should also be understood that the term “and / or” used in the specification and appended claims refers to any and all possible combinations of one or more of the associated listed items, and includes these combinations.

[0039] References to "one embodiment" or "some embodiments" etc. described in the specification of this application mean that one or more embodiments of the present application include specific features, structures or characteristics described in conjunction with the embodiment. Therefore, the phrases "in one embodiment", "in some embodiments", "in some other embodiments", "in some other embodiments", etc. appearing in different places in this specification do not necessarily refer to the same embodiment, but mean "one or more but not all embodiments", unless otherwise specifically emphasized in other ways.

[0040] Figure 1 A system architecture diagram of the access authorization method and the diagnosis authorization method provided in the embodiments of the present application is shown.

[0041] Reference Figure 1The system architecture includes a client 11, a diagnostic device 12, an authorization server 13, a resource server 14 and a device to be tested 15.

[0042] The client 11 is an application or device that interacts directly with the user. The requesting user can initiate a request to the authorization server 13 and the resource server 14 through the client 11 and receive a response from the server through the client 11.

[0043] It should be noted that the client 11 is usually run on a client device. In the embodiment of the present application, the client device may be a diagnostic device 12, or a terminal device such as a computer, a smart phone, a tablet computer, or a wearable device. When the client 11 is run on a device other than the diagnostic device 12, the system architecture may also include a client device that carries and runs the client 11.

[0044] The diagnostic device 12 refers to a professional tool or instrument used to detect, identify and analyze the status of various systems, equipment or organisms.

[0045] The authorization server 13 is a server that manages the access authorization of the diagnostic software resources. Through the authorization server 13, the authorization operation of the resource access of the diagnostic software can be realized to ensure that only legitimate users can obtain the copyrighted diagnostic software. Among them, the diagnostic software resources include the resources required for the installation and use of the diagnostic software, including but not limited to the diagnostic software installation package, configuration files and licenses.

[0046] The resource server 14 is a server storing diagnostic software resources.

[0047] In an embodiment of the present application, when a requesting user needs to obtain the authorized diagnostic software of the diagnostic device 12, he can log in to the client 11 and initiate an authorization request to the authorization server 13 through the client 11 to request the authorization server 13 to authorize the requesting user to obtain the diagnostic software resources. After the authorization server 13 obtains the authorization request sent by the client 11, it can determine whether the requesting user corresponding to the authorization request is a legal user by means of identity verification to decide whether to authorize the requesting user. If the identity verification of the requesting user passes, that is, the authorization server 13 determines that the requesting user is a legal user, subsequent authorization processing will be performed to intercept requests from illegal users and reduce the risk of diagnostic software resources being pirated. During the authorization process, the authorization server 13 will obtain the target device identifier corresponding to the diagnostic device 12 registered by the requesting user, generate an access token based on the target device identifier, and send it to the client 11.

[0048] After the client 11 receives the access token sent by the authorization server 13, the user can send the access token to the resource server 14 through the client 11. The resource server 14 can determine whether the requesting user is an authorized access user based on the access token sent by the client 11, and when it is determined that the requesting user is an authorized access user, it can determine the target diagnostic device based on the target device identifier in the access token, and then open the diagnostic software resources corresponding to the target diagnostic device to the requesting user, so that the requesting user can access and obtain the diagnostic software resources corresponding to the target diagnostic software through the client 11. After the client 11 obtains the diagnostic software resources, the requesting user can install and use the diagnostic software corresponding to the target diagnostic device on the client device based on the diagnostic software resources.

[0049] In the embodiment of the present application, the client 11 is authorized to obtain the diagnostic software resources corresponding to the target diagnostic device by means of an access token, and the target diagnostic device can be bound to its corresponding diagnostic software resources. The diagnostic software can only be used in conjunction with the authorized target diagnostic device. Even if an illegal user obtains a legitimate user identity by cracking an account password, and obtains an access token through the legitimate user identity, he cannot obtain other diagnostic software resources from the resource server 14, and cannot pirate the obtained diagnostic software resources for use on other devices, thereby effectively reducing the risk of diagnostic software being pirated.

[0050] It should be noted that after installing the diagnostic software, before using the diagnostic software to diagnose the device 15 to be inspected through the diagnostic device 12, the diagnostic software will obtain the device information of the diagnostic device 12 and the corresponding access token. The device information includes at least the device identification of the diagnostic device 12, and the access token includes the verification device identification, which is the device identification used for verification determined according to the target device identification. Because the diagnostic software obtained based on the access token is the diagnostic software corresponding to the target diagnostic device, it can only be used in conjunction with the authorized target diagnostic device. Therefore, the diagnostic software will determine whether the diagnostic device 12 is an authorized target diagnostic device based on the verification device identification and the device identification of the diagnostic device 12. When it is determined that the diagnostic device 12 is the target diagnostic device, the diagnostic resources will be opened to the diagnostic device 12, and the diagnostic device 12 can diagnose the device 15 to be inspected based on the diagnostic resources opened by the diagnostic software.

[0051] The above-mentioned equipment to be inspected 15 includes but is not limited to vehicles, mechanical equipment such as excavators, aviation equipment, medical equipment, industrial production equipment, etc. In a feasible embodiment, the above-mentioned equipment to be inspected 15 can be a vehicle, and correspondingly, the resource server 14 stores vehicle diagnostic software resources corresponding to various diagnostic devices 12 of the vehicle.

[0052] based on Figure 1 The system architecture shown, Figure 2 A schematic diagram of a flow chart of an access authorization method provided in an embodiment of the present application is shown. The access authorization method is applied to an authorization server and is described in detail as follows:

[0053] Step S201, when obtaining an authorization request sent by a client, performing identity verification on a requesting user corresponding to the authorization request, wherein the authorization request is used to request the authorization server to authorize the requesting user to obtain diagnostic software resources.

[0054] It can be understood that the above authorization request may indicate the user who initiates the authorization request (referred to as the requesting user) and the client that sends the authorization request.

[0055] As an example, the authorization request may include a client identifier and a user identifier. The client identifier may be an identifier determined by a MAC (Media Access Control) address, an Internet Protocol Address (IP address), a browser's User-Agent string, or a session identifier, etc. of a client device. The user identifier may be an identifier determined by a user name, user ID, mobile phone number, or ID card number, etc.

[0056] Optionally, the above authorization request may further include a scope parameter, a Redirect_URI (Redirect Uniform Resource Locator, redirect address) and a state parameter.

[0057] The above identity verification is used to verify whether the requesting user is a legitimate user. The above identity verification includes but is not limited to account password verification, biometric verification such as fingerprint verification, or verification code verification, etc., which can be set according to the actual application scenario.

[0058] In a possible implementation, a user can access a related application or web page on a client device, log in to the client by logging into the user account, and then submit an authorization request on the client. The authorization server can receive authorization requests initiated by different clients.

[0059] In an embodiment of the present application, in order to ensure data security, when an authorization request is received from a requesting user requesting authorization to obtain diagnostic software resources, an identity verification will be performed to determine whether the requesting user is a legitimate user, and then a decision will be made whether to authorize the requesting user, so as to avoid authorizing illegal users to obtain diagnostic software resources, which is beneficial to reducing the risk of diagnostic software being pirated.

[0060] Step S202: if the identity verification is passed, obtaining a target device identifier corresponding to a target diagnostic device, where the target diagnostic device is a registered diagnostic device corresponding to the requesting user.

[0061] A registered diagnostic device refers to a diagnostic device that is bound to a user. After obtaining a diagnostic device, the user can bind the diagnostic device to the user account on the client. For example, if user A purchases diagnostic device B, user A can enter the device ID of diagnostic device B on the Add Device page of the client and click Add. At this time, the registered diagnostic device corresponding to user A includes diagnostic device B.

[0062] Specifically, if the identity verification of the requesting user passes, the requesting user can be considered as a legitimate user and can be authorized. At this time, the registered diagnostic device of the requesting user, that is, the target diagnostic device, can be determined first, and then the device identification of the target diagnostic device can be obtained to obtain the target device identification, so as to authorize the diagnostic software resources corresponding to the target diagnostic device to the requesting user.

[0063] Optionally, if the identity verification of the requesting user fails, the requesting user may not be authorized, or the requesting user may be subjected to a secondary verification, and if the secondary verification still fails, the requesting user may not be authorized. The secondary verification may be the same verification method as the identity verification, or may be a verification method different from the identity verification.

[0064] For example, suppose that the identity of the requesting user is verified by means of a mobile phone verification code, and suppose that the identity verification of the requesting user A fails, at this time, the authorization server can send an identity confirmation notification to the client B of the requesting user A, indicating through the identity confirmation notification that the identity verification of the requesting user fails, so that the user can request to re-authenticate the identity after checking the information. Suppose that a secondary verification request is received from the client B, that is, the requesting user requests a secondary verification. Assuming that the secondary verification is face recognition, the authorization server can obtain the real-time face image of the requesting user and compare it with the pre-stored face image to identify whether the requesting user A is a legitimate user and the user himself.

[0065] If the secondary verification is passed, authorization can be granted to the requesting user A. By means of secondary verification, the impact of identity authentication failure caused by incorrect information input by the requesting user is reduced, and the accuracy of access authorization is improved.

[0066] In one possible implementation, the authorization request may include a requesting device identifier, which is the device identifier of the diagnostic device for which the requesting user requests authorization. After the identity authentication of the requesting user is passed, the authorization server can determine the registered diagnostic device corresponding to the requesting user based on pre-stored data, obtain the device identifier of the registered diagnostic device (referred to as the registered device identifier), and determine whether the requesting device identifier is the same as any registered device identifier. If they are determined to be the same, it indicates that the requesting device identifier is the device identifier of the registered diagnostic device. At this time, the requesting device identifier can be used as the target device identifier.

[0067] In another possible implementation, after the identity authentication of the requesting user is passed, the authorization server may also directly determine the registered diagnostic device corresponding to the requesting user based on pre-stored data, and determine the target device identifier based on the device identifiers of these registered diagnostic devices.

[0068] Step S203: Generate an access token according to the target device identifier.

[0069] In an embodiment of the present application, when generating an access token, the access token can be generated according to the target device identifier, so that when the client obtains diagnostic software resources from the resource server according to the access token, it can only obtain the diagnostic software resources corresponding to the target device identifier, and cannot obtain other diagnostic software resources, thereby reducing the impact of access token leakage and illegal users obtaining access tokens by cracking account passwords.

[0070] Step S104: sending the access token to the client, and the client is used to obtain the diagnostic software resource corresponding to the target diagnostic device from the resource server according to the access token.

[0071] After obtaining the access token, the client requests the corresponding diagnostic software resources from the resource server based on the access token. After receiving the access token, the resource server can determine the diagnostic software resources that the client can obtain based on the device identifier in the access token, that is, the diagnostic software resources corresponding to the target diagnostic device, and send them to the client so that the client can install and use the diagnostic software based on the diagnostic software resources.

[0072] In the embodiment of the present application, when the authorization server obtains the authorization request sent by the client, it will first perform identity verification on the requesting user corresponding to the authorization request. If the identity verification passes, that is, after judging that the requesting user is a legal user, the subsequent authorization processing will be performed to reduce the probability of request authorization for illegal users, thereby reducing the risk of diagnostic software resources being pirated. After the identity verification passes, an access token is generated according to the target device identifier corresponding to the diagnostic device registered by the requesting user, and then the access token is sent to the client. Since the access token includes the target device identifier of the authorized target diagnostic device, the diagnostic software resource obtained by the requesting user from the resource server through the access token on the client is the software resource corresponding to the target diagnostic device, that is, through the access token, the diagnostic software corresponding to the target diagnostic device and its corresponding diagnostic software resource is bound, and the diagnostic software can only be used in conjunction with the authorized target diagnostic device, and illegal users cannot obtain other diagnostic software resources from the resource server, nor can they pirate the obtained diagnostic software resources to other devices for use, effectively reducing the risk of diagnostic software being pirated.

[0073] In some embodiments, the identity verification of the requesting user corresponding to the authorization request includes:

[0074] The identity of the requesting user corresponding to the authorization request is verified using a preset verification method, and the preset verification method includes one or more identity verification methods other than account number and password verification.

[0075] Since there is a high risk that the user's account and password may be cracked by attackers, in order to further improve authorization security, when determining the verification method for identity verification, the verification method other than the account and password verification can be set as the preset verification method, so that when the preset verification method is used to verify the identity of the requesting user, verification will not be performed through the account and password verification method, thereby reducing the security risks caused by the leakage or cracking of the user's account and password.

[0076] Among them, the preset verification method may include multiple verification methods other than account and password verification, that is, judging whether the requesting user is a legitimate user through multi-factor verification is conducive to improving the accuracy of authorization and data security.

[0077] In a possible implementation, the preset verification methods include at least two of mobile phone verification code verification, voiceprint verification, face verification, iris verification, security question verification and behavioral feature verification.

[0078] In the embodiment of the present application, the identity of the requesting user is verified by an identity verification method other than account and password verification, which can reduce the security risks caused by the leakage of the user's account and password, and is conducive to reducing the risk of diagnostic software being pirated.

[0079] In some embodiments, the above-mentioned obtaining the target device identifier corresponding to the target diagnostic device includes:

[0080] The target device identifier is determined according to the device identifier selected by the requesting user.

[0081] Since the user may have activated multiple diagnostic devices, it is not necessary to authorize all of them. Therefore, to improve the accuracy of authorization, the user can independently select the device identification of the diagnostic device that needs to be authorized, and the authorization server will determine the target device identification based on the device identification selected by the user.

[0082] Optionally, the device identification requested to be selected by the user may be determined based on information manually input by the user, or may be determined based on the user's input to a displayed option list, and may be specifically set according to actual application scenarios.

[0083] As an example, the authorization server can first determine the various registered diagnostic devices corresponding to the requesting user and send them to the client. The client displays the registered diagnostic devices and the device identifiers of the registered diagnostic devices to the requesting user in the form of an option list, and then determines the device identifier selected by the requesting user based on the button clicked by the requesting user on the display page, the number or text entered, etc. Finally, the device identifier selected by the requesting user is sent to the authorization server. The authorization server can determine the target device identifier based on the received device identifier, that is, the device identifier selected by the user. Since the requesting user directly selects from the device identifiers of the diagnostic devices that have been registered by the requesting user, the authorization server does not need to determine whether the device identifier is the device identifier of the diagnostic device registered by the requesting user after obtaining the device identifier selected by the user, which can reduce unnecessary judgment steps and help improve authorization efficiency.

[0084] In one possible implementation, after the authorization server determines the target device identifier based on the device identifier selected by the user, it can send an authorization query to the requesting user based on the target device identifier and information such as the mobile phone number or email address bound by the requesting user, and instruct the requesting user to confirm whether to authorize the target diagnostic device through the authorization query. After the user confirms that he agrees to the authorization, the corresponding access token is generated. Since some illegal users may crack the account password of a legitimate user, become a legitimate user, and initiate an authorization request to the authorization server to obtain diagnostic software resources to pirate the diagnostic software, in order to further reduce the risk of diagnostic software being pirated, when sending an authorization query to the requesting user, the authorization query can be sent to the requesting user by sending a text message based on the mobile phone number bound by the user, thereby reducing the impact of the user's account password being cracked, and further reducing the probability of the authorized software being pirated.

[0085] In an embodiment of the present application, based on the device identifier selected by the requesting user, the target diagnostic device and the target device identifier are determined from the registered diagnostic devices of the requesting user, and then the requesting user is authorized to enable the requesting user to access the diagnostic software resources corresponding to the target diagnostic device, without directly authorizing the diagnostic software resources of all registered diagnostic devices, which is beneficial to reducing the impact caused by the leakage of the requesting user's access token.

[0086] Figure 3 A schematic diagram of another access authorization method provided in an embodiment of the present application is shown. Figure 3 The access authorization method shown may include:

[0087] Step S301: sending an authorization query to the client, wherein the authorization query is used to instruct the requesting user to confirm whether to agree to authorize the target diagnostic device.

[0088] Step S302: upon receiving the authorization consent information sent by the client, an authorization code is sent to the client.

[0089] Step S303, when the token request sent by the client is obtained and the token request contains the authorization code, the access token is generated according to the target device identifier, and the token request is used to request the authorization server to issue the access token.

[0090] After obtaining the target device identification, an authorization query can be sent to the client to confirm whether the requesting user agrees to authorize the target diagnostic device. If the authorization consent information sent by the client is received, that is, the requesting user agrees to authorize the target device, an authorization code can be sent to the client. Optionally, the authorization code can be a random string generated by a random number generator or the like.

[0091] In one possible implementation, when sending the authorization code to the client, the authorization code can be sent in the form of 302, that is, the authorization code is not sent directly to the client, but a response message with a status code of 302 is sent in response to the request message. The response message will carry a Location header that points to a URL. After receiving the 302 response message, the client will initiate a token request based on the URL provided in its Location header. The authorization server can obtain the token request sent by the client based on the URL.

[0092] It is understandable that after receiving the authorization code sent by the authorization server, the client usually sends a token request containing the authorization code to the authorization server. After the authorization server obtains the token request sent by the client, it will first determine whether the token request carries the previously issued authorization code. If the token request carries the previously issued authorization code, it can be considered that the token request is a legitimate request that can be responded to. At this time, an access token can be generated according to the target device identifier to respond to the client's token request in a timely manner.

[0093] If there is no authorization code in the token request, or the authorization code included is different from the previously generated authorization code, it means that the token request does not carry the correct authorization code. At this time, you can refuse to generate the authorization code, or send a notification of an authorization code error to the client. If the correct authorization code sent by the client is received, you can generate an access token. If the correct authorization code is not received, you can refuse to generate the access token.

[0094] In a possible implementation, before sending the authorization code to the client, the authorization server may first encrypt the authorization code using a preset encryption algorithm (such as a hash-based message authentication code or a Rivest-Shamir-Adleman encryption algorithm, etc.) to obtain an encrypted authorization code. After receiving the token request sent by the client, the authorization server will first confirm the correctness of the authorization code in the token request through the corresponding decryption algorithm. If the decrypted authorization code is the correct authorization code, then it can be determined that the token request contains the authorization code, and a token request can be generated according to the target device identifier.

[0095] In a possible implementation, the authorization server sets the validity period of the authorization code by adding a timestamp or serial number to the authorization code. After receiving the token request sent by the client, if the token request contains the correct authorization code, the authorization server will first verify the validity of the authorization code in the token request, that is, determine whether the authorization code is within the validity period. If the authorization code is within the validity period, it will generate an access token based on the target device identifier. Otherwise, it can refuse to generate an access token, or it can instruct the requesting user to re-initiate the authorization request.

[0096] In an embodiment of the present application, after confirming that the requesting user is a legitimate user through identity authentication, the requesting user is first asked whether he agrees to authorize the target diagnostic device. After the requesting user agrees to authorize the target diagnostic device, an access token is generated by issuing an authorization code. That is, when the requesting user requests an access token, he needs to request the access token through an authorization code, which can improve the security and controllability of the access authorization process.

[0097] In some embodiments, before the access token is generated according to the target device identifier, the method further includes:

[0098] Determine supplementary information according to the client, the supplementary information including authorized IP information and / or region information;

[0099] Correspondingly, the above-mentioned generating an access token according to the above-mentioned target device identifier includes:

[0100] The access token is generated according to the target device identifier and the supplementary information.

[0101] The above authorized IP information refers to information determined based on the IP address of the client, including but not limited to information such as the IP address, subnet mask and default gateway.

[0102] The above-mentioned regional information refers to the information determined by the real-time location of the client, including but not limited to information such as province, city, administrative region, street and longitude and latitude coordinates. The granularity of the regional information can be set according to the actual application scenario. The embodiment of the present application does not impose specific restrictions on the granularity of the regional information.

[0103] In order to further reduce the impact of pirated diagnostic software, in an embodiment of the present application, supplementary information is also determined based on the client that sends the authorization request, and then the required access token is generated based on the supplementary information and the target device information.

[0104] The supplementary information may include authorized IP information, or the supplementary information may include region information, or the supplementary information may include both authorized IP information and region information.

[0105] In a possible implementation, the supplementary information may further include at least one of authorized MAC information and permission access information determined according to the MAC address of the client device.

[0106] As an example, the supplementary information may include the authorized IP information and regional information corresponding to the client, wherein the authorized IP information includes the IP address of the client, and the regional information includes the administrative area where the client is located. Assuming that the requesting user A sends its access token C to the resource server through the client B, after receiving the access token C, the resource server will obtain the IP information of the client B and the real-time location information of the client B. If the IP address of the client B is the same as the authorized IP information in the access token C, and the real-time location information of the client B is consistent with the regional information, it can be considered that the client B (that is, the requesting user A) is authorized for legal access. At this time, the corresponding diagnostic software resources can be opened to the client B, allowing it to access and obtain the corresponding diagnostic software resources.

[0107] In an embodiment of the present application, an access token is generated based on authorized IP information and / or regional information. That is, by adding authorized IP information and / or regional information to the access token, the IP information and / or location information of the device accessing the resource server and the diagnostic software is restricted, thereby avoiding a single authorized user from obtaining the diagnostic software on multiple devices and using the diagnostic software in a pirated manner, which helps to reduce the impact of piracy of the diagnostic software.

[0108] based on Figure 1 The system architecture shown, Figure 4 A flow chart of a diagnosis authorization method is shown. The diagnosis authorization method can be applied to diagnosis software. The diagnosis software can be installed and run on a diagnosis device, a client device or other electronic devices.

[0109] Step S401, obtaining device information of a diagnostic device, wherein the device information at least includes a device identification of the diagnostic device.

[0110] Step S402: obtaining an access token, wherein the access token includes a verification device identifier used for verification.

[0111] Optionally, when obtaining the access token, the access token may be obtained directly from the diagnostic device, or the diagnostic token corresponding to the diagnostic device may be obtained from the authorization server, or individual access tokens with access authorization to the diagnostic software may be obtained from the authorization server.

[0112] For example, assume that the following three Class B diagnostic devices are authorized: diagnostic device B1, diagnostic device B2, and diagnostic device B3, that is, the target diagnostic devices of the requesting user are diagnostic device B1, diagnostic device B2, and diagnostic device B3. The requesting user can obtain the diagnostic software resources corresponding to its target diagnostic device through its corresponding access token, that is, obtain the resources of diagnostic software A. Then, for diagnostic software A, when obtaining the access token, it can obtain the access token of its corresponding authorized diagnostic device, that is, obtain diagnostic device B1, diagnostic device B2, and diagnostic device B3.

[0113] Step S403: when the verification device identifier and the device identifier are the same, opening the diagnosis resources to the diagnosis device, and the diagnosis device is used to diagnose the device to be diagnosed according to the diagnosis resources.

[0114] The above-mentioned diagnostic resources refer to various information, function sets and services required in the diagnostic process. The diagnostic software opens diagnostic resources to the diagnostic equipment, that is, the diagnostic software authorizes the diagnostic equipment to access and use its built-in functions and data through specific interfaces and protocols, so that the diagnostic equipment can perform equipment or system fault detection, performance evaluation, parameter adjustment and other operations.

[0115] In order to reduce the impact of pirated diagnostic software, before opening diagnostic resources to a diagnostic device, the diagnostic software will first determine whether the diagnostic device is a diagnostic device with its access authorization. If it is determined that the diagnostic device is a diagnostic device with the access authorization of the diagnostic software, the diagnostic resources will be opened to the diagnostic device.

[0116] Among them, since the authorization server will add the target device identifier corresponding to the authorized target diagnostic device to the access token during the access authorization process, in an embodiment of the present application, the device identifier in the access token can be used as a verification device identifier, and the diagnostic authorization can be verified based on the verification device identifier.

[0117] During the verification process, the device information of the diagnostic device can be obtained first, and the device information at least includes the device identification of the diagnostic device, and then the access token corresponding to the diagnostic software is obtained. Since the target diagnostic device with access authorization of the diagnostic software can be determined based on the verification device identification in the access token corresponding to the diagnostic software (i.e., the target device identification during access authorization), it is possible to better judge whether the diagnostic device is an authorized target diagnostic device based on whether the device identification and any verification device identification are the same.

[0118] If it is determined that the device identification of the diagnostic device is the same as any verification device identification, it indicates that the diagnostic device is one of the authorized target diagnostic devices. At this time, the diagnostic resources can be opened to the diagnostic device.

[0119] It can be understood that since the authorization server adds the target device identifier of the authorized target diagnostic device to the access token during the access authorization process, the authorized target diagnostic device can be bound to the corresponding diagnostic software. Therefore, based on the access token, the target diagnostic device with access authorization for a certain diagnostic software can be known. Furthermore, before opening diagnostic resources to the diagnostic device, the diagnostic software can determine whether the diagnostic device is an authorized target diagnostic device through the above processing. Even if an illegal user obtains the diagnostic software through data theft or other means, it can only be used in conjunction with the authorized target diagnostic device, and cannot be pirated to other diagnostic devices for use, effectively reducing the losses caused by pirated diagnostic software.

[0120] In the embodiment of the present application, the diagnostic software will obtain the device information of the diagnostic device and the corresponding access token. Since the device information of the diagnostic device includes its device identification, and the access token contains a verification device identification for verification, and can reflect the target diagnostic device authorized to access the diagnostic software, therefore, according to the device information of the diagnostic device and the access token, it is possible to better judge whether the diagnostic device is an authorized target diagnostic device, thereby judging whether the diagnostic device is a legal diagnostic device. If the device identification of the diagnostic device is the same as the verification device identification in the access token, it indicates that the diagnostic device is an authorized target diagnostic device. At this time, the diagnostic resources are opened to the diagnostic device, thereby ensuring that the diagnostic software will only open diagnostic resources to the authorized target diagnostic device. Even if a user obtains pirated diagnostic software, the diagnostic software cannot be pirated to other illegal diagnostic devices for use, effectively reducing the loss of pirated diagnostic software.

[0121] In some embodiments, the access token further includes authorized IP information and / or regional information, wherein the authorized IP information refers to information determined based on the IP address of the client, including but not limited to IP address, subnet mask, and default gateway. The regional information refers to information determined by the real-time location of the client, including but not limited to information such as province, city, administrative district, street, and longitude and latitude coordinates.

[0122] In the case where the verification device identifier and the device identifier are the same, opening the diagnostic resources to the diagnostic device includes:

[0123] When the verification device identification is the same as the device identification, and the IP information of the diagnostic device is the same as the authorized IP information,

[0124] Alternatively, when the verification device identifier is the same as the device identifier, and the location information of the diagnostic device matches the area information,

[0125] Alternatively, when the verification device identifier is identical to the device identifier, the IP information is identical to the authorized IP information, and the location information is consistent with the area information, the diagnostic resources are opened to the diagnostic device.

[0126] In the embodiment of the present application, the authorization server will add supplementary information for verification in the access token, that is, verify whether the diagnostic device using the diagnostic software is a legal diagnostic device based on the supplementary information. Among them, the supplementary information may include authorized IP information and / or regional information, and the IP information of the device that can use the diagnostic software is limited by the authorized IP information, and the location information of the device that can use the diagnostic software is limited by the regional information. It should be noted that in the embodiment of the present application, the device using the diagnostic software is the diagnostic device.

[0127] It should be noted that, in the embodiment of the present application, the supplementary information in the access token is determined based on the client, that is, the authorized IP information is determined based on the IP information of the client, and the regional information is determined based on the location information of the client. That is, in the embodiment of the present application, the user needs to log in to the account and initiate an authorization request on the target diagnostic device, and install the diagnostic software on the target diagnostic device based on the acquired diagnostic software resources. At this time, in the acquired access token, the authorized IP information in the supplementary information is determined based on the IP information of the target diagnostic device, and the regional information is determined based on the location information of the target diagnostic device.

[0128] Among them, when the supplementary information only includes the authorized IP information, in addition to judging the device identification, it is also judged whether the IP information of the diagnostic device is the same as the authorized IP information. If the IP information is the same as the authorized IP information, it means that the IP information of the diagnostic device meets the requirements. At this time, if the device identification of the diagnostic device is also the same as the verification device identification, it can be determined that the diagnostic device is a legally used target diagnostic device.

[0129] Alternatively, when the supplementary information only includes the regional information, in addition to determining the device identification, it is also determined whether the location information of the diagnostic device is consistent with the regional information. If the location information is consistent with the regional information, it indicates that the location of the diagnostic device meets the requirements. At this time, if the device identification of the diagnostic device is the same as the verification device identification, it can be determined that the diagnostic device is a legal target diagnostic device.

[0130] Alternatively, when the supplementary information includes authorized IP information and regional information, the device identification, IP information and location information of the diagnostic device must be determined. If the device identification of the diagnostic device is the same as the verification device identification, the IP information is the same as the authorized IP information, and the location information also matches the regional information, the diagnostic device is determined to be a legal target diagnostic device.

[0131] It should be noted that when making the above judgment, it is to judge whether the verification device identifier in the same access token is the same as the device identifier of the diagnostic device, whether the authorized IP information in the access token is the same as the IP information, and whether the location information is consistent with the area information in the access token, so that when it is determined that the diagnostic device is an authorized target diagnostic device, it is determined whether the diagnostic device is a legally used target diagnostic device based on the supplementary information in the access token.

[0132] Optionally, to improve the efficiency of diagnostic authorization, it is possible to first determine whether the device identification of the diagnostic device is the same as the verification device identification in the access token. After determining the access token (target access token) in which the verification device identification is the same as the device identification, the IP information and / or location information is determined based on the supplementary information in the target access token.

[0133] After determining that the diagnostic device is an authorized target diagnostic device, the diagnostic resources are opened to the diagnostic device.

[0134] If it is determined that the device identifier of the diagnostic device is different from the verification device identifier in the access token, it means that the diagnostic device is not an authorized target diagnostic device. At this time, prompt information such as illegal device can be directly output without the need to judge additional information.

[0135] If it is determined that the device identifier of the diagnostic device is the same as the verification device identifier in the access token, but the IP information is different from the authorized IP information, or the location information does not match the regional information, at this time, prompt information such as illegal use of the authorized device can be output. At this time, diagnostic resources are not open to the diagnostic device.

[0136] In the embodiment of the present application, the target diagnostic device is bound to the diagnostic software through the device identification in the access token, and the diagnostic device using the diagnostic software is correspondingly restricted through the authorized IP information and / or regional information in the access token. Only when the device identification and other information of the diagnostic device are consistent with the corresponding information in the access token, the diagnostic device is determined to be a legal target diagnostic device, and the diagnostic resources are opened to the diagnostic device, that is, the IP information and / or location information of the authorized diagnostic device is restricted by supplementary information to avoid the situation where the user uses the diagnostic device in an unauthorized area.

[0137] It should be understood that the size of the serial numbers of the steps in the above embodiments does not mean the order of execution. The execution order of each process should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of the embodiments of the present application.

[0138] Corresponding to the access authorization method described in the above embodiment, Figure 5 A structural block diagram of an access authorization device provided in an embodiment of the present application is shown. For ease of explanation, only the parts related to the embodiment of the present application are shown.

[0139] Reference Figure 5 The device includes: a verification module 51, an identification acquisition module 52, a token generation module 53 and a token sending module 54. Among them,

[0140] The verification module 51 is used to verify the identity of the requesting user corresponding to the authorization request when obtaining the authorization request sent by the client. The authorization request is used to request the authorization server to authorize the requesting user to obtain the diagnostic software resource.

[0141] The identification acquisition module 52 is used to acquire the target device identification corresponding to the target diagnostic device when the above identity verification is passed. The above target diagnostic device is the registered diagnostic device corresponding to the above requesting user.

[0142] The token generation module 53 is used to generate an access token according to the target device identification.

[0143] The token sending module 54 is used to send the access token to the client, and the client is used to obtain the diagnostic software resource corresponding to the target diagnostic device from the resource server according to the access token.

[0144] In the embodiment of the present application, when the authorization server obtains the authorization request sent by the client, it will first perform identity verification on the requesting user corresponding to the authorization request. If the identity verification passes, that is, after judging that the requesting user is a legal user, the subsequent authorization processing will be performed to reduce the probability of request authorization for illegal users, thereby reducing the risk of diagnostic software resources being pirated. After the identity verification passes, an access token is generated according to the target device identifier corresponding to the diagnostic device registered by the requesting user, and then the access token is sent to the client. Since the access token includes the target device identifier of the authorized target diagnostic device, the diagnostic software resource obtained by the requesting user from the resource server through the access token on the client is the software resource corresponding to the target diagnostic device, that is, through the access token, the diagnostic software corresponding to the target diagnostic device and its corresponding diagnostic software resource is bound, and the diagnostic software can only be used in conjunction with the authorized target diagnostic device, and illegal users cannot obtain other diagnostic software resources from the resource server, nor can they pirate the obtained diagnostic software resources to other devices for use, effectively reducing the risk of diagnostic software being pirated.

[0145] In some embodiments, the verification module 51 includes:

[0146] The verification unit is used to perform identity verification on the requesting user corresponding to the authorization request using a preset verification method, wherein the preset verification method includes one or more identity verification methods other than account number and password verification.

[0147] In some embodiments, the identification acquisition module 52 includes:

[0148] The identification determination unit is used to determine the target device identification according to the device identification selected by the requesting user.

[0149] In some embodiments, the access authorization device further includes:

[0150] The inquiry module is used to send an authorization inquiry to the client, wherein the authorization inquiry is used to instruct the requesting user to confirm whether to agree to authorize the target diagnostic device.

[0151] The authorization code sending module is used to send the authorization code to the client upon receiving the authorization consent information sent by the client.

[0152] Correspondingly, the token generation module 53 includes:

[0153] A generating unit is used to generate the access token according to the target device identifier when a token request sent by the client is obtained and the token request contains the authorization code, and the token request is used to request the authorization server to issue the access token.

[0154] In some embodiments, the access authorization device further includes:

[0155] The supplementary information determination module is used to determine the supplementary information according to the client, wherein the supplementary information includes the authorized IP information and / or the area information.

[0156] Correspondingly, the token generation module 53 includes:

[0157] A supplementary generation unit is used to generate the access token according to the target device identifier and the supplementary information.

[0158] Figure 6 A structural block diagram of an access authorization device provided in an embodiment of the present application is shown.

[0159] Reference Figure 6 The device includes: a device information acquisition module 61, a token acquisition module 62 and a resource opening module 63.

[0160] The device information acquisition module 61 is used to acquire device information of the diagnostic device, where the device information at least includes a device identification of the diagnostic device.

[0161] The token acquisition module 62 is used to acquire an access token, wherein the access token includes a verification device identifier used for verification.

[0162] The resource opening module 63 is used to open the diagnostic resources to the diagnostic device when the verification device identifier is the same as the device identifier, and the diagnostic device is used to diagnose the device to be inspected according to the diagnostic resources.

[0163] In the embodiment of the present application, the diagnostic software will obtain the device information of the diagnostic device and the corresponding access token. Since the device information of the diagnostic device includes its device identification, and the access token contains a verification device identification for verification, and can reflect the target diagnostic device authorized to access the diagnostic software, therefore, according to the device information of the diagnostic device and the access token, it is possible to better judge whether the diagnostic device is an authorized target diagnostic device, thereby judging whether the diagnostic device is a legal diagnostic device. If the device identification of the diagnostic device is the same as the verification device identification in the access token, it indicates that the diagnostic device is an authorized target diagnostic device. At this time, the diagnostic resources are opened to the diagnostic device, thereby ensuring that the diagnostic software will only open diagnostic resources to the authorized target diagnostic device. Even if a user obtains pirated diagnostic software, the diagnostic software cannot be pirated to other illegal diagnostic devices for use, effectively reducing the loss of pirated diagnostic software.

[0164] In some embodiments, the access token further includes supplementary information, and the supplementary information includes authorized IP information and / or region information. The resource opening module 63 includes:

[0165] The open judgment unit is used for, when the verification device identification is the same as the device identification, and the IP information of the diagnostic device is the same as the authorized IP information,

[0166] Alternatively, when the verification device identifier is the same as the device identifier, and the location information of the diagnostic device matches the area information,

[0167] Alternatively, when the verification device identifier is identical to the device identifier, the IP information is identical to the authorized IP information, and the location information is consistent with the area information, the diagnostic resources are opened to the diagnostic device.

[0168] It should be noted that the information interaction, execution process, etc. between the above-mentioned devices / units are based on the same concept as the method embodiment of the present application. Their specific functions and technical effects can be found in the method embodiment part and will not be repeated here.

[0169] Figure 7 This is a schematic diagram of the structure of an electronic device provided by an embodiment of the present application. Figure 7 As shown, the electronic device 7 of this embodiment includes: at least one processor 70 ( Figure 7 Only one processor is shown in the figure), a memory 71, and a computer program 72 stored in the memory 71 and executable on the at least one processor 70, wherein the processor 70 implements the steps in any of the above-mentioned method embodiments when executing the computer program 72.

[0170] The electronic device 7 may be a computing device such as a desktop computer, a notebook, a PDA, or a cloud server. The electronic device may include, but is not limited to, a processor 70 and a memory 71. Those skilled in the art will appreciate that Figure 7 It is only an example of the electronic device 7 and does not constitute a limitation on the electronic device 7. It may include more or fewer components than shown in the figure, or a combination of certain components, or different components. For example, it may also include input and output devices, network access devices, etc.

[0171] The processor 70 may be a central processing unit (CPU), or other general-purpose processors, digital signal processors (DSP), application-specific integrated circuits (ASIC), field-programmable gate arrays (FPGA) or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. A general-purpose processor may be a microprocessor or any conventional processor, etc.

[0172] In some embodiments, the memory 71 may be an internal storage unit of the electronic device 7, such as a hard disk or memory of the electronic device 7. In other embodiments, the memory 71 may also be an external storage device of the electronic device 7, such as a plug-in hard disk, a smart media card (SMC), a secure digital (SD) card, a flash card, etc. equipped on the electronic device 7. Further, the memory 71 may also include both an internal storage unit and an external storage device of the electronic device 7. The memory 71 is used to store an operating system, an application program, a boot loader (BootLoader), data, and other programs, such as the program code of the computer program. The memory 71 may also be used to temporarily store data that has been output or is to be output.

[0173] The technicians in the relevant field can clearly understand that for the convenience and simplicity of description, only the division of the above-mentioned functional units and modules is used as an example for illustration. In practical applications, the above-mentioned function allocation can be completed by different functional units and modules as needed, that is, the internal structure of the device can be divided into different functional units or modules to complete all or part of the functions described above. The functional units and modules in the embodiment can be integrated in a processing unit, or each unit can exist physically separately, or two or more units can be integrated in one unit. The above-mentioned integrated unit can be implemented in the form of hardware or in the form of software functional units. In addition, the specific names of the functional units and modules are only for the convenience of distinguishing each other, and are not used to limit the scope of protection of this application. The specific working process of the units and modules in the above-mentioned system can refer to the corresponding process in the aforementioned method embodiment, which will not be repeated here.

[0174] An embodiment of the present application also provides a network device, which includes: at least one processor, a memory, and a computer program stored in the memory and executable on the at least one processor, wherein the processor implements the steps in any of the above-mentioned method embodiments when executing the computer program.

[0175] An embodiment of the present application further provides a computer-readable storage medium, wherein the computer-readable storage medium stores a computer program, and when the computer program is executed by a processor, the steps in the above-mentioned method embodiments can be implemented.

[0176] An embodiment of the present application provides a computer program product. When the computer program product runs on an electronic device, the electronic device can implement the steps in the above-mentioned method embodiments when executing the computer program product.

[0177] If the integrated unit is implemented in the form of a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the present application implements all or part of the processes in the above-mentioned embodiment method, which can be completed by instructing the relevant hardware through a computer program, and the computer program can be stored in a computer-readable storage medium. When the computer program is executed by the processor, the steps of the above-mentioned various method embodiments can be implemented. Among them, the computer program includes computer program code, and the computer program code can be in source code form, object code form, executable file or some intermediate form. The computer-readable medium may at least include: any entity or device that can carry the computer program code to the camera / electronic device, recording medium, computer memory, read-only memory (ROM, Read-Only Memory), random access memory (RAM, RandomAccess Memory), electric carrier signal, telecommunication signal and software distribution medium. For example, a USB flash drive, a mobile hard disk, a magnetic disk or an optical disk. In some jurisdictions, according to legislation and patent practice, computer-readable media cannot be electric carrier signals and telecommunication signals.

[0178] In the above embodiments, the description of each embodiment has its own emphasis. For parts that are not described or recorded in detail in a certain embodiment, reference can be made to the relevant descriptions of other embodiments.

[0179] Those of ordinary skill in the art will appreciate that the units and algorithm steps of each example described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, or a combination of computer software and electronic hardware. Whether these functions are performed in hardware or software depends on the specific application and design constraints of the technical solution. Professional and technical personnel can use different methods to implement the described functions for each specific application, but such implementation should not be considered to be beyond the scope of this application.

[0180] In the embodiments provided in the present application, it should be understood that the disclosed devices / network equipment and methods can be implemented in other ways. For example, the device / network equipment embodiments described above are merely schematic. For example, the division of the modules or units is only a logical function division. There may be other division methods in actual implementation, such as multiple units or components can be combined or integrated into another system, or some features can be ignored or not executed. Another point is that the mutual coupling or direct coupling or communication connection shown or discussed can be through some interfaces, indirect coupling or communication connection of devices or units, which can be electrical, mechanical or other forms.

[0181] The units described as separate components may or may not be physically separated, and the components shown as units may or may not be physical units, that is, they may be located in one place or distributed on multiple network units. Some or all of the units may be selected according to actual needs to achieve the purpose of the solution of this embodiment.

[0182] The embodiments described above are only used to illustrate the technical solutions of the present application, rather than to limit them. Although the present application has been described in detail with reference to the aforementioned embodiments, a person skilled in the art should understand that the technical solutions described in the aforementioned embodiments may still be modified, or some of the technical features may be replaced by equivalents. Such modifications or replacements do not deviate the essence of the corresponding technical solutions from the spirit and scope of the technical solutions of the embodiments of the present application, and should all be included in the protection scope of the present application.

Claims

1. An access authorization method, characterized in that: Applicable to the authorization server, including: In the case of obtaining an authorization request sent by the client, performing identity verification on the requesting user corresponding to the authorization request, wherein the authorization request is used to request the authorization server to authorize the requesting user to obtain diagnostic software resources; In the case where the identity verification passes, obtaining a target device identifier corresponding to a target diagnostic device, the target diagnostic device being a registered diagnostic device corresponding to the requesting user; Generate an access token according to the target device identifier; The access token is sent to the client, and the client is used to obtain the diagnostic software resource corresponding to the target diagnostic device from a resource server according to the access token.

2. The access authorization method according to claim 1, characterized in that: The performing identity verification on the requesting user corresponding to the authorization request includes: The identity of the requesting user corresponding to the authorization request is verified using a preset verification method, and the preset verification method includes one or more identity verification methods other than account number and password verification.

3. The access authorization method according to claim 1, characterized in that: The step of obtaining a target device identifier corresponding to the target diagnostic device includes: The target device identifier is determined according to the device identifier selected by the requesting user.

4. The access authorization method according to claim 1, characterized in that: Before generating an access token according to the target device identifier, the method further includes: Sending an authorization query to the client, wherein the authorization query is used to instruct the requesting user to confirm whether to agree to authorize the target diagnostic device; Upon receiving the authorization consent information sent by the client, sending an authorization code to the client; Correspondingly, generating an access token according to the target device identifier includes: When a token request sent by the client is obtained and the token request includes the authorization code, the access token is generated according to the target device identifier, and the token request is used to request the authorization server to issue the access token.

5. The access authorization method according to any one of claims 1 to 4, characterized in that: Before generating an access token according to the target device identifier, the method further includes: Determining supplementary information according to the client, the supplementary information including authorized IP information and / or area information; Correspondingly, generating an access token according to the target device identifier includes: The access token is generated according to the target device identification and the supplementary information.

6. A diagnosis authorization method, characterized in that: include: Acquire device information of a diagnostic device, wherein the device information at least includes a device identification of the diagnostic device; Obtaining an access token, wherein the access token includes a verification device identifier used for verification; In the case where the verification device identifier and the device identifier are identical, the diagnostic resource is opened to the diagnostic device, and the diagnostic device is used to diagnose the device to be inspected according to the diagnostic resource.

7. The diagnostic authorization method according to claim 6, characterized in that: The access token further includes supplementary information, the supplementary information including authorized IP information and / or region information, and when the verification device identifier and the device identifier are the same, opening diagnostic resources to the diagnostic device includes: When the verification device identification is the same as the device identification, and the IP information of the diagnostic device is the same as the authorized IP information, Alternatively, when the verification device identifier is the same as the device identifier, and the location information of the diagnostic device matches the area information, Alternatively, when the verification device identifier is identical to the device identifier, the IP information is identical to the authorized IP information, and the location information conforms to the area information, the diagnostic resource is opened to the diagnostic device.

8. An access authorization device, characterized in that: include: A verification module, used to verify the identity of a requesting user corresponding to the authorization request upon obtaining the authorization request sent by the client, wherein the authorization request is used to request the authorization server to authorize the requesting user to obtain the diagnostic software resource; An identification acquisition module, used to acquire a target device identification corresponding to a target diagnostic device if the identity verification passes, the target diagnostic device being a registered diagnostic device corresponding to the requesting user; A token generation module, used to generate an access token according to the target device identifier; The token sending module is used to send the access token to the client, and the client is used to obtain the diagnostic software resource corresponding to the target diagnostic device from the resource server according to the access token.

9. An electronic device comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that: When the processor executes the computer program, the method according to any one of claims 1 to 5 or the method according to any one of claims 6 to 7 is implemented.

10. A computer-readable storage medium storing a computer program, characterized in that: When the computer program is executed by a processor, the method according to any one of claims 1 to 5 or the method according to any one of claims 6 to 7 is implemented.

Images