CN115580416A - Authorization method based on OAuth standard, OAuth server and storage medium - Google Patents

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

Info

Publication number
CN115580416A
CN115580416A CN202110744652.6A CN202110744652A CN115580416A CN 115580416 A CN115580416 A CN 115580416A CN 202110744652 A CN202110744652 A CN 202110744652A CN 115580416 A CN115580416 A CN 115580416A
Authority
CN
China
Prior art keywords
client
application
oauth
login
access token
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Pending
Application number
CN202110744652.6A
Other languages
Chinese (zh)
Inventor
高子和
王敏
谢凤胜
杨煜胜
吴静峰
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Shenzhen Fulian Fugui Precision Industry Co Ltd
Original Assignee
Shenzhen Fugui Precision Industrial Co Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Shenzhen Fugui Precision Industrial Co Ltd filed Critical Shenzhen Fugui Precision Industrial Co Ltd
Priority to CN202110744652.6A priority Critical patent/CN115580416A/en
Publication of CN115580416A publication Critical patent/CN115580416A/en
Pending legal-status Critical Current

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/10—Network architectures or network communication protocols for network security for controlling access to devices or network resources
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
    • H04L63/0807—Network architectures or network communication protocols for network security for authentication of entities using tickets, e.g. Kerberos
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/14—Session management
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/14—Session management
    • H04L67/143—Termination or inactivation of sessions, e.g. event-controlled end of session
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/321—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving a third party or a trusted authority
    • H04L9/3213—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving a third party or a trusted authority using tickets or tokens, e.g. Kerberos

Abstract

The invention provides an authorization method based on OAuth standard, which comprises the following steps: the OAuth server receives a first login application sent by a first client, wherein the first login application comprises first account information of a common user; the OAuth server determines that the common user logs in the second client based on the first account information; the OAuth server sends a first verification request to the first client, receives second account information generated by the first client, sends a second verification request to the second client, and 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 states of the first client and the second client according to the comparison result, logs out the account of the client which logs in abnormally, and prevents the information of the user from being in a continuous leakage state.

Description

Authorization method based on OAuth standard, OAuth server and storage medium
Technical Field
The invention relates to the technical field of computer communication, in particular to an authorization method based on an OAuth standard, an OAuth server and a storage medium.
Background
The OAuth standard is widely used on the internet as the most popular authentication and authorization access protocol for a third party Application Program Interface (API) in the industry, and can enable a user to expose information stored by the user at a certain service provider to a third party application without exposing a secret key.
However, such OAuth servers currently have the following problems: if the account information of one user is logged in at a certain client, and the OAuth server detects that the same account information sends a login request at another client, the OAuth server cannot determine which of the two clients is logged in normally.
Disclosure of Invention
In view of the foregoing, there is a need to provide an authorization method based on OAuth standard, an OAuth server and a storage medium, so as to solve the technical problem that it is difficult for the OAuth server to determine the normal login status of multiple clients.
The embodiment of the application provides an authorization method based on OAuth standard, which is applied to a system, wherein the system comprises an OAuth server, a first client and a second client, and the method comprises the following steps:
the OAuth server receives a first login application sent by the first client, wherein the first login application comprises first account information of a common user;
the OAuth server authenticates the first account information;
determining that the common user has logged in at a second client based on the first account information;
the OAuth server sends a first verification request to a first client, and receives second account information generated by the first client based on the first verification request;
the OAuth server sends a second verification request to a 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 set standard verification information respectively, and determines login states of the first client and the second client according to comparison results, wherein the login states comprise abnormal login and normal login.
The login states of the two clients are simultaneously identified by adopting an authentication mode different from the first login mode, so that which client is abnormally logged in and which client is normally logged in can be accurately identified, and the client logged in for the second time is not defaulted to be abnormally logged in, and the normal login behavior of the user can be better guaranteed.
In one embodiment: the method further comprises the following steps:
when the OAuth server judges that the second client is abnormally logged in, 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 registered on the second client based on the first access token, so that the applications on the second client destroy the local session established with the second client.
When the OAuth server receives a login request sent by a logged-in account from another client, the login states of the two clients are verified, the login states are judged according to the feedback information of the two clients, and the account of the client which logs in abnormally is logged out, so that the data information of the user can be prevented from being continuously in a leakage state.
In one embodiment: the method further comprises the following steps:
when the OAuth server judges that the first client logs in normally, the OAuth server generates a second access token and returns the second access token to the first client, so that a first application on the first client sends a second login application to the OAuth server, the second login application comprises 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, and the third access token comprises common user permission information and an identifier of the first application, so that the first application establishes a local session with the first client according to the third access token.
The OAuth server gives a second access token to the normally logged-in client, so that the client confirmed to be in a normal login state can be prevented from being influenced by the prior login.
In one embodiment: the method further comprises the following steps:
and the OAuth server records abnormal login information of a second client, receives an abnormal login query request of the first client and sends the abnormal login information of the second client to the first client.
The OAuth server obtains the abnormal login information of the second client, so that the common user can know the abnormal login mode of the second client, know which information is leaked and timely modify the leaked information,
in one embodiment: the method further comprises the following steps:
the OAuth server receives an authority change request sent by the first application, the authority change request comprises a third access token, the OAuth server verifies that the third access token is correct, the OAuth server determines a first tenant corresponding to the first application according to an identifier of the first application and a prestored application identifier tenant relation table, the OAuth server sends a trigger request to the first application, the trigger request comprises an authority change condition set by the first tenant, the OAuth server receives feedback information sent by the first application based on the authority change condition, the OAuth server determines that the feedback information is consistent with preset standard information, the OAuth returns the third access token to the first application, and the third access token comprises changed authority information.
And issuing change notification information to the first application through the permission change condition preset by the OAuth server to change the permission, so that the permission change of the scheme is more efficient and timely compared with manual permission change.
The embodiment of the present application further provides an OAuth server, which includes,
the communication unit is used for receiving a first login application sent by the first client, wherein the first login application comprises first account information of a common user;
the memory is used for storing the first account information, the second account information and the set standard verification information;
the processor is respectively connected with the communication unit and the memory and is used for authenticating the first account information, determining that the first account information is correct, and determining that the common user is in a login state at a second client based on the first account information;
the communication unit is used for sending a first verification request to the first client; the communication unit is used for receiving second account information sent by the first client based on the first verification request;
the communication unit is used for sending a second verification request to the second client; the communication unit is used for receiving the 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 a memory, and determine login states of the first client and the second client according to a comparison result, where the login states include abnormal login and normal login.
In one embodiment: the memory is further used for storing a first access token of a second client, and a global session between the processor and the second client, and the processor is further used for deleting the first access token and destroying the global session when the second client is judged to be abnormally logged in, and meanwhile, initiating a logout request to all applications registered with the first access token on the second client through a communication unit, so that the applications on the second client destroy a local session established with the second client.
In one embodiment: the memory is further used for storing a second access token of the first client, the processor is further used for generating the second access token and returning the second access token to the first client through the communication unit when the first client is judged to normally log in, so that the first application on the first client sends a second login application to the communication unit, the second login application comprises the second access token, the processor is further used for verifying that the second access token is correct, generating a third access token and returning the third access token to the first application through the communication unit, and the third access token comprises common user permission information and an identifier of the first application, so that the first application establishes a local session with the first client according to the third access token.
In one embodiment: the memory is further used for storing an application tenant relationship table, permission changing conditions and preset standard information, the communication unit is used for receiving a permission changing request sent by the first application, the permission modifying request comprises a third access token, the processor is further used for verifying the correctness of the third access token, the processor is used for determining a first tenant corresponding to the first application according to the identification of the first application and the stored application-tenant relationship table, the communication unit is further used for sending a triggering request to the first application, the triggering request comprises the permission changing conditions set by the first tenant, the communication unit is used for receiving feedback information sent by the first application based on the permission changing conditions, and the processor is used for determining that the feedback information is consistent with the preset standard information and changing the permission according to the permission changing request.
An embodiment of the present application further provides a computer-readable storage medium, on which a computer program is stored, where the computer program, when executed by the OAuth server, implements the method described above.
And when the OAuth server receives a login request sent by a logged-in account from another client, verifying the login states of the two clients, judging the login states according to the feedback information of the two clients, logging out the account of the client which logs in abnormally, and preventing the data of the user from being continuously in a leakage state.
Drawings
Fig. 1 is a flowchart of an authorization method based on OAuth standard according to an embodiment of the present invention.
Fig. 2 is a flowchart of a privilege setting process according to an embodiment of the present invention.
Fig. 3 is a schematic diagram of a process for acquiring rights by a general user according to an embodiment of the present invention.
Fig. 4 is a schematic diagram of cluster deployment of an OAuth server according to an embodiment of the present invention.
Fig. 5 is a schematic structural diagram of an OAuth server according to an embodiment of the present invention.
Description of the main elements
OAuth server 10
Communication unit 101
Memory device 102
Processor with a memory for storing a plurality of data 103
Detailed Description
In order to make the objects, technical solutions and advantages of the present invention more apparent, 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 merely illustrative of the invention and are not intended to limit the invention. All other embodiments, which can be derived by a person skilled in the art from the embodiments given herein without making any creative effort, shall fall within the protection scope of the present invention.
OAuth (open authorization) is an open standard that allows a user to have a third party application access to private resources (e.g., photos, videos, contact lists) that the user stores on a website without having to provide the third party application with a username and password. At present, the version of OAuth is 2.0, and the OAuth server in the application is realized based on an OAuth2.0 protocol.
If account information of a user is logged in a certain client, the OAuth server detects that the same account information sends a login request at another client, in the prior art, the OAuth server defaults that the first login is normal login, and sends a notification of the second login to the client which logs in for the first time for confirmation, but does not consider that if the first login is abnormal login, a common user which logs in for the second time cannot log in normally, so that the conventional OAuth server is difficult to determine normal login conditions of a plurality of clients, namely cannot identify which one of the two clients is normal login.
The embodiment of the application provides an authorization method based on OAuth standard, which is applied to a system, wherein the system comprises an OAuth server, a first client and a second client, and the method comprises the following steps:
the OAuth server receives a first login application sent by the first client, wherein the first login application comprises first account information of a common user;
the OAuth server authenticates the first account information;
determining that the common user has logged in at a second client based on the first account information;
the OAuth server sends a first verification request to a first client, and receives second account information generated by the first client based on the first verification request;
the OAuth server sends a second verification request to a 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 set standard verification information respectively, and determines login states of the first client and the second client according to comparison results, wherein the login states comprise abnormal login and normal login.
The login states of the two clients are simultaneously identified by adopting the verification mode different from the first login mode, so that which client is abnormally logged in and which client is normally logged in can be accurately identified, and the client which logs in for the second time is not defaulted to be abnormally logged in, so that the normal login behavior of the user can be better guaranteed.
The embodiment of the application also provides an OAuth server, which comprises,
the communication unit is used for receiving a first login application sent by the first client, wherein the first login application comprises first account information of a common user;
the memory is used for storing the first account information, the second account information and the set standard verification information;
the processor is respectively connected with the communication unit and the memory and is used for authenticating the first account information, determining that the first account information is correct, and determining that the common user is in a login state at a second client based on the first account information;
the communication unit is used for sending a first verification request to the first client; the communication unit is used for receiving second account information sent by the first client based on the first verification request;
the communication unit is used for sending a second verification request to the second client; the communication unit is used for receiving the 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 a memory, and the processor is configured to determine login states of the first client and the second client according to a comparison result, where the login states include abnormal login and normal login.
An embodiment of the present application further provides a computer-readable storage medium, on which a computer program is stored, where the computer program, when executed by the OAuth server, implements the method described above.
And when the OAuth server receives a login request sent by a logged-in account from another client, verifying the login states of the two clients, judging the login states according to the feedback information of the two clients, logging out the account of the client which logs in abnormally, and preventing the data of the user from being continuously in a leakage state.
Some embodiments of the invention will be described in detail below with reference to the accompanying drawings.
As shown in fig. 1, a first embodiment of the present application provides an authorization method based on OAuth standard.
The method comprises the following steps.
S101, the OAuth server receives a first login application sent by the first client, wherein the first login application comprises first account information of a common user.
It should be noted that the first client may be a mobile phone, a computer, a tablet, or the like; in the application, the first client uses a mobile phone as an example, the first account information includes a user name and a password of the user, and may also include a short message authentication code login and the like, and in the application, the first account information is the user name and the password of the user.
S102, the OAuth server authenticates the first account information; determining that the common user is logged in at a second client based on the first account information.
It should be noted that the second client may be a mobile phone, a computer, a tablet, or the like.
In the application, the second client uses a tablet as an example, for example, a user a logs in a certain application on a mobile phone by using a user name and a password, a MySQL database is arranged in the OAuth server, a user name and password correspondence table of each user is stored in the MySQL database, the OAuth server receives the user name and the password of the user a, compares the user name and the password with the correspondence table stored in the MySQL database, if the MySQL database has the corresponding user name and password, it is proved that the user name and the password input by the user a are correct, the OAuth server finds that a login token has been generated based on the user name and password of the user a and sends the login token to the tablet through a stored session record, which means that the user B logs in on the tablet before the user a logs in, the user a and the user B may refer to the same person or different persons in the application, and the OAuth server needs to judge which of the mobile phone and the tablet log in normally.
S103, the OAuth server sends a first verification request to a first client, and the OAuth server receives second account information generated by the first client based on the first verification request.
And S104, the OAuth server sends a second verification request to a second client, and the OAuth server receives the third account information generated by the second client based on the second verification request.
It should be noted that the first authentication request and the second authentication request sent by the OAuth server are to let the user a and the user B input information different from the first input for login, for example, the second client logs in through the user name and the password for the first time, then the second authentication request is no longer to input the user name and the password, for example, login is performed in a short message random code manner, if the first client logs in through the short message random code for the first time, the first authentication request is no longer to input the short message random code, for example, to input the user name and the password.
The user A and the user B are different people, the user B is a hacker, the user A obtains a user name and a password of the user A, the user name and the password are used for sending a login request to an OAuth server and successfully logging in a second client, the user A sends the login request to the OAuth server at a first client based on the same user name and password, the OAuth server receives the login request of the user A, the user name and the password are identified and then the user name and the password are found to be logged in, at the moment, the OAuth server simultaneously sends an authentication request of inputting a short message random code to the first client and the second client, the hacker does not obtain a mobile phone of an account A owner, so the hacker cannot log in through a correct short message authentication code, the OAuth receives authentication code feedback of the first client and the second client, identifies an incorrect authentication code, and can judge that the second client logs in abnormally, and the first client logs in normally.
And S105, the OAuth server compares the second account information and the third account information with set standard verification information respectively, and determines login states of the first client and the second client according to a comparison result, wherein the login states comprise abnormal login and normal login.
The OAuth server can judge that the second client is abnormally logged in by receiving the wrong short message verification code or not receiving the verification code.
The login states of the two clients are simultaneously identified by adopting the verification mode different from the first login mode, which client is abnormal login and which client is normal login can be accurately identified, and the client which logs in for the second time is not considered as abnormal login by default, so that compared with the prior art, the method and the device can provide guarantee for normal login behaviors of the user.
In one embodiment: the method further comprises the step.
And S106 (not shown), when the OAuth server determines that the second client logs 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 registered on the second client based on the first access token, so that the applications on the second client destroy the local session established with the second client.
Through the technical scheme, when the OAuth server receives a login request sent by a logged-in account from another client, the login states of the two clients are verified, the login states are judged according to the feedback information of the two clients, the account of the client which logs in abnormally is logged out, and the data information of the user is prevented from being continuously in a leakage state.
In one embodiment: the method further comprises the step.
S107 (not shown), when the OAuth server determines that the first client normally logs in, 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, where 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, where the third access token includes the general user permission information and the identifier of the first application, so that the first application establishes a local session with the first client according to the third access token.
It should be noted that, in the above embodiment, the first client and the second client do not represent two clients, but may represent multiple clients, and specifically, the method of the present application is to determine that when there is an identical account in the multiple clients simultaneously in the login state, the OAuth server may verify the login state of each client, give the second access token to the normally logged-in client, and log out the abnormally logged-in client.
Therefore, in step S106, not only is the processing procedure of the OAuth server performed when the second client is abnormally logged in, but all the clients determined to be abnormally logged in perform the same processing; similarly, step S107 is not only the processing procedure of the OAuth server when the first client normally logs in, but also the processing procedure of all clients judged by the OAuth server to normally log in, and the OAuth server performs the same processing.
As a possible implementation manner, when all the clients are judged to normally log in by the OAuth server, the multiple accounts can log in at multiple ends at the same time, and when all the clients are judged to abnormally log in by the OAuth server, the multiple clients can be logged out.
In one embodiment: the method also includes.
The OAuth server records abnormal login information of a second client, receives an abnormal login query request of the first client, and sends the abnormal login information of the second client to the first client.
It can be understood that when an ordinary user uses an own account to normally log in an account at a first client, the ordinary user can understand that the own account logs in at a second client when encountering secondary verification, if the ordinary user thinks that the second client is abnormally logged in, the ordinary user can send an abnormal login query request to an OAuth server, the OAuth server sends abnormal login information of the second client to the first client, and the abnormal login information comprises login modes of the second client, such as user name account login, secret protection problem login, mobile phone verification code login and the like.
By adopting the technical scheme, the ordinary user can know the abnormal login mode of the second client, can know which information is leaked, and then timely modifies the leaked information.
For example, if the ordinary user knows that the second client logs in through the username account, the user name and the password can be modified in time.
In one embodiment: the method also includes.
The OAuth server receives an authority change request sent by the first application, the authority change request comprises a third access token, the OAuth server verifies that the third access token is correct, the OAuth server determines a first tenant corresponding to the first application according to an identifier of the first application and a prestored application identifier tenant relation table, the OAuth server sends a trigger request to the first application, the trigger request comprises an authority change condition set by the first tenant, the OAuth server receives feedback information sent by the first application based on the authority change condition, the OAuth server determines that the feedback information is consistent with preset standard information, the OAuth returns the third access token to the first application, and the third access token comprises changed authority information.
By adopting the technical scheme, the OAuth server issues the change notification information to the first application through the preset permission change condition so as to change the permission, and compared with manual permission change, the OAuth server realizes efficient and timely change.
It should be noted that the OAuth server sets the rights through the RBAC rights model, and a fiiOAuth user system is provided in the OAuth server, as shown in fig. 2, the process flow of the initial setting of the rights includes the following steps.
And the super administrator logs in the fiiOAuth user system, adds application information, presets application administrators and administrator roles, and logs out by the super administrator.
And the application manager logs in the fiiOAuth user system, adds application role or authority information, sets roles or authorities for the common user, and logs out.
And (4) the common user logs in the first application in a single point mode, the first application acquires the role and the authority information of the first application from the user information return, and the first application controls the authority of the user operation and finishes.
The first application is set on the first client, and the process of the ordinary user for obtaining the authority by single sign-on of the first application for the first time is shown in fig. 3.
The method comprises the steps that a common user sends a single sign-on request to an OAuth server through a first application, the single sign-on request comprises first account information, the OAuth server verifies that the first account information is correct, a second access token is returned 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, a third access token is returned to the first application, and the third access token comprises common user authority information.
It should be noted that the super administrator also adds department management in the OAuth server, and designs the role permission module by using the RBA to implement an effective access control mode facing the enterprise security policy, so that the application can manage and control the permissions of the user more powerfully.
Moreover, the user data, the department data and the role authority data all support the import in the fiiOAuth user system and the input in the fiiOAuth user system by the first application in a remote import mode of the effective token, so that the user information maintenance is more convenient.
The OAuth server supports user data docking of different tenants and supports third-party docking service for different applications.
Each tenant can log in the fiiOAuth user system to actively set the application under the flag and the role, information and authority of the ordinary user.
Each tenant can also change the authority of the ordinary user according to the authority change application of the ordinary user under the flag, but if a plurality of ordinary users send the authority change application at the same time, the tenant needs to process the authority change requests of the ordinary users in a one-to-one correspondence manner, and the efficiency is very low.
As a possible implementation manner, a tenant may set an authority change condition in an OAuth server, when an ordinary user sends an authority change request to the OAuth server through a first application, the OAuth server directly returns a condition required for changing the authority to the ordinary user, for example, the ordinary user is required to input a corresponding question answer, recharge, and the like, after the ordinary user meets the authority change requirement, the ordinary user feeds back information to the OAuth server through the first application, the OAuth server determines that the feedback information is consistent with preset standard information, and returns a third access token to the first application, where the third access token includes the changed authority information.
It will be appreciated that the OAuth server updates the database after the rights information is changed.
It should be noted that session data after the user logs in will be cached in Redis for other nodes of the cluster to use.
As shown in fig. 4, as a possible implementation manner, the OAuth server combines the strong advantages of the micro-service, expands the cluster deployment configuration, deploys by adopting a micro-service architecture during cluster deployment, performs automatic fusing, automatically selects an optimal node to provide services, and avoids the situations of downtime, slow response and the like which may occur in the case of high concurrency.
The method comprises the steps that a first client sends a login request to an authentication server cluster through a first reverse proxy server, the login request comprises first account information, the login authentication server cluster verifies that the first account information is correct, a second access token is returned to the first client through the first reverse proxy server, the first client requests a service gateway cluster to acquire authority information of a user on a certain micro-service through the second access token and the second reverse proxy server, the service gateway cluster requests the authentication server cluster to check the validity of the second access token, the authentication server cluster returns a check result to the server gateway cluster, if the second access token is invalid, the server gateway cluster gives up the request of the first client and prompts that the authentication is invalid, if the second access token is valid, the server gateway cluster releases the request of the first client, the first client is allowed to log in the micro-service, and the micro-service returns a third access token to the first client through the service gateway cluster and the second reverse proxy server.
As a possible implementation manner, the microservice may also access the authentication server cluster to perform secondary verification on the second access token.
An embodiment of the present application provides an OAuth server 10, as shown in fig. 5, where the OAuth server 10 includes:
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 an ordinary user;
the memory 102 is used for storing the first account information, the second account information and the set standard verification information;
the processor 103 is connected to the communication unit 101 and the memory 102, and configured to authenticate the first account information, determine that the first account information is correct, and determine that the ordinary user is in a login state at a second client based on the first account information;
the communication unit 101 is configured to send a first authentication request to the first client; the communication unit 101 is configured to receive second account information sent by the first client based on the first authentication request;
the communication unit 101 is configured to send a second authentication request to a second client; the communication unit 101 is configured to receive the third account information sent by the second client based on the second authentication request;
the processor 103 is further configured to compare the second account information and the third account information with standard verification information set in the memory 102, and the processor 103 is configured to determine login states of the first client and the second client according to a comparison result, where the login states include abnormal login and normal login.
The Processor 103 may be a Central Processing Unit (CPU), and may include other general purpose processors, digital Signal Processors (DSPs), application Specific Integrated Circuits (ASICs), field-Programmable Gate arrays (FPGAs) or other Programmable logic devices, discrete Gate or transistor logic devices, discrete hardware components, etc.
The memory 102 may be used to store computer programs and/or modules/units, and the processor 103 may implement 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 storage 102 may include an external storage medium and may also include a memory. In addition, the memory 102 may include high speed random access memory, and may also include 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 memory Card (Flash Card), at least one magnetic disk storage device, a Flash memory device, or other volatile solid state storage device.
In one embodiment: the memory 102 is further configured to store a first access token of a second client, and a global session between the processor 103 and the second client, where the processor 103 is configured to delete the first access token and destroy the global session when it is determined that the second client logs in abnormally, and meanwhile, initiate a logout request to all applications registered with the first access token on the second client through the communication unit 101, so that the applications on the second client destroy a local session established with the second client.
In one embodiment: the memory 102 is further configured to store a second access token of the first client, and when the processor 103 is configured to determine that the first client normally logs in, the processor 103 is further configured to generate the 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, where the second login application includes the second access token, and the processor 103 is further configured 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, where the third access token includes common user permission information and an identifier of the first application, so that the first application establishes a local session with the first client according to the third access token.
In one embodiment: the memory 102 is further configured to store an application tenant relationship table, an authority change condition, and preset standard information, the communication unit 101 is configured to receive an authority change request sent by the first application, the authority modification request includes a third access token, the processor 103 is further configured to verify that the third access token is correct, the processor 103 is configured to determine a first tenant corresponding to the first application according to the identifier of the first application and the stored application-tenant relationship table, the communication unit 101 is further configured to send a trigger request to the first application, the trigger request includes the authority change condition set by the first tenant, the communication unit 101 is configured to receive feedback information sent by the first application based on the authority change condition, and the processor 103 is configured to determine that the feedback information is consistent with the preset standard information, and change the authority according to the authority change request.
One embodiment of the present application provides a computer-readable storage medium having stored thereon a computer program which, when executed by the OAuth server 10, implements the method described above.
May be stored in a computer readable storage medium. Based on such understanding, all or part of the processes in the method according to the embodiments of the present application may also be implemented by hardware associated with computer readable program instructions, which may be stored in a computer readable storage medium, and when the computer readable program instructions are executed by the processor 103, the steps of the various method embodiments may be implemented. It should be noted that the computer readable medium may contain content that is subject to appropriate increase or decrease as required by legislation and patent practice in jurisdictions, for example, in some jurisdictions, computer readable media does not include electrical carrier signals and telecommunications signals as is required by legislation and patent practice.
The computer-readable program instructions described herein may be downloaded from a computer-readable storage medium to a corresponding computing processing device, or may be 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 a network). The network may include copper transmission cables, optical transmission fibers, wireless transmissions, routers, firewalls, switches, gateway computers and/or edge servers, with the network adapter card or network interface in each computing processing device receiving computer-readable program instructions from the network and forwarding the computer-readable program instructions for storage in a computer-readable storage medium within the respective computing processing device.
Computer-readable program instructions for carrying out operations of the present invention may be assembler instructions, instruction Set Architecture (ISA) instructions, machine-related instructions, microcode, firmware instructions, state setting data, configuration data for an integrated circuit, or source or object code language written in any combination of one or more programming languages, including an object oriented programming language such as Smalltalk, C + + or the like and a procedural programming language such as the "C" programming language or the like. The computer-readable program instructions may execute entirely on the ordinary user computer, partly on the ordinary user computer, as a stand-alone software package, partly on the ordinary user computer and partly on a remote computer or entirely on the remote computer or server. In the latter scenario, the remote computer may be connected to the general user's computer through any type of network, including a Local Area Network (LAN) or a Wide Area Network (WAN), or the connection may be made to an external computer (for example, through the Internet using an Internet service provider). In some embodiments, an electronic circuit comprising, for example, a programmable logic circuit, a Field Programmable Gate Array (FPGA), or a Programmable Logic Array (PLA), may personalize computer-readable program instructions by utilizing state information of the computer-readable program instructions.
The flowchart and block diagrams in the figures illustrate the architecture, functionality, and operation of possible implementations of apparatus, methods and computer program products according to various embodiments of the present invention. In this regard, each block in the flowchart or block diagrams may represent a module, segment, or portion of instructions, which comprises one or more executable instructions for implementing the specified logical function(s). In some alternative implementations, the functions noted in the block may occur out of the order noted in the figures. For example, two blocks shown in succession may, in fact, be executed substantially concurrently, or the blocks may sometimes be executed in the reverse order, depending upon the functionality involved. It will also be noted that each block of the block diagrams and/or flowchart illustration, and combinations of blocks in the block diagrams and/or flowchart illustration, can be implemented by special purpose hardware-based systems that perform the specified functions or acts, or based on specific goals.
The description of various embodiments of the present invention has been presented for purposes of illustration but is not intended to be exhaustive or limited to the invention in the form disclosed. Many modifications and variations will be apparent to those of ordinary skill in the art without departing from the scope and spirit of the invention. The embodiment was chosen and described in order to best explain the principles of the invention and the practical application, and to enable others of ordinary skill in the art to understand the invention for various embodiments with various modifications as are suited to the particular use contemplated.

Claims (10)

1. An authorization method based on OAuth standard is applied to a system, the system comprises an OAuth server, a first client and a second client, and the method is characterized by comprising the following steps:
the OAuth server receives a first login application sent by the first client, wherein the first login application comprises first account information of a common user;
the OAuth server authenticates the first account information;
determining that the common user is logged in at a second client based on the first account information;
the OAuth server sends a first verification request to a first client, and receives second account information generated by the first client based on the first verification request;
the OAuth server sends a second verification request to a 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 set standard verification information respectively, and determines login states of the first client and the second client according to comparison results, wherein the login states comprise abnormal login and normal login.
2. The OAuth standard-based authorization method of claim 1, further comprising:
when the OAuth server judges that the second client is abnormally logged in, 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 registered on the second client based on the first access token, so that the applications on the second client destroy the local session established with the second client.
3. The OAuth standard-based authorization method of claim 2, further comprising:
when the OAuth server judges that the first client logs in normally, the OAuth server generates a second access token and returns the second access token to the first client, so that a first application on the first client sends a second login application to the OAuth server, the second login application comprises 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, and the third access token comprises common user permission information and an identifier of the first application, so that the first application establishes a local session with the first client according to the third access token.
4. The OAuth standard-based authorization method of claim 3, further comprising:
the OAuth server records abnormal login information of a second client, receives an abnormal login query request of the first client, and sends the abnormal login information of the second client to the first client.
5. The OAuth standard based authorization method according to claim 3, wherein the method further comprises:
the OAuth server receives an authority change request sent by the first application, the authority change request comprises a third access token, the OAuth server verifies that the third access token is correct, the OAuth server determines a first tenant corresponding to the first application according to an identifier of the first application and a prestored application identifier tenant relation table, the OAuth server sends a trigger request to the first application, the trigger request comprises an authority change condition set by the first tenant, the OAuth server receives feedback information sent by the first application based on the authority change condition, the OAuth server determines that the feedback information is consistent with preset standard information, the OAuth returns the third access token to the first application, and the third access token comprises changed authority information.
6. An OAuth server, comprising,
the system comprises a communication unit, a first client and a second client, wherein the communication unit is used for receiving a first login application sent by the first client, and the first login application comprises first account information of a common user;
the memory is used for storing the first account information, the second account information and the set standard verification information;
the processor is respectively connected with the communication unit and the memory, and is used for authenticating the first account information, determining that the first account information is correct, determining that the common user is in a login state at a second client based on the first account information, and generating a first verification request and a second verification request;
the communication unit is further configured to send a first authentication request to the first client; the communication unit is used for receiving second account information sent by the first client based on the first verification request;
the communication unit is further configured to send a second authentication request to the second client; the communication unit is used for receiving 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 a memory, and determine login states of the first client and the second client according to a comparison result, where the login states include abnormal login and normal login.
7. The OAuth server of claim 6, wherein,
the memory is further used for storing a first access token of the second client, and a global session between the processor and the second client, and the processor is further used for deleting the first access token and destroying the global session when the second client is judged to be abnormally logged in, and meanwhile, a logout request is initiated to all applications registered with the first access token on the second client through a communication unit, so that the applications on the second client destroy a local session established with the second client.
8. The OAuth server of claim 7, wherein,
the processor is further configured 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, where the third access token includes general user permission information and an identifier of the first application, so that the first application establishes a local session with the first client according to the third access token.
9. The OAuth server of claim 8, wherein,
the memory is further used for storing an application tenant relationship table, permission changing conditions and preset standard information, the communication unit is used for receiving a permission changing request sent by the first application, the permission modifying request comprises a third access token, the processor is further used for verifying the correctness of the third access token, the processor is used for determining a first tenant corresponding to the first application according to the identification of the first application and the stored application-tenant relationship table, the communication unit is further used for sending a triggering request to the first application, the triggering request comprises the permission changing conditions set by the first tenant, the communication unit is used for receiving feedback information sent by the first application based on the permission changing conditions, and the processor is used for determining that the feedback information is consistent with the preset standard information and changing the permission according to the permission changing request.
10. A computer-readable storage medium, having stored thereon a computer program which, when executed by the OAuth server, implements the method of any of claims 1 to 5.
CN202110744652.6A 2021-07-01 2021-07-01 Authorization method based on OAuth standard, OAuth server and storage medium Pending CN115580416A (en)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN202110744652.6A CN115580416A (en) 2021-07-01 2021-07-01 Authorization method based on OAuth standard, OAuth server and storage medium

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN202110744652.6A CN115580416A (en) 2021-07-01 2021-07-01 Authorization method based on OAuth standard, OAuth server and storage medium

Publications (1)

Publication Number Publication Date
CN115580416A true CN115580416A (en) 2023-01-06

Family

ID=84578831

Family Applications (1)

Application Number Title Priority Date Filing Date
CN202110744652.6A Pending CN115580416A (en) 2021-07-01 2021-07-01 Authorization method based on OAuth standard, OAuth server and storage medium

Country Status (1)

Country Link
CN (1) CN115580416A (en)

Similar Documents

Publication Publication Date Title
US11544356B2 (en) Systems and methods for dynamic flexible authentication in a cloud service
EP3691215B1 (en) Access token management method, terminal and server
US11063928B2 (en) System and method for transferring device identifying information
WO2018077169A1 (en) Image repository authorization, access and management method, server, and client
US20190199707A1 (en) Using a service-provider password to simulate f-sso functionality
CN106487774B (en) A kind of cloud host services authority control method, device and system
US6754829B1 (en) Certificate-based authentication system for heterogeneous environments
CN108964885B (en) Authentication method, device, system and storage medium
US8387136B2 (en) Role-based access control utilizing token profiles
US20170317999A1 (en) Security credential protection with cloud services
US20140050317A1 (en) Cloud Key Management System
US20180145830A1 (en) System for retrieval of email certificates from remote certificate repository
US10681023B2 (en) Self-service portal for provisioning passwordless access
JP2015535984A5 (en)
EP3226506A1 (en) Authorization processing method, device and system
US11695747B2 (en) Multi-device single sign-on
US20180307858A1 (en) Multi-party authentication and authorization
US20210279323A1 (en) Application authenticity verification in digital distribution systems
CN109756469B (en) Public account management method and device and computer readable storage medium
CN113302606A (en) Method and system for detecting unauthorized access
US20230016488A1 (en) Document signing system for mobile devices
CN112929388B (en) Network identity cross-device application rapid authentication method and system, and user agent device
CN115580416A (en) Authorization method based on OAuth standard, OAuth server and storage medium
US11275858B2 (en) Document signing system for mobile devices
US11416586B2 (en) Secure communication application registration process

Legal Events

Date Code Title Description
PB01 Publication
PB01 Publication
SE01 Entry into force of request for substantive examination
SE01 Entry into force of request for substantive examination