Authorization method based on OAuth standard, OAuth server and storage medium

Abstract

The present invention proposes an authorization method based on the OAuth standard, including: an OAuth server receives a first login application sent by a first client, the first login application includes first account information of an ordinary user; the OAuth server determines that the ordinary user has logged in on a second client based on the first account information; the OAuth server sends a first verification request to the first client, and the OAuth server receives second account information generated by the first client; the OAuth server sends a second verification request to the second client, and the OAuth server receives third account information generated by the second client; the OAuth server compares the second account information and the third account information with set standard verification information respectively, determines the login status of the first client and the second client according to the comparison result, logs out the account of the abnormally logged-in client, and prevents the user's information from being in a continuous leakage state. The present invention also provides an OAuth server and a storage medium.

Description

Technical Field

[0001] The present invention relates to the field of computer communication technology, and in particular to an authorization method, an OAuth server, and a storage medium based on the OAuth standard. Background Art

[0002] The Open Authentication Application Programming Interface (OAuth) standard, currently the most popular third-party application programming interface (API) authentication and authorization access protocol in the industry, has been widely used on the Internet. The OAuth standard allows users to expose information stored by a service provider to third-party applications without exposing their keys.

[0003] However, such OAuth servers currently often have the following problem: if a user's account information has been logged in on a client, and the OAuth server detects that the same account information has sent a login request on another client, the OAuth server cannot determine which of the two clients is the normal login. Summary of the Invention

[0004] In view of the above, it is necessary to propose an authorization method, an OAuth server and a storage medium based on the OAuth standard to solve the technical problem that it is difficult for the OAuth server to determine the normal login status of multiple clients.

[0005] The present invention provides an authorization method based on the OAuth standard, which is applied to a system including an OAuth server, a first client, and a second client. The method includes:

[0006] The OAuth server receives a first login application sent by the first client, where the first login application includes first account information of a common user;

[0007] The OAuth server authenticates the first account information;

[0008] Determining, based on the first account information, that the ordinary user has logged in to the second client;

[0009] The OAuth server sends a first verification request to the first client, and the OAuth server receives second account information generated by the first client based on the first verification request;

[0010] The OAuth server sends a second verification request to the second client, and the OAuth server receives the third account information generated by the second client based on the second verification request;

[0011] The OAuth server compares the second account information and the third account information with the set standard verification information respectively, and determines the login status of the first client and the second client according to the comparison results, where the login status includes abnormal login and normal login.

[0012] By using a verification method different from the first login method to simultaneously identify the login status of two clients, it is possible to accurately identify which client is an abnormal login and which client is a normal login, rather than assuming that the client that logged in the second time is an abnormal login. This can better protect the user's normal login behavior.

[0013] In one embodiment, the method further comprises:

[0014] When the OAuth server determines that the second client has logged in abnormally, the OAuth server deletes the first access token of the second client, destroys the global session established with the second client, and simultaneously initiates a logout request to all applications on the second client that are registered based on the first access token, so that the applications on the second client destroy the local sessions established with the second client.

[0015] When the OAuth server receives a login request from another client for an account that has already logged in, it verifies the login status of both clients, determines the login status based on the feedback from the two clients, and logs out the account of the abnormally logged-in client, thus preventing the user's data information from continuing to be leaked.

[0016] In one embodiment, the method further comprises:

[0017] When the OAuth server determines that the first client has logged in normally, the OAuth server generates a second access token and returns the second access token to the first client, so that the first application on the first client sends a second login application to the OAuth server, and the second login application includes the second access token. The OAuth server verifies that the second access token is correct and returns a third access token to the first application. The third access token includes ordinary user permission information and the identifier of the first application, so that the first application establishes a local session with the first client based on the third access token.

[0018] The OAuth server gives the normally logged-in client a second access token, ensuring that the client confirmed to be in a normally logged-in state is not affected by the previous login.

[0019] In one embodiment, the method further comprises:

[0020] The OAuth server records abnormal login information of the second client, receives the abnormal login query request of the first client, and sends the abnormal login information of the second client to the first client.

[0021] Obtain the abnormal login information of the second client through the OAuth server. In this way, ordinary users can know the abnormal login method of the second client and understand which of their information has been leaked, and then modify the leaked information in time.

[0022] In one embodiment, the method further comprises:

[0023] The OAuth server receives a permission change request sent by the first application, where the permission change request includes a third access token. The OAuth server verifies that the third access token is correct. The OAuth server determines the first tenant corresponding to the first application based on the identifier of the first application and a pre-stored application identifier tenant relationship table. The OAuth server sends a trigger request to the first application, where the trigger request includes a permission change condition set by the first tenant. The OAuth server receives feedback information sent by the first application based on the permission change condition. The OAuth server determines that the feedback information is consistent with preset standard information. The OAuth returns a third access token to the first application, where the third access token includes the changed permission information.

[0024] Through the permission change conditions preset by the OAuth server, a change notification message is sent to the first application to perform the permission change. In this way, compared with manual permission changes, the permission change of this solution is more efficient and timely.

[0025] The embodiment of the present application further provides an OAuth server, the OAuth server comprising:

[0026] a communication unit, configured to receive a first login application sent by the first client, where the first login application includes first account information of a common user;

[0027] A memory, configured to store the first account information, the second account information, and set standard verification information;

[0028] a processor, connected to the communication unit and the memory, respectively, and configured to authenticate the first account information, determine that the first account information is correct, and determine that the ordinary user is logged in to the second client based on the first account information;

[0029] The communication unit is configured to send a first verification request to the first client; the communication unit is configured to receive second account information sent by the first client based on the first verification request;

[0030] The communication unit is configured to send a second verification request to the second client; the communication unit is configured to receive the third account information sent by the second client based on the second verification request;

[0031] The processor is further configured to compare the second account information and the third account information with standard verification information set in the memory respectively, and the processor is configured to determine the login status of the first client and the second client based on the comparison results, wherein the login status includes abnormal login and normal login.

[0032] In one embodiment: the memory is further used to store the first access token of the second client, the global session between the processor and the second client, and the processor is used to, when determining that the second client has logged in abnormally, delete the first access token and destroy the global session, and at the same time initiate a logout request to all applications on the second client registered with the first access token through the communication unit, so that the applications on the second client destroy the local sessions established with the second client.

[0033] In one embodiment: the memory is also used to store the second access token of the first client, and the processor is used to determine that the first client has logged in normally. The processor is also used to generate a second access token and return the second access token to the first client through the communication unit, so that the first application on the first client sends a second login application to the communication unit, and the second login application includes the second access token. The processor is also used to verify that the second access token is correct, generate a third access token and return the third access token to the first application through the communication unit, and the third access token includes ordinary user permission information and the identifier of the first application, so that the first application establishes a local session with the first client based on the third access token.

[0034] In one embodiment: the memory is also used to store an application tenant relationship table, permission change conditions, and preset standard information; the communication unit is used to receive a permission change request sent by the first application, the permission modification request includes a third access token; the processor is also used to verify that the third access token is correct; the processor is used to determine the first tenant corresponding to the first application based on the identifier of the first application and the stored application-tenant relationship table; the communication unit is also used to send a trigger request to the first application, the trigger request includes the permission change condition set by the first tenant; the communication unit is used to receive feedback information sent by the first application based on the permission change condition; the processor is used to determine that the feedback information is consistent with the preset standard information, and change the permission according to the permission change request.

[0035] An embodiment of the present application further provides a computer-readable storage medium, on which a computer program is stored. When the computer program is executed by the OAuth server, the above method is implemented.

[0036] When the OAuth server receives a login request from another client for an account that has already logged in, it verifies the login status of both clients, determines the login status based on the feedback from the two clients, and logs out the account of the abnormally logged-in client to prevent the user's data from continuing to be leaked. BRIEF DESCRIPTION OF THE DRAWINGS

[0037] Figure 1 This is a flowchart of an authorization method based on the OAuth standard provided by one embodiment of the present invention.

[0038] Figure 2 This is a flowchart of a permission setting process provided by an embodiment of the present invention.

[0039] Figure 3 This is a schematic diagram of a process for a common user to obtain permissions provided by an embodiment of the present invention.

[0040] Figure 4 This is a schematic diagram of cluster deployment of OAuth servers provided by an embodiment of the present invention.

[0041] Figure 5 A schematic diagram of the architecture of an OAuth server provided in one embodiment of the present invention.

[0042] Description of main component symbols

[0043] OAuth Server 10 Communication unit 101 Memory 102 processor 103 DETAILED DESCRIPTION

[0044] In order to make the purpose, technical solutions and advantages of the present invention more clearly understood, the present invention is further described in detail below with reference to the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are only used to explain the present invention and are not intended to limit the present invention. Based on the embodiments of the present invention, all other embodiments obtained by ordinary technicians in this field without making creative work are within the scope of protection of the present invention.

[0045] OAuth (Open Authorization) is an open standard that allows users to grant third-party applications access to private resources stored on a website (such as photos, videos, and contact lists) without providing their username and password to the third-party application. The current version of OAuth is 2.0, and the OAuth server in this application is implemented based on the OAuth 2.0 protocol.

[0046] If a user's account information has already been logged in on a client, and the OAuth server detects that the same account information has sent a login request from another client, in the existing technology, the OAuth server will default to the first login as a normal login and send a notification of the second login to the client that logged in the first time for confirmation. However, it does not take into account that if the first login is an abnormal login, it will cause the ordinary user who logs in the second time to be unable to log in normally. Therefore, it is difficult for the existing OAuth server to determine the normal login status of multiple clients, that is, it is impossible to identify which of the two clients is the normal login.

[0047] The present invention provides an authorization method based on the OAuth standard, which is applied to a system including an OAuth server, a first client, and a second client. The method includes:

[0048] The OAuth server receives a first login application sent by the first client, where the first login application includes first account information of a common user;

[0049] The OAuth server authenticates the first account information;

[0050] Determining, based on the first account information, that the ordinary user has logged in to the second client;

[0051] The OAuth server sends a first verification request to the first client, and the OAuth server receives second account information generated by the first client based on the first verification request;

[0052] The OAuth server sends a second verification request to the second client, and the OAuth server receives the third account information generated by the second client based on the second verification request;

[0053] The OAuth server compares the second account information and the third account information with the set standard verification information respectively, and determines the login status of the first client and the second client according to the comparison results, where the login status includes abnormal login and normal login.

[0054] By using a verification method different from the first login method to simultaneously identify the login status of two clients, it is possible to accurately identify which client is an abnormal login and which client is a normal login, rather than assuming that the client that logged in the second time is an abnormal login. This can better protect the user's normal login behavior.

[0055] The embodiment of the present application further provides an OAuth server, the OAuth server comprising:

[0056] a communication unit, configured to receive a first login application sent by the first client, where the first login application includes first account information of a common user;

[0057] A memory, configured to store the first account information, the second account information, and set standard verification information;

[0058] a processor, connected to the communication unit and the memory, respectively, and configured to authenticate the first account information, determine that the first account information is correct, and determine that the ordinary user is logged in to the second client based on the first account information;

[0059] The communication unit is configured to send a first verification request to the first client; the communication unit is configured to receive second account information sent by the first client based on the first verification request;

[0060] The communication unit is configured to send a second verification request to the second client; the communication unit is configured to receive the third account information sent by the second client based on the second verification request;

[0061] The processor is further configured to compare the second account information and the third account information with standard verification information set in the memory respectively, and the processor is configured to determine the login status of the first client and the second client based on the comparison results, wherein the login status includes abnormal login and normal login.

[0062] An embodiment of the present application further provides a computer-readable storage medium, on which a computer program is stored. When the computer program is executed by the OAuth server, the above method is implemented.

[0063] When the OAuth server receives a login request from another client for an account that has already logged in, it verifies the login status of both clients, determines the login status based on the feedback from the two clients, and logs out the account of the abnormally logged-in client to prevent the user's data from continuing to be leaked.

[0064] Some embodiments of the present invention will be described in detail below with reference to the accompanying drawings.

[0065] like Figure 1 As shown, the first embodiment of the present application provides an authorization method based on the OAuth standard.

[0066] The method comprises the following steps.

[0067] S101: The OAuth server receives a first login application sent by the first client, where the first login application includes first account information of a common user.

[0068] It should be noted that the first client can be a mobile phone, computer, tablet, etc.; in this application, the first client takes a mobile phone as an example, and the first account information includes the user's username and password, and may also include SMS verification code login, etc. In this application, the first account information is the user's username and password.

[0069] S102: The OAuth server authenticates the first account information; and determines, based on the first account information, that the ordinary user has logged in to the second client.

[0070] It should be noted that the second client can be a mobile phone, computer, tablet, etc.

[0071] In this application, the second client takes a tablet as an example. For example, user A uses a username and password to log in to an application on the mobile phone. A MySQL database is set up in the OAuth server. The MySQL database stores a correspondence table of usernames and passwords for each user. The OAuth server receives the username and password of user A and compares it with the correspondence table stored in the MySQL database. If the corresponding username and password exist in the MySQL database, it proves that the username and password entered by user A are correct. The OAuth server finds through the stored session records that a login token has been generated based on user A's username and password and sent to the tablet, which means that user B has logged in on the tablet before user A logged in. User A and user B in this application can refer to the same person or different people. At this time, the OAuth server needs to determine which of the mobile phone and tablet is the normal login.

[0072] S103: The OAuth server sends a first verification request to the first client, and the OAuth server receives second account information generated by the first client based on the first verification request.

[0073] S104: The OAuth server sends a second verification request to the second client, and the OAuth server receives the third account information generated by the second client based on the second verification request.

[0074] It should be noted that the first verification request and the second verification request sent by the OAuth server require user A and user B to enter information different from the first input to log in. For example, if the second client logs in for the first time using a username and password, then the second verification request will no longer require the input of a username and password, for example, logging in using a random SMS code. If the first client logs in for the first time using a random SMS code, the first verification request will no longer require the input of a random SMS code, for example, logging in using a username and password.

[0075] Suppose user A and user B are different people. User B is a hacker who obtains user A's username and password, uses the username and password to send a login request to the OAuth server and successfully logs in to the second client. User A then sends a login request to the OAuth server based on the same username and password from the first client. The OAuth server receives user A's login request, identifies the username and password, and finds that the username and password have already been logged in. At this time, the OAuth server simultaneously sends verification requests to the first client and the second client to enter a random SMS code. The hacker does not have the mobile phone of the owner of account A, so he cannot log in with the correct SMS verification code. OAuth receives verification code feedback from the first client and the second client, identifies the wrong verification code, and can determine that the second client has logged in abnormally and the first client has logged in normally.

[0076] S105: The OAuth server compares the second account information and the third account information with the set standard verification information respectively. The OAuth server determines the login status of the first client and the second client according to the comparison results, and the login status includes abnormal login and normal login.

[0077] The OAuth server can determine that the second client has logged in abnormally by receiving an incorrect SMS verification code or not receiving the verification code.

[0078] This application uses a verification method different from the first login method to simultaneously identify the login status of two clients. It can accurately identify which client is an abnormal login and which client is a normal login, instead of assuming that the client that logged in for the second time is an abnormal login. Compared with the existing technology, this application can better provide protection for the user's normal login behavior.

[0079] In one embodiment: the method further comprises the steps.

[0080] S106 (not shown), when the OAuth server determines that the second client has logged in abnormally, the OAuth server deletes the first access token of the second client and destroys the global session established with the second client, and at the same time initiates a logout request to all applications on the second client that are registered based on the first access token, so that the applications on the second client destroy the local sessions established with the second client.

[0081] Through the above technical solution, when the OAuth server receives a login request sent by an account that has already logged in from another client, it verifies the login status of the two clients, determines the login status based on the feedback information of the two clients, and logs out the account of the abnormally logged-in client to prevent the user's data information from continuing to be leaked.

[0082] In one embodiment: the method further comprises the steps.

[0083] S107 (not shown), when the OAuth server determines that the first client has logged in normally, the OAuth server generates a second access token and returns the second access token to the first client, so that the first application on the first client sends a second login request to the OAuth server, and the second login request includes the second access token. The OAuth server verifies that the second access token is correct and returns a third access token to the first application. The third access token includes ordinary user permission information and the identifier of the first application, so that the first application establishes a local session with the first client based on the third access token.

[0084] It should be noted that in the above embodiment, the first client and the second client do not represent two clients, but may also represent multiple clients. Specifically, the method of the present application is to determine that when the same account is logged in at the same time on multiple clients, the OAuth server can verify the login status of each client, give the normally logged-in client a second access token, and log out the abnormally logged-in client.

[0085] Therefore, step S106 is not only the processing process of the OAuth server when the second client logs in abnormally, but the OAuth server performs the same processing on all clients judged to have logged in abnormally; similarly, step S107 is not only the processing process of the OAuth server when the first client logs in normally, but the OAuth server performs the same processing on all clients judged to have logged in normally by the OAuth server.

[0086] As a possible implementation method, when multiple clients are judged as normal logins by the OAuth server, multiple accounts can be logged in on multiple terminals at the same time. When multiple clients are judged as abnormal logins by the OAuth server, all clients will be logged out.

[0087] In one embodiment: the method further comprises:

[0088] The OAuth server records abnormal login information of the second client, receives the abnormal login query request of the first client, and sends the abnormal login information of the second client to the first client.

[0089] It is understandable that when an ordinary user uses his or her account to log in normally on the first client, when encountering secondary verification, he or she will realize that his or her account is logged in on the second client. If this ordinary user thinks that the second client is an abnormal login, he or she can send an abnormal login query request to the OAuth server. The OAuth server sends the abnormal login information of the second client to the first client. The abnormal login information includes the login method of the second client, such as username account login, security question login, mobile phone verification code login, etc.

[0090] By adopting the above technical solution, ordinary users can know the abnormal login method of the second client, and can understand which of their information has been leaked, and then modify the leaked information in time.

[0091] For example, if an ordinary user knows that the second client is logged in through a username account, he or she can change the username and password in time.

[0092] In one embodiment: the method further comprises:

[0093] The OAuth server receives a permission change request sent by the first application, where the permission change request includes a third access token. The OAuth server verifies that the third access token is correct. The OAuth server determines the first tenant corresponding to the first application based on the identifier of the first application and a pre-stored application identifier tenant relationship table. The OAuth server sends a trigger request to the first application, where the trigger request includes a permission change condition set by the first tenant. The OAuth server receives feedback information sent by the first application based on the permission change condition. The OAuth server determines that the feedback information is consistent with preset standard information. The OAuth returns a third access token to the first application, where the third access token includes the changed permission information.

[0094] By adopting the above technical solution, the OAuth server sends a change notification message to the first application through the preset permission change conditions to make permission changes. Compared with manual permission changes, the changes are efficient and timely.

[0095] It should be noted that the OAuth server sets permissions through the RBAC permission model, and the OAuth server is equipped with a fiiOAuth user system, such as Figure 2 As shown, the initial setting process flow of permissions includes the following steps.

[0096] The super administrator logs in to the fiiOAuth user system, adds application information, and presets application administrator and administrator roles. The super administrator logs out.

[0097] The application administrator logs in to the fiiOAuth user system, adds application roles or permission information, sets roles or permissions for ordinary users, and then logs out.

[0098] An ordinary user logs on to the first application through single sign-on. The first application obtains its role and permission information from the user information returned. The first application performs permission control on the user's operation and ends.

[0099] The first application is set on the first client. The process of obtaining permissions for the first application by a common user through single-point login is as follows: Figure 3 shown.

[0100] An ordinary user sends a single sign-on request to the OAuth server through the first application. The single sign-on request includes the first account information. The OAuth server verifies that the first account information is correct and returns a second access token to the first application. The first application requests the OAuth server to obtain user information through the second access token. The OAuth server verifies that the second access token is correct and returns a third access token to the first application. The third access token includes the ordinary user's permission information.

[0101] It should be noted that the super administrator also added department management to the OAuth server and used RBA to implement effective access control methods for enterprise security policies to design role permission modules, making the application's permission control over users more powerful.

[0102] Moreover, user data, department data, and role permission data can all be imported into the fiiOAuth user system and imported remotely by the first application with a valid token, making user information maintenance more convenient.

[0103] Among them, the application administrator is the tenant, and multiple application administrators are multiple tenants. The OAuth server supports the docking of user data of different tenants and supports providing third-party docking services for different applications.

[0104] Each tenant can log in to the fiiOAuth user system to actively set the roles, information, and permissions of its applications and ordinary users.

[0105] Each tenant can also change the permissions of ordinary users based on the permission change applications of their ordinary users. However, if multiple ordinary users submit permission change applications at the same time, the tenant needs to process them one by one according to the permission change requests of multiple ordinary users, which will be very inefficient.

[0106] As a possible implementation method, the tenant can set the permission change conditions in the OAuth server. When an ordinary user sends a permission change request to the OAuth server through the first application, the OAuth server directly returns the conditions required for changing the permission to the ordinary user, such as requiring the ordinary user to enter the corresponding answer to the question, recharge, etc. After the ordinary user meets the permission change requirements, the first application will feedback information to the OAuth server. The OAuth server determines that the feedback information is consistent with the preset standard information, and returns a third access token to the first application. The third access token includes the changed permission information.

[0107] It is understandable that after the permission information is changed, the OAuth server updates the database.

[0108] It should be noted that the session data after the user logs in will be cached in Redis for use by other nodes in the cluster.

[0109] like Figure 4As shown in the figure, as a possible implementation method, the OAuth server combines the powerful advantages of microservices, expands the cluster deployment configuration, and adopts the microservice architecture for deployment in the cluster, so as to achieve automatic circuit breaking and automatically select the optimal node to provide services, avoiding possible downtime and slow response in high concurrency situations.

[0110] The first client sends a login request to the authentication server cluster through the first reverse proxy server. The login request includes the first account information. The login authentication server cluster verifies that the first account information is correct and returns a second access token to the first client through the first reverse proxy server. The first client requests the service gateway cluster to obtain the user's permission information on a certain microservice through the second access token and the second reverse proxy server. The service gateway cluster requests the authentication server cluster to verify the validity of the second access token. The authentication server cluster returns the verification result to the server gateway cluster. If the second access token is invalid, the server gateway cluster abandons the first client's request and prompts that the authentication is invalid. If the second access token is valid, the server gateway cluster releases the first client's request and allows the first client to log in to the microservice. The microservice returns a third access token to the first client through the service gateway cluster and the second reverse proxy server.

[0111] As a possible implementation method, the microservice can also access the authentication server cluster to perform a secondary verification of the second access token.

[0112] The embodiment of the present application provides an OAuth server 10, such as Figure 5 As shown, the OAuth server 10 includes:

[0113] The communication unit 101 is configured to receive a first login application sent by the first client, where the first login application includes first account information of a common user;

[0114] Memory 102, used to store first account information, second account information, and set standard verification information;

[0115] a processor 103 connected to the communication unit 101 and the memory 102, respectively, for authenticating the first account information, determining that the first account information is correct, and determining that the ordinary user is logged in to the second client based on the first account information;

[0116] The communication unit 101 is used to send a first verification request to the first client; the communication unit 101 is used to receive second account information sent by the first client based on the first verification request;

[0117] The communication unit 101 is used to send a second verification request to the second client; the communication unit 101 is used to receive the third account information sent by the second client based on the second verification request;

[0118] The processor 103 is further configured to compare the second account information and the third account information with the standard verification information set in the memory 102 respectively. The processor 103 is configured to determine the login status of the first client and the second client based on the comparison results, where the login status includes abnormal login and normal login.

[0119] The processor 103 may be a central processing unit (CPU), and may also include 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.

[0120] The memory 102 can be used to store computer programs and / or modules / units. The processor 103 implements various functions by running or executing the computer programs and / or modules / units stored in the memory 102 and calling data stored in the memory 102. The memory 102 may include an external storage medium or a memory. In addition, the memory 102 may include a high-speed random access memory or a non-volatile memory, such as a hard disk, a memory, a plug-in hard disk, a smart media card (SMC), a secure digital (SD) card, a flash card, at least one disk storage device, a flash memory device, or other volatile solid-state storage device.

[0121] In one embodiment: the memory 102 is further used to store the first access token of the second client, the global session between the processor 103 and the second client, and the processor 103 is used to, when determining that the second client has logged in abnormally, delete the first access token and destroy the global session, and at the same time initiate a logout request to all applications on the second client registered with the first access token through the communication unit 101, so that the applications on the second client destroy the local sessions established with the second client.

[0122] In one embodiment: the memory 102 is also used to store the second access token of the first client, and the processor 103 is used to determine that the first client is logged in normally. The processor 103 is also used to generate a second access token and return the second access token to the first client through the communication unit 101, so that the first application on the first client sends a second login application to the communication unit 101, and the second login application includes the second access token. The processor 103 is also used to verify that the second access token is correct, generate a third access token and return the third access token to the first application through the communication unit 101, and the third access token includes ordinary user permission information and the identifier of the first application, so that the first application establishes a local session with the first client based on the third access token.

[0123] In one embodiment: the memory 102 is also used to store the application tenant relationship table, permission change conditions, and preset standard information; the communication unit 101 is used to receive a permission change request sent by the first application, the permission modification request includes a third access token; the processor 103 is also used to verify that the third access token is correct; the processor 103 is used to determine the first tenant corresponding to the first application based on the identifier of the first application and the stored application-tenant relationship table; the communication unit 101 is also used to send a trigger request to the first application, the trigger request includes the permission change condition set by the first tenant; the communication unit 101 is used to receive feedback information sent by the first application based on the permission change condition; the processor 103 is used to determine that the feedback information is consistent with the preset standard information, and change the permission according to the permission change request.

[0124] An embodiment of the present application provides a computer-readable storage medium having a computer program stored thereon. When the computer program is executed by the OAuth server 10 , the above method is implemented.

[0125] 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 embodiment method, which can also be completed by hardware related to computer-readable program instructions. The computer-readable program instructions can be stored in a computer-readable storage medium. When the computer-readable program instructions are executed by the processor 103, the steps of the various method embodiments can be implemented. It should be noted that the content contained in the computer-readable medium can be appropriately increased or decreased according to the requirements of the legislation and patent practice in the jurisdiction. For example, in some jurisdictions, according to legislation and patent practice, computer-readable media do not include electric carrier signals and telecommunication signals.

[0126] The computer-readable program instructions described herein can be downloaded from a computer-readable storage medium to a corresponding computing processing device, or downloaded to an external computer or external storage device or wireless network via a network (e.g., the Internet, a local area network, a wide area network, and the Internet). The network may include copper transmission cables, optical transmission fibers, wireless transmission, routers, firewalls, switches, gateway computers, and / or edge servers. The network adapter card or network interface in each computing processing device receives the computer-readable program instructions from the network and forwards the computer-readable program instructions to be stored in a computer-readable storage medium within each computing processing device.

[0127] The computer-readable program instructions for performing the operations of the present invention may be assembler instructions, instruction set architecture (ISA) instructions, machine instructions, machine-dependent instructions, microcode, firmware instructions, state setting data, configuration data for an integrated circuit, or source code or object code language written in any combination of one or more programming languages ​​(including object-oriented programming languages, such as Smalltalk, C++, etc.) and procedural programming languages ​​(such as the "C" programming language or similar programming). The computer-readable program instructions may be executed entirely on a regular user computer, partially on a regular user computer, as a standalone software package, partially on a regular user computer and partially on a remote computer, or entirely on a remote computer or server. In the latter case, the remote computer may be connected to the regular user computer via any type of network, including a local area network (LAN) or a wide area network (WAN), or may be connected to an external computer (for example, via the Internet using an Internet service provider). In some embodiments, electronic circuits including, for example, programmable logic circuits, field programmable gate arrays (FPGAs), or programmable logic arrays (PLAs) may be personalized using state information of the computer-readable program instructions.

[0128] The flowcharts and block diagrams in the accompanying drawings illustrate possible implementation architectures, functions, and operations of devices, methods, and computer program products according to various embodiments of the present invention. In this regard, each box in the flowchart or block diagram may represent a module, fragment, or portion of an instruction that includes one or more executable instructions for implementing a specified logical function. In some alternative embodiments, the functions indicated in the box may not occur in the order indicated in the figure. For example, depending on the functions involved, two boxes shown in succession may actually be executed substantially simultaneously, or the boxes may sometimes be executed in the opposite order. It should also be noted that each box in the block diagram and / or flowchart, as well as combinations of boxes in the block diagram and / or flowchart, may be implemented by a dedicated hardware-based system that performs a specified function or action or is based on a specific purpose.

[0129] The description of various embodiments of the present invention has been given for the purpose of illustration and is not intended to be exhaustive or to limit the invention to the disclosed forms. Many modifications and variations will be apparent to those skilled in the art without departing from the scope and spirit of the invention. The embodiments were chosen and described in order to best explain the principles of the invention and practical application and to enable others skilled in the art to understand the various embodiments of the invention with various modifications suitable for the specific use contemplated.

Claims

1. An authorization method based on the OAuth standard, applied to a system, the system comprising an OAuth server, a first client and a second client, characterized in that: The method comprises: The OAuth server receives a first login application sent by the first client, where the first login application includes first account information of a common user; The OAuth server authenticates the first account information; Determining, based on the first account information, that the ordinary user has logged in to the second client; The OAuth server sends a first verification request to the first client, and the OAuth server receives second account information generated by the first client based on the first verification request; The OAuth server sends a second verification request to the second client, and the OAuth server receives third account information generated by the second client based on the second verification request; The OAuth server compares the second account information and the third account information with the set standard verification information respectively, and determines the login status of the first client and the second client according to the comparison results, where the login status includes abnormal login and normal login; Log out the account of the client whose login status is the abnormal login.

2. The OAuth-based authorization method according to claim 1, wherein: The method further comprises: When the OAuth server determines that the second client has logged in abnormally, the OAuth server deletes the first access token of the second client, destroys the global session established with the second client, and simultaneously initiates a logout request to all applications on the second client that are registered based on the first access token, so that the applications on the second client destroy the local sessions established with the second client.

3. The OAuth-based authorization method according to claim 2, wherein: The method further comprises: When the OAuth server determines that the first client has logged in normally, the OAuth server generates a second access token and returns the second access token to the first client, so that the first application on the first client sends a second login application to the OAuth server, and the second login application includes the second access token. The OAuth server verifies that the second access token is correct and returns a third access token to the first application. The third access token includes ordinary user permission information and the identifier of the first application, so that the first application establishes a local session with the first client based on the third access token.

4. The authorization method based on the OAuth standard according to claim 3, characterized in that: The method further comprises: The OAuth server records abnormal login information of the second client, receives the abnormal login query request of the first client, and sends the abnormal login information of the second client to the first client.

5. The authorization method based on the OAuth standard according to claim 3, characterized in that: The method further comprises: The OAuth server receives a permission change request sent by the first application, where the permission change request includes a third access token. The OAuth server verifies that the third access token is correct. The OAuth server determines the first tenant corresponding to the first application based on the identifier of the first application and a pre-stored application identifier tenant relationship table. The OAuth server sends a trigger request to the first application, where the trigger request includes a permission change condition set by the first tenant. The OAuth server receives feedback information sent by the first application based on the permission change condition. The OAuth server determines that the feedback information is consistent with preset standard information. The OAuth server returns a third access token to the first application, where the third access token includes the changed permission information.

6. An OAuth server, characterized in that: The OAuth server includes, A communication unit, configured to receive a first login application sent by a first client, wherein the first login application includes first account information of a common user; A memory, configured to store the first account information, the second account information, and set standard verification information; a processor, connected to the communication unit and the memory, respectively, configured to authenticate the first account information, determine that the first account information is correct, determine that the ordinary user is logged in to the second client based on the first account information, and generate a first verification request and a second verification request; The communication unit is further configured to send a first verification request to the first client; the communication unit is configured to receive second account information sent by the first client based on the first verification request; The communication unit is further configured to send a second verification request to the second client; the communication unit is configured to receive third account information sent by the second client based on the second verification request; The processor is further configured to compare the second account information and the third account information with standard verification information set in the memory, and the processor is further configured to determine the login status of the first client and the second client based on the comparison results, wherein the login status includes abnormal login and normal login; Log out the account of the client whose login status is the abnormal login.

7. The OAuth server according to claim 6, wherein: The memory is further configured to store the first access token of the second client, the global session between the processor and the second client, and the processor is further configured to, when determining that the second client has logged in abnormally, delete the first access token and destroy the global session, and simultaneously initiate a logout request to all applications on the second client registered with the first access token through the communication unit, so that the applications on the second client destroy the local sessions established with the second client.

8. The OAuth server according to claim 7, wherein: The memory is also used to store a second access token of the first client. When the processor determines that the first client has logged in normally, the processor is further used to generate a second access token and return the second access token to the first client through the communication unit, so that the first application on the first client sends a second login application to the communication unit, and the second login application includes the second access token. The processor is also used to verify that the second access token is correct, generate a third access token, and return the third access token to the first application through the communication unit, and the third access token includes ordinary user permission information and the identifier of the first application, so that the first application establishes a local session with the first client based on the third access token.

9. The OAuth server according to claim 8, wherein: The memory is further used to store an application tenant relationship table, permission change conditions, and preset standard information; the communication unit is used to receive a permission change request sent by the first application, the permission change request including a third access token; the processor is further used to verify that the third access token is correct; the processor is used to determine the first tenant corresponding to the first application based on the identifier of the first application and the stored application-tenant relationship table; the communication unit is further used to send a trigger request to the first application, the trigger request including the permission change conditions set by the first tenant; the communication unit is used to receive feedback information sent by the first application based on the permission change conditions; the processor is used to determine that the feedback information is consistent with the preset standard information, and change the permission according to the permission change request.

10. A computer-readable storage medium, characterized in that The computer-readable storage medium stores a computer program, which implements the method according to any one of claims 1 to 5 when executed by the OAuth server.

Images