WO2021022792A1 - 一种鉴权与业务服务方法、装置以及设备 - Google Patents

一种鉴权与业务服务方法、装置以及设备 Download PDF

Info

Publication number
WO2021022792A1
WO2021022792A1 PCT/CN2020/071977 CN2020071977W WO2021022792A1 WO 2021022792 A1 WO2021022792 A1 WO 2021022792A1 CN 2020071977 W CN2020071977 W CN 2020071977W WO 2021022792 A1 WO2021022792 A1 WO 2021022792A1
Authority
WO
WIPO (PCT)
Prior art keywords
access request
authentication system
business service
request
access
Prior art date
Application number
PCT/CN2020/071977
Other languages
English (en)
French (fr)
Inventor
刘洋
王世纪
Original Assignee
创新先进技术有限公司
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 创新先进技术有限公司 filed Critical 创新先进技术有限公司
Priority to US16/805,025 priority Critical patent/US10728247B1/en
Publication of WO2021022792A1 publication Critical patent/WO2021022792A1/zh

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L1/00—Arrangements for detecting or preventing errors in the information received
    • H04L1/22—Arrangements for detecting or preventing errors in the information received using redundant apparatus to increase reliability
    • 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
    • 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/083—Network architectures or network communication protocols for network security for authentication of entities using passwords
    • 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/0876—Network architectures or network communication protocols for network security for authentication of entities based on the identity of the terminal or configuration, e.g. MAC address, hardware or software configuration or device fingerprint

Definitions

  • This manual relates to the field of computer technology, in particular to an authentication and business service method, device and equipment.
  • the system Before the user accesses the system, the system needs to verify the user's access authority to determine whether the user has the right to access the system. Specifically, the user sends an access request to the system, and the system determines whether the user has the access authority based on the received access request. If so, the system allows users to continue to access the system.
  • the authentication system is usually used to verify the access authority of the access request.
  • the authentication system confirms the user's access authority according to the login information provided by the user, such as the user name and password, and passes the user's login verification. After that, the authority information is generated, so that the system can authenticate the access authority of the access request according to the authority information in the subsequent access process.
  • the embodiments of this specification provide an authentication and business service method, device, and equipment.
  • the embodiment of this specification provides an authentication method, including:
  • the policy is determined according to the preset authentication system, and the target authentication system is determined from at least two authentication systems according to the identification information in the access request.
  • the system determination strategy includes the correspondence between the identification information and the authentication system, each of the at least two authentication systems being independently deployed as a microservice component in the microservice framework;
  • the access request is sent to the target authentication system, so that the target authentication system authenticates the access request.
  • the embodiment of this specification provides a business service method, including:
  • the policy is determined according to the preset authentication system, and the target authentication system is determined from at least two authentication systems according to the identification information in the business service request.
  • the authentication system determination strategy includes the corresponding relationship between the identification information and the authentication system, and the at least two authentication systems are each independently deployed as a microservice component in a microservice framework;
  • the business service request is sent to the corresponding business service system, so that the business service system provides business services according to the business service request .
  • the embodiment of this specification provides an authentication device, including:
  • the receiving unit receives the access request
  • the determining unit when it is determined that the access request does not have the access authority, determines the strategy according to the preset authentication system, and determines the target authentication system from at least two authentication systems according to the identification information in the access request, so
  • the authentication system determination strategy includes the corresponding relationship between the identification information and the authentication system, and the at least two authentication systems are each independently deployed as a microservice component in a microservice framework;
  • the sending unit sends the access request to the target authentication system, so that the target authentication system authenticates the access request.
  • the embodiment of this specification provides an authentication system, including: an authentication unit and an interception unit;
  • At least two authentication systems are deployed in the authentication unit based on a microservice framework, and each of the at least two authentication systems is independently deployed as a microservice component in the microservice framework;
  • the interception unit receives an access request
  • the interception unit determines that the access request does not have the access authority, it determines the policy according to the preset authentication system, and determines the target authentication from the at least two authentication systems according to the identification information in the access request.
  • the authentication system determining strategy includes the corresponding relationship between the identification information and the authentication system,
  • the interception unit sends the access request to the target authentication system, so that the target authentication system authenticates the access request.
  • the embodiment of this specification provides a business service device, including:
  • the receiving unit receives the business service request
  • the determining unit when it is determined that the business service request does not have access rights, determines the strategy according to the preset authentication system, and determines the target authentication system from at least two authentication systems according to the identification information in the business service request ,
  • the authentication system determination strategy includes the corresponding relationship between the identification information and the authentication system, and each of the at least two authentication systems is independently deployed as a microservice component in a microservice framework;
  • a sending unit which sends the business service request to the target authentication system, so that the target authentication system authenticates the business service request
  • the sending unit sends the business service request to the corresponding business service system, so that the business service system can be based on the business service Request business services.
  • the embodiment of the present specification provides an electronic device for authentication, including: at least one processor and a memory, the memory stores a program and is configured to execute the following steps by the at least one processor:
  • the policy is determined according to the preset authentication system, and the target authentication system is determined from at least two authentication systems according to the identification information in the access request.
  • the system determination strategy includes the correspondence between the identification information and the authentication system, each of the at least two authentication systems being independently deployed as a microservice component in the microservice framework;
  • the access request is sent to the target authentication system, so that the target authentication system authenticates the access request.
  • the embodiment of this specification provides an electronic device for business services, including: at least one processor and a memory, the memory stores a program and is configured to execute the following steps by the at least one processor:
  • the policy is determined according to the preset authentication system, and the target authentication system is determined from at least two authentication systems according to the identification information in the business service request.
  • the authentication system determination strategy includes the corresponding relationship between the identification information and the authentication system, and the at least two authentication systems are each independently deployed as a microservice component in a microservice framework;
  • the business service request is sent to the corresponding business service system, so that the business service system provides business services according to the business service request .
  • the above-mentioned at least one technical solution adopted in the embodiment of this specification can achieve the following beneficial effects: in the authentication method proposed in the embodiment of this specification, at least two authentication systems are independently deployed as microservice components in the microservice architecture, and the access request is not determined When you have access rights, determine the target authentication system based on the identification information in the access request according to the authentication system to determine the policy, and then send the access request to the target authentication system, so that the target authentication system can authenticate the access request.
  • the authentication method is compatible with multiple authentication systems while ensuring the smooth progress of the authentication process, avoiding unnecessary confusion, simple configuration and convenient operation.
  • Fig. 1 is a schematic diagram of the application of an authentication method proposed in an embodiment of the specification.
  • Fig. 2 is a flowchart of an authentication method provided by an embodiment of the specification.
  • FIGS 3a and 3b are interaction flowcharts of the authentication method provided by the embodiments of this specification.
  • Fig. 4 is a flowchart of an authentication method provided by an embodiment of the specification.
  • Fig. 5 is a flowchart of a business service method provided by an embodiment of the specification.
  • FIG. 6 is a schematic structural diagram of a business service method provided by an embodiment of this specification.
  • Fig. 7 is a flowchart of a business service method proposed in an embodiment of this specification.
  • Fig. 8 is a schematic structural diagram of an authentication device provided by an embodiment of the specification.
  • Fig. 9 is a schematic structural diagram of an authentication system provided by an embodiment of the specification.
  • Fig. 10 is a schematic structural diagram of a business service device provided by an embodiment of the specification.
  • the traditional verification process after the system receives the user's access request, it directly sends the access request to the authentication system for authentication.
  • the traditional verification process only includes a single authentication system, that is, all Access requests can only be authenticated using one type of authentication system, and in actual use, in order to meet actual use requirements, different authentication systems need to be used for authentication for different access requests. Therefore, when more than one authentication system needs to be used in the verification process, the traditional verification process cannot meet the use requirements.
  • the application schematic diagram may be as shown in FIG. 1, including a server 10 and at least one client 20.
  • the client 20 accesses the server 10 and obtains services from the server 10.
  • the client 20 can obtain services from the server 10 by sending an access request to the server 10.
  • At least two authentication systems are provided in the server 10, and the authentication system authenticates the received access request to determine whether the access request has access authority.
  • the client terminal 20 may include a terminal device that needs to access the server 10, including but not limited to a computer, a tablet, a mobile phone, etc.; it may also include an application program that needs to access the server 10, and the application program may be carried on the terminal device.
  • the application can be a browser or the like.
  • the client 20 and the server 10 realize interaction through a data connection.
  • the overall idea of the authentication method proposed in the embodiment of this specification is that at least two authentication systems in the server 10 are independently deployed as microservice components in the microservice framework, because the microservice architecture is a kind of The software application is designed as a specific way of independently deployable service suites.
  • the software under the microservice architecture will be split into various services to achieve componentization, and the components are independent of each other. Therefore, through the aforementioned solutions
  • the deployment of at least two authentication systems enables each authentication system to be completely encapsulated in an independent component without modification, and to independently provide the original complete services of the authentication system without interference between each other , This deployment method is quick and simple, while ensuring the integrity of the authentication system's functions, so that the authentication system can run authentication services independently.
  • an access request containing identification information is received from the client 20; when it is determined that the access request does not have access rights, a predetermined authentication system determination strategy is determined according to the identification information from at least two authentication systems Target authentication system, the authentication system determination strategy includes the corresponding relationship between the identification information and the authentication system, so that access requests can be accurately allocated to the authentication system, and different access requests do not affect each other, avoiding occurrences in the processing process Confusion; then the access request is sent to the target authentication system, and the access request is authenticated through the target authentication system.
  • the access request can be accurately passed to the corresponding target authentication system
  • the independent operation of the authentication system access requests from different sources can be authenticated independently without affecting each other, which not only ensures the accuracy of authentication, but also improves the efficiency of authentication.
  • the authentication methods are independent of each other, the access request can be effectively allocated to the corresponding authentication system, independent authentication, therefore, the authentication process of different access requests does not interfere with each other in the authentication process Therefore, the authentication method provided in the embodiment of the present specification can be compatible with multiple authentication systems while ensuring smooth authentication.
  • Fig. 2 is a flowchart of an authentication method provided by an embodiment of the specification.
  • the authentication method in the embodiment of this specification includes the following steps:
  • Step S201 Receive an access request.
  • the access request is a request sent when the client accesses the server.
  • the access request may be triggered by the client according to the user's operation on the client, or automatically triggered according to the preset business logic of the client.
  • the embodiment of the application does not specifically limit the triggering factor for generating the access request. For example, if the user clicks a function button on the client, an access request is generated according to the business function corresponding to the function button.
  • Step S203 When it is determined that the access request does not have the access authority, the predetermined authentication system determines the strategy, and the target authentication system is determined from at least two authentication systems according to the identification information in the access request.
  • At least two authentication systems are independently deployed as microservice components in the microservice framework.
  • it can be a complete authentication system as a microservice component that is independently deployed in the microservice architecture to independently provide authentication services, and the authentication systems do not affect or interfere with each other.
  • This deployment method Not only can the authentication system be used directly without modification, the original functions of the authentication system are completely retained, and multiple authentication systems can be deployed in the microservice architecture according to actual needs, which has good scalability and deployment Convenient and simple to operate.
  • the commonly used authentication methods can include HTTP Basic Authentication, session-cookie, Token and OAuth (Open Authorization), etc.
  • the authentication system can adopt different authentication methods for different access requests, for example, for PC
  • the client can use the session-cookie authentication method
  • the mobile client can use the Token authentication method, etc.
  • At least two authentication systems in the embodiment of this specification can authenticate access requests from different types of clients
  • one authentication system uses session-cookie authentication for PC client access
  • Token authentication for mobile client access requests It can also be used to authenticate different access requests from the same type of client.
  • both authentication systems use session-cookie methods for PC client access requests Perform authentication.
  • the two authentication systems may respectively perform authentication for access requests for obtaining different services, or perform authentication for access requests from different types of PC clients.
  • determining whether the access request has the access authority can be performed by authenticating the authority information in the access request. If the authority information is authenticated, the access request has the access authority. If the authority information is not If the authentication is passed, the access request does not have access authority.
  • the authority information includes authority information generated by the target authentication system when an access request containing login information is authenticated.
  • the access request containing login information is an access request sent before the sender of the access request sends the access request, and the client receives After the authorization information generated by the target authentication system is stored, the authorization information can be set in the access request generated subsequently by the client to determine whether the subsequently generated access request has access authorization.
  • the identification information includes information for identifying the target authentication system. For example, when access requests from different access sources correspond to different authentication systems, the information that can identify the source of the access request may be used as the identification information; for example, different services When the types correspond to different authentication systems, the service type corresponding to the access request is used as the identification information as the identification information; for example, the identification information of the authentication system may be used as the identification information.
  • the identification information may include at least one of a uniform resource locator, a uniform resource identifier, and an authentication system interface parameter, for example, the identification information is a uniform resource locator Uniform Resource Locator (URL), when the authentication system A is used to authenticate the client using the external network and the authentication system B is used to authenticate the client of the internal network, the access sent by the client of the external network
  • the URL information in the request indicates that it wants to access the authentication system A
  • the URL information in the access request sent by the client of the internal network indicates that it wants to access the authentication system B.
  • the authentication system determines that the corresponding relationship between the identification information and the authentication system is pre-stored in the policy, and when the access request is received, the authentication system is used to determine the corresponding relationship in the policy according to the access request.
  • the identification information in determines the target authentication system corresponding to the access request.
  • the corresponding authentication system can be determined according to the corresponding relationship between the identification information and the authentication system, thereby ensuring that the access request can be obtained by the corresponding authentication system , To avoid unnecessary confusion in the authentication process and ensure the accuracy of the follow-up process.
  • Step S205 Send the access request to the target authentication system, so that the target authentication system authenticates the access request.
  • the authentication system includes a system for verifying access rights based on login information.
  • the authentication system can be a system that verifies access rights based on user names and passwords, or can identify users based on the authentication system's recognition A system for verifying access to legally-identified information.
  • the access request further includes login information
  • the authentication of the access request by the target authentication system includes:
  • the target authentication system authenticates the access request according to the login information.
  • the target authentication system when the access request received by the target authentication system includes login information, the target authentication system directly obtains the login information from the access request, and determines whether the access request has access authority according to the login information.
  • the target authentication system when the access request received by the target authentication system does not contain login information, it will re-receive the access request containing the login information sent by the client corresponding to the access request, and then determine whether the access request has the login information based on the login information. access permission.
  • the authentication method provided in the embodiment of this specification further includes: sending a login information acquisition request to the client corresponding to the access request; receiving; An access request containing login information sent by the client corresponding to the access request.
  • the login information acquisition request may be presented on the client in the form of a login page, and the login information input by the user is obtained through the login page.
  • At least two authentication systems can use one or more login pages. For example, all authentication systems use the same login page, or each login system uses a corresponding login page.
  • the login page received by the client is the login page used by the authentication system corresponding to the client.
  • the method further includes:
  • first authority information is authority information sent by the target authentication system in response to the access request after the access request is authenticated
  • the first permission information may be used to authenticate the access request subsequently generated by the client. For example, when the client generates a new access request after the end of this authentication, the first permission information may be set to the new In the access request, it is convenient to determine the access authority of the new access request based on the first authority information.
  • the method further includes: establishing with the target authentication system Conversation
  • the receiving the first authority information includes:
  • the received access request is an http request
  • at least two authentication systems use the same authentication method for the access request, such as session control (session-cookie).
  • session control session-cookie
  • the first authority information sent by the system is in the form of session information.
  • the target authentication system corresponding to the http request establishes a session, so that it can independently communicate with the target authentication system based on the session
  • the first permission information sent by different authentication systems can be kept independent and not interfere with each other.
  • At least two authentication systems are authentication system C and authentication system D, because when the received access request is an http request, authentication system C and authentication system D both adopt session-cookie authentication for http requests.
  • Authentication method When the target authentication system determined according to the http request is authentication system C, a session is established with authentication system C, and the http request is sent to authentication system C based on the established session, and the authentication is received After that, the sessionID sent by the authentication system C in response to the access request is received; when the target authentication system is the authentication system D, the communication process is the same as using the authentication system C to authenticate the access request, and will not be repeated here.
  • Such a communication method enables independent information interaction with different authentication systems, avoids confusion caused when at least two authentication systems authenticate access requests with the same authentication method, and improves communication efficiency and accuracy.
  • the received first permission information can be sent to the client that generated the access request, so that the client can use it in the subsequent access process, for example,
  • the permission information is in the form of session information
  • the sessionID information corresponding to the session is sent to the client, so that a cookie containing the sessionID is set in a new access request generated by the client.
  • the authentication system independently authenticates the access request, and accesses relevant information correspondingly, without mutual influence, so that the user using the client will not perceive the difference between different authentication systems and improve the user experience.
  • the authentication method provided in the embodiments of this specification can be run in the form of an interceptor, and the interceptor may be set on the client side or on the server side.
  • the following takes the interceptor as the execution subject, based on two authentication systems, to authenticate access requests that do not have access rights as an example, to describe the authentication method provided in this specification.
  • FIGS 3a and 3b are interaction flowcharts of the authentication method provided by the embodiments of this specification.
  • the user performs operations on the client, for example, clicks on the page and enters a user name and password.
  • the client generates an access request containing the user name and password, and executes step S3.1 to send the access request to the interceptor.
  • Determine the strategy according to the authentication system According to the identification information in the access request, determine the target authentication system from the two authentication systems, establish a session with the target authentication system, and assign the access request to the target authentication system based on the established session.
  • the authentication system performs authentication according to the received access request.
  • step S3.3 When the target authentication system of the access request is the first authentication system, based on the session between the interceptor and the first authentication system, perform step S3.3 to access The request is sent to the first authentication system, and the first authentication system performs step S3.5 to verify the user name and password in the access request, and generates a session (such as sessionID) after passing the verification, and based on the difference between the interceptor and the first authentication system During the session, perform step S3.7 to send the sessionID to the interceptor in response to the access request, and the interceptor performs step S3.9 to send the received sessionID to the client, so that the client can write the sessionID into the client’s cookie accordingly in.
  • step S3.7 to send the sessionID to the interceptor in response to the access request
  • step S3.9 to send the received sessionID to the client, so that the client can write the sessionID into the client’s cookie accordingly in.
  • the client After the user performs an operation on the client, the client generates an access request containing the user name and password, and executes step S4.1 to send the access request to the interceptor.
  • the interceptor determines the policy according to the authentication system according to the access
  • the identification information in the request determines that the target authentication system of the access request is the second authentication system, based on the session between the interceptor and the second authentication system, perform step S4.3 to send the access request to the second authentication system
  • the second authentication system executes step S4.5 to verify the user name and password in the access request, generates a session after verification is passed, and based on the communication between the interceptor and the second authentication system, executes step S4.7 to send the sessionID
  • the interceptor executes step S4.9 to send the received sessionID to the client, so that the client can write the sessionID into the client’s cookie accordingly, so that after the authentication is passed, the client can Set the cookie containing the sessionID in the new access request and send it to the interceptor
  • the above-mentioned at least one technical solution adopted in the embodiment of this specification can achieve the following beneficial effects:
  • the authentication method proposed in the embodiment of this specification at least two authentication systems are independently deployed as microservice components in the microservice architecture, and are determined according to the access request.
  • the target authentication system is determined according to the authentication system's policy and the identification information in the access request, and then the access request is sent to the target authentication system, so that the target authentication system can authenticate the access request.
  • the authentication method provided by the embodiment of the present specification is compatible with multiple authentication systems while ensuring the smooth progress of the authentication process, avoiding unnecessary confusion, simple configuration and convenient operation.
  • Fig. 4 is a flowchart of an authentication method proposed in an embodiment of the specification.
  • the authentication method in the embodiment of this specification includes the following steps:
  • Step S501 Receive an access request.
  • the access request is a request sent by the client.
  • Step S503 It is judged whether the second permission information is included in the access request, if it is included, step S505 is executed, and if not included, step S507 is executed.
  • the second authority information includes authority information generated by the target authentication system when an access request containing login information is authenticated, and the access request containing login information is sent by the sender of the access request before sending the access request in step S501 Access request.
  • the access request received in step S501 is this access request.
  • the target authentication system verifies the received access request containing login information from the client. After generating the second permission information, the second permission information is returned to the client. Therefore, the client has already stored the second permission information before generating this access request, so the client is generating this access request.
  • the second permission information is set in the second permission information so that the target authentication system can determine whether the access request has the access permission according to the second permission information. Therefore, in step S503, the second permission information in the received access request can be used to determine the access request. Do you have access rights.
  • Step S303 can be to determine whether the access request has access permission by judging whether the access request contains a cookie. If it does not contain a cookie, it is determined that the access request does not have access permission. If it contains a cookie, it is necessary to further determine whether the access request has access permission. Of ok.
  • Step S505 Determine whether the access request has the access permission according to the second permission information, and if it does not have the access permission, execute step S507.
  • the second authority information is authenticated. If the authentication is passed, it is determined that the access request has access authority, and if the authentication is not passed, it is determined that the access request does not have access authority, that is, the access request needs to be authenticated.
  • the policy when the second authority information is authenticated, the policy may be determined according to the preset authentication system, and the target authentication system may be determined from at least two authentication systems according to the identification information in the access request received in step S501 , Send the access request to the target authentication system, so that the target authentication system authenticates the second authority information.
  • the target authentication system obtains the sessionID from the cookie contained in the access request, and queries the corresponding session according to the sessionID. If the correct session information can be queried, the authentication is passed. If the session cannot be queried or the wrong session is queried, The certification failed.
  • Step S507 Determine a target authentication system from at least two authentication systems according to the identification information in the access request.
  • Step S509 Send the access request to the target authentication system, so that the target authentication system authenticates the access request.
  • Step S5011 Receive first permission information.
  • the first authority information is authority information sent by the target authentication system in response to the access request after the access request is authenticated.
  • Step S5013 Send the first permission information to the sender of the access request, so that the sender sets the first permission information in a new access request.
  • the first permission information is used to determine whether the new access request has access permission.
  • the first permission information is sent to the client that generates the access request, so that the client sets the first permission information in the new access request.
  • Fig. 5 is a flowchart of a business service method provided by an embodiment of the specification.
  • the business service method in the embodiment of this specification includes the following steps:
  • Step S601 Receive a business service request.
  • Step S603 When it is determined that the business service request does not have the access right, the policy is determined according to the preset authentication system, and the target authentication system is determined from at least two authentication systems according to the identification information in the service request of the business. .
  • the authentication system determination strategy includes the corresponding relationship between the identification information and the authentication system, and each of the at least two authentication systems is independently deployed as a microservice component in a microservice framework.
  • Step S605 Send the business service request to the target authentication system, so that the target authentication system authenticates the business service request.
  • Step S607 When it is determined that the business service request is authenticated in the target authentication system, the business service request is sent to the corresponding business service system, so that the business service system can respond to the business service request Provide business services.
  • step S607 it may be determined that the authentication is passed by receiving the first authority information sent by the target authentication system when the authentication of the business service request is passed; or it may be that the target authentication system is not received within a predetermined period of time.
  • the authentication failure information is sent to determine that the authentication is passed; it can also be determined that the authentication is passed according to other pre-agreed methods.
  • step S603 when it is determined in step S603 that the business service request has access rights, the business service request is sent to the corresponding business service system, so that the business service system provides the business service according to the business service request.
  • the business service system can be independently deployed as a microservice component in the microservice framework; it can also be deployed using other deployment methods.
  • the business service system can be deployed in In the microservice framework, it is not necessary to deploy it in the microservice framework.
  • the following access request is an http request
  • the first permission information is in the form of session information as an example to describe the business service method proposed in the embodiment of this specification.
  • Fig. 6 is a schematic diagram of an architecture for providing a business service using a business service method provided by an embodiment of this specification, wherein the business service method is set in an interceptor.
  • the user performs an operation on the browser, and the browser sends the business service request corresponding to the user operation to the interceptor.
  • the interceptor determines that the received business service request has In the case of access authority, the business service request is sent to the corresponding service system, and when the interceptor determines that the received business service request does not have the access authority, the business service request is sent to at least two authentication systems for authentication. At least two authentication systems are independently deployed as microservice components in the microservice framework.
  • Fig. 7 is a flowchart of a business service method proposed in an embodiment of this specification.
  • a browser generates an http request to obtain a business service example from a server, and an interceptor set on the server is used as the execution subject.
  • the business service method in the embodiment of this specification includes the following steps:
  • Step S701 The interceptor receives a business service request from the browser.
  • the browser when it needs to access the business service system, it first sends the generated http request to the interceptor.
  • step S703 the interceptor judges whether the HTTP request contains a cookie, if it contains a cookie, execute step S705, if it does not contain it, execute step S707.
  • step S705 it is determined whether the http request has access authority according to the cookie, if it does not have the access authority, step S707 is executed, and if the access authority is granted, step S7013 is executed.
  • the interceptor determines the target authentication system that authenticates the cookie according to the URL information in the http request, and sends the http request to the target authentication system for authentication based on the session established between the interceptor and the target authentication system. According to the authentication result of the target authentication system on the cookie, it is determined whether the http request has the access authority.
  • the two authentication systems are independently deployed as micro-service components in the micro-service framework.
  • Step S707 Use the URL information in the http request to determine the target authentication system from the two authentication systems.
  • the interceptor determines the target authentication system according to the URL information in the http request.
  • step S705 and step S707 may be processed by setting different processing modules in one interceptor, or may be processed by setting two different interceptors to process separately.
  • the two authentication systems respectively verify login information from external systems and service requests from external systems.
  • Step S709 Send the http request to the target authentication system, so that the target authentication system can authenticate the http request.
  • the interceptor sends the http request to the target authentication system based on the session established between the interceptor and the target authentication system.
  • the target authentication system After the target authentication system receives the http request from the interceptor, if the http request contains the user name and password, the target authentication system directly authenticates according to the user name and password in the received http request; if the http request does not contain the user name and password When the password is used, the interceptor retrieves the http request containing the user name and password from the corresponding browser.
  • the target authentication system generates a session correspondingly, wherein the session information is stored in the server.
  • Step S7011 Receive the authentication result sent by the target authentication system, and if the authentication result is that the authentication is passed, step S7013 is executed.
  • the interceptor receives the sessionID sent by the target authentication system in response to the http request based on the session established between the interceptor and the target authentication system, and sends the sessionID to the browser.
  • Step 7013 Send the http request to the corresponding business service system.
  • the interceptor sends the http request to the corresponding business service system, so that the business service system executes subsequent business logic according to the http request.
  • the embodiments of this specification also provide devices, electronic equipment, and non-volatile computer storage media corresponding to the authentication method.
  • Fig. 8 is a schematic structural diagram of an authentication device provided by an embodiment of the specification.
  • an authentication device provided by an embodiment of this specification may include:
  • the receiving unit 801 receives an access request
  • the determining unit 803 when it is determined that the access request does not have the access authority, determines the policy according to the preset authentication system, and determines the target authentication system from at least two authentication systems according to the identification information in the access request,
  • the authentication system determination strategy includes the corresponding relationship between the identification information and the authentication system, and each of the at least two authentication systems is independently deployed as a microservice component in a microservice framework;
  • the sending unit 805 sends the access request to the target authentication system, so that the target authentication system authenticates the access request.
  • the identification information includes at least one of a uniform resource locator, a uniform resource identifier, and an authentication system interface parameter.
  • the access request further includes login information
  • the authentication of the access request by the target authentication system includes:
  • the target authentication system authenticates the access request according to the login information.
  • the device further includes: a receiving unit,
  • the receiving unit receives first authority information, where the first authority information is authority information sent by the target authentication system in response to the access request after the access request is authenticated;
  • the sending unit sends the first permission information to the sender of the access request, so that the sender sets the first permission information in a new access request.
  • the access request is an http request
  • the device also includes: an establishment unit
  • the receiving the first authority information includes:
  • the step of determining that the access request does not have access authority includes:
  • the determining unit determines whether the access request includes second authority information, the second authority information includes authority information generated by the target authentication system when the access request including login information is authenticated, and the access request includes login information.
  • the access request for information is an access request sent before the sender of the access request sends the access request;
  • the determining unit determines that the access request does not have the access authority according to the second authority information.
  • the determining unit determines whether the access request has the access permission.
  • Fig. 9 is a schematic structural diagram of an authentication system provided by an embodiment of the specification.
  • an authentication system may include: an authentication unit 901 and an interception unit 903;
  • At least two authentication systems are deployed in the authentication unit 901 based on a microservice framework, and the at least two authentication systems are each independently deployed as a microservice component in the microservice framework;
  • the interception unit 903 receives the access request
  • the intercepting unit 903 determines the policy according to the preset authentication system, and determines the target authentication from the at least two authentication systems according to the identification information in the access request.
  • An authentication system where the authentication system determination strategy includes the correspondence between the identification information and the authentication system;
  • the interception unit 903 sends the access request to the target authentication system, so that the target authentication system authenticates the access request.
  • an electronic device for authentication which includes at least one processor and a memory, the memory stores a program and is configured to execute the following steps by the at least one processor:
  • the policy is determined according to the preset authentication system, and the target authentication system is determined from at least two authentication systems according to the identification information in the access request.
  • the system determination strategy includes the correspondence between the identification information and the authentication system, each of the at least two authentication systems being independently deployed as a microservice component in the microservice framework;
  • the access request is sent to the target authentication system, so that the target authentication system authenticates the access request.
  • the embodiments of this specification also provide a non-volatile computer storage medium for authentication, including a program used in combination with an electronic device.
  • the program can be executed by a processor to complete the following steps:
  • the policy is determined according to the preset authentication system, and the target authentication system is determined from at least two authentication systems according to the identification information in the access request.
  • the system determination strategy includes the correspondence between the identification information and the authentication system, each of the at least two authentication systems being independently deployed as a microservice component in the microservice framework;
  • the access request is sent to the target authentication system, so that the target authentication system authenticates the access request.
  • the embodiments of this specification also provide devices, electronic equipment, and non-volatile computer storage media corresponding to the business service method.
  • Fig. 10 is a schematic structural diagram of a business service device provided by an embodiment of the specification.
  • a business service apparatus provided by an embodiment of this specification may include:
  • the receiving unit 1001 receives a business service request
  • the determining unit 1003 when it is determined that the business service request does not have access rights, determines the strategy according to the preset authentication system, and determines the target authentication system from at least two authentication systems according to the identification information in the business service request System, the authentication system determination strategy includes the correspondence between identification information and the authentication system, and each of the at least two authentication systems is independently deployed as a microservice component in a microservice framework;
  • the sending unit 1005 sends the business service request to the target authentication system, so that the target authentication system authenticates the business service request;
  • the sending unit 1005 sends the business service request to the corresponding business service system, so that the business service system is Service requests provide business services.
  • the sending unit sends the business service request to a corresponding business service system, so that the business service system provides business services according to the business service request .
  • the embodiments of the present specification also provide an electronic device for providing services, including at least one processor and a memory, the memory stores a program and is configured to execute the following steps by the at least one processor:
  • the policy is determined according to the preset authentication system, and the target authentication system is determined from at least two authentication systems according to the identification information in the business service request.
  • the authentication system determination strategy includes the corresponding relationship between the identification information and the authentication system, and the at least two authentication systems are each independently deployed as a microservice component in a microservice framework;
  • the business service request is sent to the corresponding business service system, so that the business service system provides business services according to the business service request .
  • the embodiments of this specification also provide a non-volatile computer storage medium for business services, including a program used in combination with an electronic device, and the program can be executed by a processor to complete the following steps:
  • the policy is determined according to the preset authentication system, and the target authentication system is determined from at least two authentication systems according to the identification information in the business service request.
  • the authentication system determination strategy includes the corresponding relationship between the identification information and the authentication system, and the at least two authentication systems are each independently deployed as a microservice component in a microservice framework;
  • the business service request is sent to the corresponding business service system, so that the business service system provides business services according to the business service request .
  • the apparatus, equipment, non-volatile computer storage medium and method provided in the embodiments of this specification correspond to each other. Therefore, the apparatus, equipment, and non-volatile computer storage medium also have beneficial technical effects similar to the corresponding method.
  • the beneficial technical effects of the method are described in detail, therefore, the beneficial technical effects of the corresponding device, equipment, and non-volatile computer storage medium are not repeated here.
  • a programmable logic device Programmable Logic Device, PLD
  • FPGA Field Programmable Gate Array
  • HDL Hardware Description Language
  • ABEL Advanced Boolean Expression Language
  • AHDL Altera Hardware Description Language
  • HDCal JHDL
  • Lava Lava
  • Lola MyHDL
  • PALASM RHDL
  • VHDL Very-High-Speed Integrated Circuit Hardware Description Language
  • Verilog Verilog
  • the controller can be implemented in any suitable manner.
  • the controller can take the form of, for example, a microprocessor or a processor and a computer-readable medium storing computer-readable program codes (such as software or firmware) executable by the (micro)processor. , Logic gates, switches, application specific integrated circuits (ASICs), programmable logic controllers and embedded microcontrollers.
  • controllers include but are not limited to the following microcontrollers: ARC 625D, Atmel AT91SAM, Microchip PIC18F26K20 and Silicon Labs C8051F320, the memory controller can also be implemented as a part of the memory control logic.
  • controller in addition to implementing the controller in a purely computer-readable program code manner, it is entirely possible to program the method steps to make the controller use logic gates, switches, application specific integrated circuits, programmable logic controllers and embedded The same function can be realized in the form of a microcontroller, etc. Therefore, such a controller can be regarded as a hardware component, and the devices included in it for implementing various functions can also be regarded as a structure within the hardware component. Or even, the device for realizing various functions can be regarded as both a software module for realizing the method and a structure within a hardware component.
  • a typical implementation device is a computer.
  • the computer may be, for example, a personal computer, a laptop computer, a cell phone, a camera phone, a smart phone, a personal digital assistant, a media player, a navigation device, an email device, a game console, a tablet computer, a wearable device, or Any combination of these devices.
  • the embodiments of the present invention may be provided as methods, systems, or computer program products. Therefore, the present invention may adopt the form of a complete hardware embodiment, a complete software embodiment, or an embodiment combining software and hardware. Moreover, the present invention may adopt the form of a computer program product implemented on one or more computer-usable storage media (including but not limited to disk storage, CD-ROM, optical storage, etc.) containing computer-usable program codes.
  • a computer-usable storage media including but not limited to disk storage, CD-ROM, optical storage, etc.
  • These computer program instructions can also be stored in a computer-readable memory that can guide a computer or other programmable data processing equipment to work in a specific manner, so that the instructions stored in the computer-readable memory produce an article of manufacture including the instruction device.
  • the device implements the functions specified in one process or multiple processes in the flowchart and/or one block or multiple blocks in the block diagram.
  • These computer program instructions can also be loaded on a computer or other programmable data processing equipment, so that a series of operation steps are executed on the computer or other programmable equipment to produce computer-implemented processing, so as to execute on the computer or other programmable equipment.
  • the instructions provide steps for implementing functions specified in a flow or multiple flows in the flowchart and/or a block or multiple blocks in the block diagram.
  • the computing device includes one or more processors (CPU), input/output interfaces, network interfaces, and memory.
  • processors CPU
  • input/output interfaces network interfaces
  • memory volatile and non-volatile memory
  • the memory may include non-permanent memory in computer readable media, random access memory (RAM) and/or non-volatile memory, such as read-only memory (ROM) or flash memory (flash RAM). Memory is an example of computer readable media.
  • RAM random access memory
  • ROM read-only memory
  • flash RAM flash memory
  • Computer-readable media include permanent and non-permanent, removable and non-removable media, and information storage can be realized by any method or technology.
  • the information can be computer-readable instructions, data structures, program modules, or other data.
  • Examples of computer storage media include, but are not limited to, phase change memory (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), other types of random access memory (RAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory or other memory technology, CD-ROM, digital versatile disc (DVD) or other optical storage, Magnetic cassettes, magnetic tape magnetic disk storage or other magnetic storage devices or any other non-transmission media can be used to store information that can be accessed by computing devices. According to the definition in this article, computer-readable media does not include transitory media, such as modulated data signals and carrier waves.
  • program modules include routines, programs, objects, components, data structures, etc. that perform specific tasks or implement specific abstract data types.
  • This application can also be practiced in distributed computing environments. In these distributed computing environments, remote processing devices connected through a communication network perform tasks.
  • program modules can be located in local and remote computer storage media including storage devices.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computer Hardware Design (AREA)
  • Computer Security & Cryptography (AREA)
  • Computing Systems (AREA)
  • General Engineering & Computer Science (AREA)
  • Power Engineering (AREA)
  • Storage Device Security (AREA)
  • Information Transfer Between Computers (AREA)

Abstract

本说明书实施例公开了一种鉴权与业务服务方法、装置以及设备。其中鉴权方案包括：接收访问请求；当确定所述访问请求未拥有访问权限时，按预设的鉴权***确定策略，根据所述访问请求中的标识信息，从至少两个鉴权***中确定目标鉴权***，所述鉴权***确定策略包括标识信息与鉴权***之间的对应关系，所述至少两个鉴权***各自作为微服务组件独立部署于微服务框架中；将所述访问请求发送至所述目标鉴权***，以使所述目标鉴权***对所述访问请求进行鉴权。

Description

一种鉴权与业务服务方法、装置以及设备 技术领域
本说明书涉及计算机技术领域，尤其涉及一种鉴权与业务服务方法、装置及设备。
背景技术
在用户访问***前，***需要对用户的访问权限进行验证，以确定该用户是否具有访问***的权利，具体地，用户向***发送访问请求，***根据接收到的访问请求判断是否具有访问权限，若有则***允许用户能够继续访问***。
在传统的验证过程中，通常使用鉴权***对访问请求的访问权限进行验证，鉴权***根据用户提供的登录信息，例如用户名和密码，来确认用户的访问权限，并在用户的登录验证通过后，生成权限信息，使得后续访问过程中***可根据权限信息对访问请求的访问权限进行认证。
发明内容
有鉴于此，本说明书实施例提供了一种鉴权与业务服务方法、装置以及设备。
本说明书实施例采用下述技术方案：
本说明书实施例提供一种鉴权方法，包括：
接收访问请求；
当确定所述访问请求未拥有访问权限时，按预设的鉴权***确定策略，根据所述访问请求中的标识信息，从至少两个鉴权***中确定目标鉴权***，所述鉴权***确定策略包括标识信息与鉴权***之间的对应关系，所述至少两个鉴权***各自作为微服务组件独立部署于微服务框架中；
将所述访问请求发送至所述目标鉴权***，以使所述目标鉴权***对所述访问请求进行鉴权。
本说明书实施例提供一种业务服务方法，包括：
接收业务服务请求；
当确定所述业务服务请求未拥有访问权限时，按预设的鉴权***确定策略，根据所 述业务服务请求中的标识信息，从至少两个鉴权***中确定目标鉴权***，所述鉴权***确定策略包括标识信息与鉴权***之间的对应关系，所述至少两个鉴权***各自作为微服务组件独立部署于微服务框架中；
将所述业务服务请求发送至所述目标鉴权***，以使所述目标鉴权***对所述业务服务请求进行鉴权；
当确定所述业务服务请求在所述目标鉴权***中鉴权通过时，将所述业务服务请求发送至对应的业务服务***，以使所述业务服务***根据所述业务服务请求提供业务服务。
本说明书实施例提供一种鉴权装置，包括：
接收单元，接收访问请求；
确定单元，当确定所述访问请求未拥有访问权限时，按预设的鉴权***确定策略，根据所述访问请求中的标识信息，从至少两个鉴权***中确定目标鉴权***，所述鉴权***确定策略包括标识信息与鉴权***之间的对应关系，所述至少两个鉴权***各自作为微服务组件独立部署于微服务框架中；
发送单元，将所述访问请求发送至所述目标鉴权***，以使所述目标鉴权***对所述访问请求进行鉴权。
本说明书实施例提供一种鉴权***，包括：鉴权单元和拦截单元；
所述鉴权单元中基于微服务框架部署有至少两个鉴权***，所述至少两个鉴权***各自作为微服务组件独立部署于所述微服务框架中；
所述拦截单元接收访问请求；
当所述拦截单元确定所述访问请求未拥有访问权限时，按预设的鉴权***确定策略，根据所述访问请求中的标识信息，从所述至少两个鉴权***中确定目标鉴权***，所述鉴权***确定策略包括标识信息与鉴权***之间的对应关系，
所述拦截单元将所述访问请求发送至所述目标鉴权***，以使所述目标鉴权***对所述访问请求进行鉴权。
本说明书实施例提供一种业务服务装置，包括：
接收单元，接收业务服务请求；
确定单元，当确定所述业务服务请求未拥有访问权限时，按预设的鉴权***确定策略，根据所述业务服务请求中的标识信息，从至少两个鉴权***中确定目标鉴权***，所述鉴权***确定策略包括标识信息与鉴权***之间的对应关系，所述至少两个鉴权***各自作为微服务组件独立部署于微服务框架中；
发送单元，将所述业务服务请求发送至所述目标鉴权***，以使所述目标鉴权***对所述业务服务请求进行鉴权；
当确定所述业务服务请求在所述目标鉴权***中鉴权通过时，所述发送单元将所述业务服务请求发送至对应的业务服务***，以使所述业务服务***根据所述业务服务请求提供业务服务。
本说明书实施例提供一种用于鉴权的电子设备，包括：至少一个处理器及存储器，所述存储器存储有程序，并且被配置成由至少一个处理器执行以下步骤：
接收访问请求；
当确定所述访问请求未拥有访问权限时，按预设的鉴权***确定策略，根据所述访问请求中的标识信息，从至少两个鉴权***中确定目标鉴权***，所述鉴权***确定策略包括标识信息与鉴权***之间的对应关系，所述至少两个鉴权***各自作为微服务组件独立部署于微服务框架中；
将所述访问请求发送至所述目标鉴权***，以使所述目标鉴权***对所述访问请求进行鉴权。
本说明书实施例提供一种用于业务服务的电子设备，包括：至少一个处理器及存储器，所述存储器存储有程序，并且被配置成由至少一个处理器执行以下步骤：
接收业务服务请求；
当确定所述业务服务请求未拥有访问权限时，按预设的鉴权***确定策略，根据所述业务服务请求中的标识信息，从至少两个鉴权***中确定目标鉴权***，所述鉴权***确定策略包括标识信息与鉴权***之间的对应关系，所述至少两个鉴权***各自作为微服务组件独立部署于微服务框架中；
将所述业务服务请求发送至所述目标鉴权***，以使所述目标鉴权***对所述业务服务请求进行鉴权；
当确定所述业务服务请求在所述目标鉴权***中鉴权通过时，将所述业务服务请求 发送至对应的业务服务***，以使所述业务服务***根据所述业务服务请求提供业务服务。
本说明书实施例采用的上述至少一个技术方案能够达到以下有益效果：本说明书实施例提出的鉴权方法，至少两个鉴权***各自作为微服务组件独立部署于微服务架构，在确定访问请求未拥有访问权限时，按鉴权***确定策略根据访问请求中的标识信息确定目标鉴权***，再将访问请求发送至目标鉴权***，以使目标鉴权***对访问请求进行鉴权，从而让该鉴权方法在兼容多个鉴权***的同时保证鉴权过程的顺利进行，避免出现不必要的混乱，并且配置简单，操作方便。
附图说明
为了更清楚地说明本说明书实施例或现有技术中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本说明书中记载的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动性的前提下，还可以根据这些附图获得其他的附图。
图1为本说明书实施例提出的一种鉴权方法的应用示意图。
图2为本说明书实施例提供的一种鉴权方法的流程图。
图3a和图3b为本说明书实施例提供的鉴权方法的交互流程图。
图4为本说明书实施例提供的一种鉴权方法的流程图。
图5为本说明书实施例提供的一种业务服务方法的流程图。
图6为本说明书实施例提供的一种业务服务方法的架构示意图。
图7为本说明书实施例提出的一种业务服务方法的流程图。
图8为本说明书实施例提供的一种鉴权装置的结构示意图。
图9为本说明书实施例提供的一种鉴权***的结构示意图。
图10为本说明书实施例提供的一种业务服务装置的结构示意图。
具体实施方式
为了使本技术领域的人员更好地理解本说明书中的技术方案，下面将结合本说明书实施例中的附图，对本说明书实施例中的技术方案进行清楚、完整地描述，显然，所描 述的实施例仅仅是本申请一部分实施例，而不是全部的实施例。基于本说明书实施例，本领域普通技术人员在没有作出创造性劳动前提下所获得的所有其他实施例，都应当属于本申请保护的范围。
如前述分析，在传统的验证过程中，***接收到用户的访问请求后，直接将访问请求发送至鉴权***进行鉴权，然而传统的验证过程中只包含单一的鉴权***，即所有的访问请求都只能使用一种鉴权***进行鉴权，而实际使用过程中，为满足实际使用的需求，需要针对不同的访问请求使用不同的鉴权***进行鉴权。因此，当验证过程中需要使用到一个以上的鉴权***时，传统的验证过程就无法满足使用需求了。
基于此，本说明书实施例提出一种鉴权与业务服务方法、装置及设备，应用示意图可如图1所示，包括服务端10以及至少一个客户端20。
客户端20访问服务端10，从服务端10获取服务，例如，客户端20可以通过向服务端10发送访问请求，从而从服务端10获取服务。服务端10中设置有至少两个鉴权***，鉴权***对接收到的访问请求进行鉴权，以判定访问请求是否具有访问权限。
其中，客户端20可以包括需要访问服务端10的终端设备，包括但不限于计算机、平板电脑、手机等；也可以包括需要访问服务端10的应用程序，该应用程序可以搭载在终端设备上，例如应用程序可以是浏览器等。
客户端20与服务端10之间通过数据连接实现交互。
具体地，本说明书实施例提出的鉴权方法，其整体思路是，服务端10中的至少两个鉴权***，各自作为微服务组件独立部署于微服务框架中，由于微服务架构是一种将软件应用程序设计为可独立部署的服务套件的特定方式，在微服务架构下的软件会被拆分成各种不同的服务来实现组件化，组件之间相互独立，因此，通过前述方案来部署的至少两个鉴权***，能够让每个鉴权***无需进行改动，完整地被封装在一个独立组件中，并分别独立地提供鉴权***原有的完整服务，相互之间不产生干扰，这样的部署方式快捷简便，同时又保证了鉴权***功能的完整性，使得鉴权***能够独立运行鉴权服务。在进行验证时，接收来自客户端20的包含标识信息的访问请求；当确定访问请求未拥有访问权限时，按预设的鉴权***确定策略根据标识信息，从至少两个鉴权***中确定目标鉴权***，鉴权***确定策略包括标识信息与鉴权***之间的对应关系，使得访问请求能够准确地分配给鉴权***，不同的访问请求之间相互不影响，避免处理过程中出现混乱；再将访问请求发送至目标鉴权***，通过目标鉴权***对访问请求进行鉴权， 由于鉴权之前已经确定了目标鉴权***，使得访问请求能够准确地被对应的目标鉴权***进行鉴权，同时由于鉴权***的独立运行，使得不同来源的访问请求能够独立地被鉴权，互不影响，既保证了鉴权的准确性，又提高了鉴权效率。在上述鉴权过程中，由于鉴权***之间相互独立，访问请求能够被有效分配至对应的鉴权***，独立鉴权，因此，鉴权过程中不同的访问请求的鉴权过程相互不干扰，从而让本说明书实施例提供的鉴权方法能够在兼容多个鉴权***的同时保证鉴权的顺利进行。
以下结合附图，详细说明本申请各实施例提供的技术方案。
实施例1
图2为本说明书实施例提供的一种鉴权方法的流程图。
如图2所示，本说明书实施例中鉴权方法包括以下步骤：
步骤S201，接收访问请求。
其中，访问请求为客户端访问服务端时发送的请求。
在实际应用中，访问请求可以是客户端根据用户对客户端的操作触发生成，也可以根据客户端预设业务逻辑自动触发生成，本申请实施例对生成访问请求的触发因素并不做具体限定，例如，用户在客户端上点击功能按钮，则根据该功能按钮所对应的业务功能生成访问请求。
步骤S203，当确定所述访问请求未拥有访问权限时，按预设的鉴权***确定策略，根据所述访问请求中的标识信息，从至少两个鉴权***中确定目标鉴权***。
其中，至少两个鉴权***各自作为微服务组件独立部署于微服务框架中。
具体地，可以是一个完整的鉴权***作为一个微服务组件被独立部署于微服务架构中，独立地提供鉴权服务，鉴权***之间相互不产生影响，相互不干扰，这样的部署方式既能够直接使用鉴权***，无需进行修改，完整的保留了鉴权***的原有功能，又能够根据实际使用的需要在微服务架构中部署多个鉴权***，具有很好拓展性，部署方便，操作简单。
需要说明的是，常用的鉴权方式可包括HTTP Basic Authentication，session-cookie，Token以及OAuth(开放授权)等，鉴权***针对不同的访问请求可以采用不同的鉴权方式，例如，针对如PC客户端可以使用session-cookie的鉴权方式，针对移动客户端可以使用Token的鉴权方式等，本说明书实施例中的至少两个鉴权***可以是针对来自不同 种类客户端的访问请求进行鉴权，例如，当鉴权***为两个时，一个鉴权***针对PC客户端的访问，采用session-cookie的方式进行鉴权，另一个鉴权***针对移动客户端的访问请求，采用Token的方式进行鉴权；也可以是，针对来自相同种类客户端不同的访问请求进行鉴权，例如，当鉴权***为两个时，两个鉴权***均针对PC客户端的访问请求，采用session-cookie的方式进行鉴权，此时，两个鉴权***可以是分别针对获取不同服务的访问请求进行鉴权，或分别针对来自不同类别的PC客户端的访问请求进行鉴权。
还需要说明的是，本说明书实施例中，确定访问请求是否拥有访问权限可以通过对访问请求中的权限信息进行认证的方式进行，若权限信息通过认证则访问请求拥有访问权限，若权限信息未通过认证则访问请求未拥有访问权限。其中，权限信息包括目标鉴权***在包含登录信息的访问请求鉴权通过时生成的权限信息，该包含登录信息的访问请求为访问请求的发送方发送访问请求之前发送的访问请求，客户端接收到目标鉴权***生成的权限信息后进行存储，使得权限信息能够被设置于客户端后续生成的访问请求中，以用于确定后续生成的访问请求是否具有访问权限。
标识信息包括对目标鉴权***进行标识的信息，例如，不同访问来源的访问请求对应于不同的鉴权***时，可以是将能够标识访问请求来源的信息作为标识信息；又如，不同的服务种类对应于不同的鉴权***时，将访问请求所对应的服务种类作为标识信息作为标识信息；还如，可以是将鉴权***的识别信息作为标识信息。
在一种应用示例中，为了能够简单有效地设置标识信息，标识信息包括可以是统一资源定位符、统一资源标识符以及鉴权***接口参数中的至少一种，比如，标识信息为统一资源定位符(Uniform Resource Locator，URL)，当鉴权***A用于对使用外部网络客户端进行鉴权和鉴权***B用于对内部网络的客户端进行鉴权时，外部网络的客户端发送的访问请求中的URL信息表示其要访问的是鉴权***A，内部网络的客户端发送的访问请求中的URL信息表示其要访问的是鉴权***B。
进一步地，本说明书实施例中，鉴权***确定策略中预先存储有标识信息与鉴权***之间的对应关系，当接收到访问请求后，利用鉴权***确定策略中的对应关系根据访问请求中的标识信息确定与访问请求对应的目标鉴权***。
由于设置了鉴权***确定策略，使得一旦获取标识信息，就能根据标识信息与鉴权***之间的对应关系确定出对应的鉴权***，从而保证了访问请求能够被对应的鉴权***获取，避免了鉴权过程中出现不必要的混乱，保证了后续过程的准确性。
步骤S205，将所述访问请求发送至所述目标鉴权***，以使得所述目标鉴权***对所述访问请求进行鉴权。
本说明书实施例中，鉴权***包括用于根据登录信息验证访问权限的***，例如，鉴权***可以是根据用户名和密码验证访问权限的***，也可以是根据鉴权***承认的能够识别用户合法身份的信息验证访问权限的***。
在一种应用示例中，所述访问请求还包括登录信息；
所述目标鉴权***对所述访问请求进行鉴权包括：
所述目标鉴权***根据所述登录信息对所述访问请求进行鉴权。
具体地，当目标鉴权***接收到的访问请求中包含有登录信息时，目标鉴权***直接从访问请求中获取登录信息，根据登录信息判定访问请求是否具有访问权限。
需要说明的是，当目标鉴权***接收到的访问请求中不包含有登录信息时，重新接收与访问请求对应的客户端发送的包含登录信息的访问请求，进而根据登录信息判定访问请求是否具有访问权限。
需要说明的是，当目标鉴权***接收到的访问请求中不包含有登录信息时，本说明书实施例提供的鉴权方法还包括：向与访问请求对应的客户端发送登录信息获取请求；接收与访问请求对应的客户端发送的包含登录信息的访问请求。其中，登录信息获取请求可以是以登录页面的形式在客户端进行呈现，通过登录页面获取用户输入的登录信息。
还需要说明的是，至少两个鉴权***可以使用一个或多个登录页面，例如，所有的鉴权***均使用相同的登录页面，或每个登录***分别对应地使用一个登录页面。
当每个登录***分别对应地使用一个登录页面时，客户端接收到的登录页面为与该客户端对应的鉴权***使用的登录页面。
在一种应用示例中，所述方法还包括：
接收第一权限信息，所述第一权限信息为所述目标鉴权***在所述访问请求通过鉴权后，响应所述访问请求发送的权限信息；
向所述访问请求的发送方发送所述第一权限信息，以使所述发送方将所述第一权限信息设置于新的访问请求中。
其中，第一权限信息可以是用于对客户端后续生成的访问请求进行认证，例如，在本次鉴权结束后，客户端生成新的访问请求时，可以将第一权限信息设置于新的访问请 求中，以便于基于第一权限信息确定新的访问请求的访问权限。
在一种应用示例中，为了保证与鉴权***之间信息交互的高效性和准确性，避免发生混乱，在访问请求为http请求时，所述方法还包括：与所述目标鉴权***建立会话；
所述接收第一权限信息包括：
基于所述会话接收第一权限信息，以使所述目标鉴权***基于所述会话进行会话控制。
例如，当接收到的访问请求为http请求时，至少两个鉴权系对访问请求均使用相同的鉴权方式，如会话控制(session-cookie)的方式，此时，由于至少两个鉴权***发送的第一权限信息均为session信息的形式，为避免产生混乱，在接收到http请求后，与http请求对应的目标鉴权***建立会话，从而能够基于该会话独立地与目标鉴权***进行通信，如基于该会话接收第一权限信息，进而使得不同的鉴权***发送的第一权限信息能够保持独立，互不干扰。
比如，至少两个鉴权***为鉴权***C和鉴权***D，由于当接收到的访问请求为http请求时，鉴权***C和鉴权***D对于http请求均采取session-cookie的鉴权方式，当根据http请求确定出的目标鉴权***为鉴权***C时，与鉴权***C建立会话，基于建立好的会话将http请求发送至鉴权***C，并在鉴权通过接收后，接收鉴权***C响应访问请求发送的sessionID；当目标鉴权***为鉴权***D时，通信过程与使用鉴权***C对访问请求进行鉴权相同，此处不再一一赘述。
这样的通信方式使得能够与不同鉴权***独立地进行信息交互，避免了至少两个鉴权***对访问请求进行鉴权的鉴权方式相同时导致的混乱，提高了通信的效率和准确性。
进一步地，向访问请求的发送方发送第一权限信息，可以将接收到的第一权限信息发送至生成访问请求的客户端，使得客户端能够在后续的访问过程中使用，例如，当第一权限信息为session信息的形式时，将session对应的sessionID信息发送至客户端，以使得客户端生成的新的访问请求中设置有包含sessionID的cookie。
鉴权***独立地对访问请求进行鉴权，并对应地访问相关信息，相互无影响，使得使用客户端的用户不会感知不同鉴权***的差异，提高用户的使用体验。
需要说明的是，本说明书实施例中提供的鉴权方法可通过***的形式运行，该***可以是设置在客户端也可以是设置在服务端。
以下以***为执行主体，基于两个鉴权***，对不具有访问权限的访问请求进行鉴权为例，对本说明书提供的鉴权方法进行说明。
图3a和图3b为本说明书实施例提供的鉴权方法的交互流程图。
如图3a所示，用户在客户端执行操作，例如，点击页面和输入用户名和密码，客户端生成包含用户名和密码的访问请求，并执行步骤S3.1将访问请求发送至***，***按鉴权***确定策略根据访问请求中的标识信息，从两个鉴权***中确定目标鉴权***，与目标鉴权***建立会话，基于建立的会话将访问请求分配至目标鉴权***，目标鉴权***根据接收到的访问请求进行鉴权，当访问请求的目标鉴权***为第一鉴权***时，基于***与第一鉴权***之间的会话，执行步骤S3.3将访问请求发送至第一鉴权***，第一鉴权***执行步骤S3.5校验访问请求中的用户名和密码，验证通过后生成session(比如sessionID)，并基于***与第一鉴权***之间的会话，执行步骤S3.7将sessionID发送至***以响应访问请求，***执行步骤S3.9将接收到的sessionID发送给客户端，以便于客户端将sessionID对应地写入客户端的cookie中。
如图3b所示，用户在客户端执行操作后，客户端生成包含用户名和密码的访问请求，并执行步骤S4.1将访问请求发送至***，当***按鉴权***确定策略根据访问请求中的标识信息确定访问请求的目标鉴权***为第二鉴权***时，基于***与第二鉴权***之间的会话，执行步骤S4.3将访问请求发送至第二鉴权***，第二鉴权***执行步骤S4.5校验访问请求中的用户名和密码，验证通过后生成session，并基于***与第二鉴权***之间的通信，执行步骤S4.7将sessionID发送至***以响应访问请求，***执行步骤S4.9将接收到的sessionID发送给客户端，以便于客户端将sessionID对应地写入客户端的cookie中，这样在鉴权通过后，客户端可以将包含sessionID的cookie设置于新的访问请求中发送至***。
本说明书实施例采用的上述至少一个技术方案能够达到以下有益效果：本说明书实施例提出的鉴权方法，至少两个鉴权***各自作为微服务组件独立部署于微服务架构，在根据确定访问请求未拥有访问权限时，按鉴权***确定策略根据访问请求中的标识信息确定目标鉴权***，再将访问请求发送至目标鉴权***，使目标鉴权***对访问请求进行鉴权，从而让本说明书实施例提供的鉴权方法在兼容多个鉴权***的同时保证鉴权过程的顺利进行，避免出现不必要的混乱，并且配置简单，操作方便。
实施例2
图4为本说明书实施例提出的一种鉴权方法的流程图。
如图4所示，本说明书实施例中鉴权方法包括以下步骤：
步骤S501，接收访问请求。
其中，访问请求为客户端发送的请求。
步骤S503，判断所述访问请求中是否包含第二权限信息，若包含则执行步骤S505，若不包含则执行步骤S507。
其中，第二权限信息包括目标鉴权***在包含登录信息的访问请求鉴权通过时生成的权限信息，包含登录信息的访问请求为访问请求的发送方在发送步骤S501中的访问请求之前发送的访问请求。
例如，步骤S501中的接收到的访问请求为本次访问请求，客户端在生成本次访问请求之前，目标鉴权***对接收到的来自客户端的包含登录信息的访问请求进行验证，在验证通过后生成第二权限信息，然后该第二权限信息被返回至客户端，因此，在生成本次访问请求之间，客户端已经存储有第二权限信息，故客户端在生成的本次访问请求中设置第二权限信息，以使得目标鉴权***能够根据第二权限信息确定本次访问请求是否具有访问权限，所以，步骤S503中可以利用接收到的访问请求中的第二权限信息确定访问请求是否具有访问权限。
以下，以第二权限信息为session信息的形式为例进行说明：若客户端在先发送的包含登录信息的访问请求在目标鉴权***的鉴权通过后，客户端会接收到目标鉴权***发生的sessionID，即客户端在进行本次访问前，已预先存储有sessionID，故生成的本次访问请求中可以包含设置有sessionID的cookie，从而使得步骤S301中接收到访问请求中包含cookie，因此，步骤S303可以是通过判断访问请求中是否包含cookie，来判定访问请求是否拥有访问权限，若不包含cookie则确定访问请求未拥有访问权限，若包含cookie则需要对访问请求是否拥有访问权限进行进一步的确定。
步骤S505，根据所述第二权限信息确定所述访问请求是否拥有访问权限，若未拥有访问权限则执行步骤S507。
具体地，对第二权限信息进行认证，若认证通过则确定访问请求具有访问权限，若认证未通过则确定访问请求不具有访问权限，即访问请求需要进行鉴权。
例如，对第二权限信息进行认证时，可以是按预设的鉴权***确定策略，根据 步骤S501中接收到的访问请求中的标识信息，从至少两个鉴权***中确定目标鉴权***，将访问请求发送至目标鉴权***，以使目标鉴权***对第二权限信息进行认证。进行认证时，目标鉴权***从访问请求所包含的cookie中获取sessionID，根据sessionID查询对应的session，若能够查询到正确的session信息则认证通过，若无法查询到session或查询到错误的session则认证未通过。
步骤S507，根据所述访问请求中的标识信息，从至少两个鉴权***中确定目标鉴权***。
步骤S509，将所述访问请求发送至所述目标鉴权***，以使所述目标鉴权***对所述访问请求进行鉴权。
步骤S5011，接收第一权限信息。
其中，第一权限信息为所述目标鉴权***在所述访问请求通过鉴权后，响应所述访问请求发送的权限信息。
步骤S5013，向所述访问请求的发送方发送所述第一权限信息，以使所述发送方将所述第一权限信息设置于新的访问请求中。
其中，所述第一权限信息用于确定所述新的访问请求是否拥有访问权限。
具体地，将第一权限信息发送给生成访问请求的客户端，以使客户端将第一权限信息设置于新的访问请求中。
实施例4
图5为本说明书实施例提供的一种业务服务方法的流程图。
如图5所示，本说明书实施例中的业务服务方法包括以下步骤：
步骤S601，接收业务服务请求。
步骤S603，当确定所述业务服务请求未拥有访问权限时，按预设的鉴权***确定策略，根据业务所述服务请求中的标识信息，从至少两个鉴权***中确定目标鉴权***。
所述鉴权***确定策略包括标识信息与鉴权***之间的对应关系，所述至少两个鉴权***各自作为微服务组件独立部署于微服务框架中。
步骤S605，将所述业务服务请求发送至所述目标鉴权***，以使所述目标鉴权 ***对所述业务服务请求进行鉴权。
步骤S607，当确定所述业务服务请求在所述目标鉴权***中鉴权通过时，将所述业务服务请求发送至对应的业务服务***，以使所述业务服务***根据所述业务服务请求提供业务服务。
具体地，步骤S607中可以是通过接收到目标鉴权***对业务服务请求鉴权通过时发送的第一权限信息来确定鉴权通过；也可以是在预定时间段内未接收到目标鉴权***发送的鉴权失败信息来确定鉴权通过；还可以是根据其他预先约定好的方式来确定鉴权通过。
在一种应用示例中，当步骤S603中确定业务服务请求拥有访问权限时，将业务服务请求发送至对应的业务服务***，以使业务服务***根据业务服务请求提供业务服务。
还需要说明的是，本说明书实施例中，业务服务***可以是作为微服务组件独立部署于微服务框架中；也可以是采用其他的部署方式进行部署，此时，业务服务***可以是部署在微服务框架中，可以不部署在微服务框架中。
以下访问请求为http请求，第一权限信息为session信息的形式为例，对本说明书实施例提出的业务服务方法进行说明。
图6为利用本说明书实施例提供的一种业务服务方法提供业务服务的架构示意图，其中所述业务服务方法设置于***中。
如图6所示，本说明书提供的业务服务方法中，用户在浏览器上执行操作，浏览器将与用户操作对应的业务服务请求发送到***，当***确定接收到的业务服务请求拥有访问权限时，将业务服务请求发送至对应的服务***，当***确定接收到的业务服务请求未拥有访问权限时，将业务服务请求发送至少两个鉴权***进行鉴权。至少两个鉴权***各自作为微服务组件独立部署于微服务框架中。
图7为本说明书实施例提出的一种业务服务方法的流程图。
如图7所示，具体地，以浏览器生成http请求从服务器获取业务服务例，将设置在服务器的***作为执行主体，本说明书实施例中的业务服务方法包括以下步骤：
步骤S701，***接收到来自浏览器的业务服务请求。
具体地，浏览器需要访问业务服务***时，先将生成的http请求发送至***。
步骤S703，***判断http请求中是否包含cookie，若包含则执行步骤S705，若不包含则执行步骤S707。
步骤S705，根据cookie确定http请求是否拥有访问权限，若未拥有访问权限则执行步骤S707，若拥有访问权限则执行步骤S7013。
具体地，***根据http请求中的URL信息确定对cookie进行认证的目标鉴权***，基于***与目标鉴权***之间建立的会话，将http请求发送至目标鉴权***进行鉴权，根据目标鉴权***对cookie的认证结果确定http请求是否拥有访问权限。
其中，两个鉴权***为各种作为微服务组件独立部署于微服务框架中。
步骤S707，利用http请求中的URL信息，从两个鉴权***中确定出目标鉴权***。
具体地，针对需要鉴权的http请求，***根据http请求中的URL信息确定目标鉴权***。
需要说明的是，步骤S705和步骤S707可以是通过在一个***设置不同处理模块进行处理，也可以是设置两个不同的***分别进行处理。
两个鉴权***分别针对来自外部***的登录信息和来自外部***的服务请求进行验证。
步骤S709，将http请求发送至目标鉴权***，以使目标鉴权***对http请求进行鉴权。
***基于***与目标鉴权***之间建立的会话，将http请求发送至目标鉴权***。
目标鉴权***接收到来自***的http请求后，若http请求中包含用户名和密码，目标鉴权***直接根据接收到的http请求中的用户名和密码进行验证；若http请求中不包含用户名和密码时，***从对应的浏览器重新获取包含用户名和密码的http请求。
进一步地，若验证通过，目标鉴权***对应地生成session，其中，session信息存储在服务器中。
步骤S7011，接收目标鉴权***发送的鉴权结果，若鉴权结果为鉴权通过则执行步骤S7013。
若鉴权通过，***基于***与目标鉴权***之间建立的会话，接收目标鉴权***响应http请求发送的sessionID，并将sessionID发送至浏览器。
步骤7013，将http请求发送至与对应的业务服务***。
具体地，在http请求拥有访问权限时，***将http请求发送至对应的业务服务***，以使业务服务***根据http请求执行后续业务逻辑。
实施例5
基于相同的发明构思，本说明书实施例还提供与鉴权方法对应的装置、电子设备以及非易失性计算机存储介质。
鉴于前述实施例中对方法已进行了详细说明，下面实施例中对方法对应的装置、电子设备以及非易失性计算机存储介质所涉及的相应内容将不再赘述。
图8为本说明书实施例提供的一种鉴权装置的结构示意图。
如图8所示，本说明书实施例提供的一种鉴权装置可以包括：
接收单元801，接收访问请求；
确定单元803，当确定所述访问请求未拥有访问权限时，按预设的鉴权***确定策略，根据所述访问请求中的标识信息，从至少两个鉴权***中确定目标鉴权***，所述鉴权***确定策略包括标识信息与鉴权***之间的对应关系，所述至少两个鉴权***各自作为微服务组件独立部署于微服务框架中；
发送单元805，将所述访问请求发送至所述目标鉴权***，以使所述目标鉴权***对所述访问请求进行鉴权。
可选地，所述标识信息包括统一资源定位符、统一资源标识符以及鉴权***接口参数中的至少一种。
可选地，所述访问请求还包括登录信息，
所述目标鉴权***对所述访问请求进行鉴权包括：
所述目标鉴权***根据所述登录信息对所述访问请求进行鉴权。
可选地，所述装置还包括：接收单元，
所述接收单元接收第一权限信息，所述第一权限信息为所述目标鉴权***在所述访问请求通过鉴权后，响应所述访问请求发送的权限信息；
所述发送单元向所述访问请求的发送方发送所述第一权限信息，以使所述发送方将所述第一权限信息设置于新的访问请求中。
可选地，当所述访问请求为http请求时，
所述装置还包括：建立单元
通过所述建立单元与所述目标鉴权***建立会话；
所述接收第一权限信息包括：
基于所述会话接收第一权限信息，以使所述目标鉴权***基于所述会话进行会话控制。
可选地，所述确定所述访问请求未拥有访问权限步骤包括：
所述确定单元判断所述访问请求中是否包含第二权限信息，所述第二权限信息包括所述目标鉴权***在包含登录信息的访问请求鉴权通过时生成的权限信息，所述包含登录信息的访问请求为所述访问请求的发送方发送所述访问请求之前发送的访问请求；
若所述访问请求未包含所述第二权限信息，则所述确定单元根据所述第二权限信息确定所述访问请求未拥有访问权限。
可选地，若所述访问请求包含所述第二权限信息，则所述确定单元确定所述访问请求是否拥有访问权限。
图9为本说明书实施例提供的一种鉴权***的结构示意图。
如图9所示，本说明书实施例提供的一种鉴权***可以包括：鉴权单元901和拦截单元903；
所述鉴权单元901中基于微服务框架部署有至少两个鉴权***，所述至少两个鉴权***各自作为微服务组件独立部署于所述微服务框架中；
所述拦截单元903接收访问请求；
当所述拦截单元903确定所述访问请求未拥有访问权限时，按预设的鉴权***确定策略，根据所述访问请求中的标识信息，从所述至少两个鉴权***中确定目标鉴权***，所述鉴权***确定策略包括标识信息与鉴权***之间的对应关系；
所述拦截单元903将所述访问请求发送至所述目标鉴权***，以使所述目标鉴 权***对所述访问请求进行鉴权。
基于同一发明构思，本说明书实施例还提供一种用于鉴权的电子设备，包括至少一个处理器及存储器，所述存储器存储有程序，并且被配置成由至少一个处理器执行以下步骤：
接收访问请求；
当确定所述访问请求未拥有访问权限时，按预设的鉴权***确定策略，根据所述访问请求中的标识信息，从至少两个鉴权***中确定目标鉴权***，所述鉴权***确定策略包括标识信息与鉴权***之间的对应关系，所述至少两个鉴权***各自作为微服务组件独立部署于微服务框架中；
将所述访问请求发送至所述目标鉴权***，以使所述目标鉴权***对所述访问请求进行鉴权。
其中，处理器的其他功能还可以参见上述实施例中记载的内容，这里不再一一赘述。
基于同一发明构思，本说明书实施例还提供一种用于鉴权的非易失性计算机存储介质，包括与电子设备结合使用的程序，程序可被处理器执行以完成以下步骤：
接收访问请求；
当确定所述访问请求未拥有访问权限时，按预设的鉴权***确定策略，根据所述访问请求中的标识信息，从至少两个鉴权***中确定目标鉴权***，所述鉴权***确定策略包括标识信息与鉴权***之间的对应关系，所述至少两个鉴权***各自作为微服务组件独立部署于微服务框架中；
将所述访问请求发送至所述目标鉴权***，以使所述目标鉴权***对所述访问请求进行鉴权。
实施例6
基于相同的发明构思，本说明书实施例还提供与业务服务方法对应的装置、电子设备以及非易失性计算机存储介质。
鉴于前述实施例中对方法已进行了详细说明，下面实施例中对方法对应的装置、电子设备以及非易失性计算机存储介质所涉及的相应内容将不再赘述。
图10为本说明书实施例提供的一种业务服务装置的结构示意图。
如图10所示，本说明书实施例提供的一种业务服务装置可以包括：
接收单元1001，接收业务服务请求；
确定单元1003，当确定所述业务服务请求未拥有访问权限时，按预设的鉴权***确定策略，根据所述业务服务请求中的标识信息，从至少两个鉴权***中确定目标鉴权***，所述鉴权***确定策略包括标识信息与鉴权***之间的对应关系，所述至少两个鉴权***各自作为微服务组件独立部署于微服务框架中；
发送单元1005，将所述业务服务请求发送至所述目标鉴权***，以使所述目标鉴权***对所述业务服务请求进行鉴权；
当确定所述业务服务请求在所述目标鉴权***中鉴权通过时，所述发送单元1005将所述业务服务请求发送至对应的业务服务***，以使所述业务服务***根据所述业务服务请求提供业务服务。
可选地，当确定所述业务服务请求拥有访问权限时，所述发送单元将所述业务服务请求发送至对应的业务服务***，以使所述业务服务***根据所述业务服务请求提供业务服务。
基于同一发明构思，本说明书实施例还提供一种用于提供服务的电子设备，包括至少一个处理器及存储器，所述存储器存储有程序，并且被配置成由至少一个处理器执行以下步骤：
接收业务服务请求；
当确定所述业务服务请求未拥有访问权限时，按预设的鉴权***确定策略，根据所述业务服务请求中的标识信息，从至少两个鉴权***中确定目标鉴权***，所述鉴权***确定策略包括标识信息与鉴权***之间的对应关系，所述至少两个鉴权***各自作为微服务组件独立部署于微服务框架中；
将所述业务服务请求发送至所述目标鉴权***，以使所述目标鉴权***对所述业务服务请求进行鉴权；
当确定所述业务服务请求在所述目标鉴权***中鉴权通过时，将所述业务服务请求发送至对应的业务服务***，以使所述业务服务***根据所述业务服务请求提供业务服务。
其中，处理器的其他功能还可以参见上述实施例中记载的内容，这里不再一一 赘述。
基于同一发明构思，本说明书实施例还提供一种用于业务服务的非易失性计算机存储介质，包括与电子设备结合使用的程序，程序可被处理器执行以完成以下步骤：
接收业务服务请求；
当确定所述业务服务请求未拥有访问权限时，按预设的鉴权***确定策略，根据所述业务服务请求中的标识信息，从至少两个鉴权***中确定目标鉴权***，所述鉴权***确定策略包括标识信息与鉴权***之间的对应关系，所述至少两个鉴权***各自作为微服务组件独立部署于微服务框架中；
将所述业务服务请求发送至所述目标鉴权***，以使所述目标鉴权***对所述业务服务请求进行鉴权；
当确定所述业务服务请求在所述目标鉴权***中鉴权通过时，将所述业务服务请求发送至对应的业务服务***，以使所述业务服务***根据所述业务服务请求提供业务服务。
上述对本说明书特定实施例进行了描述。其它实施例在所附权利要求书的范围内。在一些情况下，在权利要求书中记载的动作或步骤可以按照不同于实施例中的顺序来执行并且仍然可以实现期望的结果。另外，在附图中描绘的过程不一定要求示出的特定顺序或者连续顺序才能实现期望的结果。在某些实施方式中，多任务处理和并行处理也是可以的或者可能是有利的。
本说明书中的各个实施例均采用递进的方式描述，各个实施例之间相同相似的部分互相参见即可，每个实施例重点说明的都是与其他实施例的不同之处。尤其，对于装置、设备、非易失性计算机存储介质实施例而言，由于其基本相似于方法实施例，所以描述的比较简单，相关之处参见方法实施例的部分说明即可。
本说明书实施例提供的装置、设备、非易失性计算机存储介质与方法是对应的，因此，装置、设备、非易失性计算机存储介质也具有与对应方法类似的有益技术效果，由于上面已经对方法的有益技术效果进行了详细说明，因此，这里不再赘述对应装置、设备、非易失性计算机存储介质的有益技术效果。
在20世纪90年代，对于一个技术的改进可以很明显地区分是硬件上的改进(例如，对二极管、晶体管、开关等电路结构的改进)还是软件上的改进(对于方法流程的改进)。然而，随着技术的发展，当今的很多方法流程的改进已经可以视为硬件电路结 构的直接改进。设计人员几乎都通过将改进的方法流程编程到硬件电路中来得到相应的硬件电路结构。因此，不能说一个方法流程的改进就不能用硬件实体模块来实现。例如，可编程逻辑器件(Programmable Logic Device,PLD)(例如现场可编程门阵列(Field Programmable Gate Array，FPGA))就是这样一种集成电路，其逻辑功能由用户对器件编程来确定。由设计人员自行编程来把一个数字***“集成”在一片PLD上，而不需要请芯片制造厂商来设计和制作专用的集成电路芯片。而且，如今，取代手工地制作集成电路芯片，这种编程也多半改用“逻辑编译器(logic compiler)”软件来实现，它与程序开发撰写时所用的软件编译器相类似，而要编译之前的原始代码也得用特定的编程语言来撰写，此称之为硬件描述语言(Hardware Description Language，HDL)，而HDL也并非仅有一种，而是有许多种，如ABEL(Advanced Boolean Expression Language)、AHDL(Altera Hardware Description Language)、Confluence、CUPL(Cornell University Programming Language)、HDCal、JHDL(Java Hardware Description Language)、Lava、Lola、MyHDL、PALASM、RHDL(Ruby Hardware Description Language)等，目前最普遍使用的是VHDL(Very-High-Speed Integrated Circuit Hardware Description Language)与Verilog。本领域技术人员也应该清楚，只需要将方法流程用上述几种硬件描述语言稍作逻辑编程并编程到集成电路中，就可以很容易得到实现该逻辑方法流程的硬件电路。
控制器可以按任何适当的方式实现，例如，控制器可以采取例如微处理器或处理器以及存储可由该(微)处理器执行的计算机可读程序代码(例如软件或固件)的计算机可读介质、逻辑门、开关、专用集成电路(Application Specific Integrated Circuit，ASIC)、可编程逻辑控制器和嵌入微控制器的形式，控制器的例子包括但不限于以下微控制器：ARC 625D、Atmel AT91SAM、Microchip PIC18F26K20以及Silicone Labs C8051F320，存储器控制器还可以被实现为存储器的控制逻辑的一部分。本领域技术人员也知道，除了以纯计算机可读程序代码方式实现控制器以外，完全可以通过将方法步骤进行逻辑编程来使得控制器以逻辑门、开关、专用集成电路、可编程逻辑控制器和嵌入微控制器等的形式来实现相同功能。因此这种控制器可以被认为是一种硬件部件，而对其内包括的用于实现各种功能的装置也可以视为硬件部件内的结构。或者甚至，可以将用于实现各种功能的装置视为既可以是实现方法的软件模块又可以是硬件部件内的结构。
上述实施例阐明的***、装置、模块或单元，具体可以由计算机芯片或实体实现，或者由具有某种功能的产品来实现。一种典型的实现设备为计算机。具体的，计算机例如可以为个人计算机、膝上型计算机、蜂窝电话、相机电话、智能电话、个人数字 助理、媒体播放器、导航设备、电子邮件设备、游戏控制台、平板计算机、可穿戴设备或者这些设备中的任何设备的组合。
为了描述的方便，描述以上装置时以功能分为各种单元分别描述。当然，在实施本申请时可以把各单元的功能在同一个或多个软件和/或硬件中实现。
本领域内的技术人员应明白，本发明的实施例可提供为方法、***、或计算机程序产品。因此，本发明可采用完全硬件实施例、完全软件实施例、或结合软件和硬件方面的实施例的形式。而且，本发明可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、CD-ROM、光学存储器等)上实施的计算机程序产品的形式。
本发明是参照根据本发明实施例的方法、设备(***)、和计算机程序产品的流程图和/或方框图来描述的。应理解可由计算机程序指令实现流程图和/或方框图中的每一流程和/或方框、以及流程图和/或方框图中的流程和/或方框的结合。可提供这些计算机程序指令到通用计算机、专用计算机、嵌入式处理机或其他可编程数据处理设备的处理器以产生一个机器，使得通过计算机或其他可编程数据处理设备的处理器执行的指令产生用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的装置。
这些计算机程序指令也可存储在能引导计算机或其他可编程数据处理设备以特定方式工作的计算机可读存储器中，使得存储在该计算机可读存储器中的指令产生包括指令装置的制造品，该指令装置实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能。
这些计算机程序指令也可装载到计算机或其他可编程数据处理设备上，使得在计算机或其他可编程设备上执行一系列操作步骤以产生计算机实现的处理，从而在计算机或其他可编程设备上执行的指令提供用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的步骤。
在一个典型的配置中，计算设备包括一个或多个处理器(CPU)、输入/输出接口、网络接口和内存。
内存可能包括计算机可读介质中的非永久性存储器，随机存取存储器(RAM)和/或非易失性内存等形式，如只读存储器(ROM)或闪存(flash RAM)。内存是计算机可读介质的示例。
计算机可读介质包括永久性和非永久性、可移动和非可移动媒体可以由任何方法或技术来实现信息存储。信息可以是计算机可读指令、数据结构、程序的模块或其他数据。计算机的存储介质的例子包括，但不限于相变内存(PRAM)、静态随机存取存储器(SRAM)、动态随机存取存储器(DRAM)、其他类型的随机存取存储器(RAM)、只读存储器(ROM)、电可擦除可编程只读存储器(EEPROM)、快闪记忆体或其他内存技术、只读光盘只读存储器(CD-ROM)、数字多功能光盘(DVD)或其他光学存储、磁盒式磁带，磁带磁磁盘存储或其他磁性存储设备或任何其他非传输介质，可用于存储可以被计算设备访问的信息。按照本文中的界定，计算机可读介质不包括暂存电脑可读媒体(transitory media)，如调制的数据信号和载波。
还需要说明的是，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、商品或者设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、商品或者设备所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括所述要素的过程、方法、商品或者设备中还存在另外的相同要素。
本申请可以在由计算机执行的计算机可执行指令的一般上下文中描述，例如程序模块。一般地，程序模块包括执行特定任务或实现特定抽象数据类型的例程、程序、对象、组件、数据结构等等。也可以在分布式计算环境中实践本申请，在这些分布式计算环境中，由通过通信网络而被连接的远程处理设备来执行任务。在分布式计算环境中，程序模块可以位于包括存储设备在内的本地和远程计算机存储介质中。
本说明书中的各个实施例均采用递进的方式描述，各个实施例之间相同相似的部分互相参见即可，每个实施例重点说明的都是与其他实施例的不同之处。尤其，对于***实施例而言，由于其基本相似于方法实施例，所以描述的比较简单，相关之处参见方法实施例的部分说明即可。
以上所述仅为本申请的实施例而已，并不用于限制本申请。对于本领域技术人员来说，本申请可以有各种更改和变化。凡在本申请的精神和原理之内所作的任何修改、等同替换、改进等，均应包含在本申请的权利要求范围之内。

Claims (21)

  1. 一种鉴权方法，包括：
    接收访问请求；
    当确定所述访问请求未拥有访问权限时，按预设的鉴权***确定策略，根据所述访问请求中的标识信息，从至少两个鉴权***中确定目标鉴权***，所述鉴权***确定策略包括标识信息与鉴权***之间的对应关系，所述至少两个鉴权***各自作为微服务组件独立部署于微服务框架中；
    将所述访问请求发送至所述目标鉴权***，以使所述目标鉴权***对所述访问请求进行鉴权。
  2. 根据权利要求1所述的方法，所述标识信息包括统一资源定位符、统一资源标识符以及鉴权***接口参数中的至少一种。
  3. 根据权利要求1所述的方法，所述访问请求还包括登录信息；
    所述目标鉴权***对所述访问请求进行鉴权包括：
    所述目标鉴权***根据所述登录信息对所述访问请求进行鉴权。
  4. 根据权利要求1所述的方法，所述方法还包括：
    接收第一权限信息，所述第一权限信息为所述目标鉴权***在所述访问请求通过鉴权后，响应所述访问请求发送的权限信息；
    向所述访问请求的发送方发送所述第一权限信息，以使所述发送方将所述第一权限信息设置于新的访问请求中。
  5. 根据权利要求4所述的方法，在所述访问请求为http请求时；
    所述方法还包括：
    与所述目标鉴权***建立会话；
    所述接收第一权限信息包括：
    基于所述会话接收第一权限信息，以使所述目标鉴权***基于所述会话进行会话控制。
  6. 根据权利要求1所述的方法，所述确定所述访问请求未拥有访问权限步骤包括：
    判断所述访问请求中是否包含第二权限信息，所述第二权限信息包括所述目标鉴权***在包含登录信息的访问请求鉴权通过时生成的权限信息，所述包含登录信息的访问请求为所述访问请求的发送方在发送所述访问请求之前发送的访问请求；
    若所述访问请求未包含所述第二权限信息，则确定所述访问请求未拥有访问权限。
  7. 根据权利要求6所述的方法，
    若所述访问请求包含所述第二权限信息，则根据所述第二权限信息确定所述访问请求是否拥有访问权限。
  8. 一种业务服务方法，包括：
    接收业务服务请求；
    当确定所述业务服务请求未拥有访问权限时，按预设的鉴权***确定策略，根据所述业务服务请求中的标识信息，从至少两个鉴权***中确定目标鉴权***，所述鉴权***确定策略包括标识信息与鉴权***之间的对应关系，所述至少两个鉴权***各自作为微服务组件独立部署于微服务框架中；
    将所述业务服务请求发送至所述目标鉴权***，以使所述目标鉴权***对所述业务服务请求进行鉴权；
    当确定所述业务服务请求在所述目标鉴权***中鉴权通过时，将所述业务服务请求发送至对应的业务服务***，以使所述业务服务***根据所述业务服务请求提供业务服务。
  9. 根据权利要求8所述的方法，所述方法还包括：
    当确定所述业务服务请求拥有访问权限时，将所述业务服务请求发送至对应的业务服务***，以使所述业务服务***根据所述业务服务请求提供业务服务。
  10. 一种鉴权装置，包括：
    接收单元，接收访问请求；
    确定单元，当确定所述访问请求未拥有访问权限时，按预设的鉴权***确定策略，根据所述访问请求中的标识信息，从至少两个鉴权***中确定目标鉴权***，所述鉴权***确定策略包括标识信息与鉴权***之间的对应关系，所述至少两个鉴权***各自作为微服务组件独立部署于微服务框架中；
    发送单元，将所述访问请求发送至所述目标鉴权***，以使所述目标鉴权***对所述访问请求进行鉴权。
  11. 根据权利要求10所述的装置，所述标识信息包括统一资源定位符、统一资源标识符以及鉴权***接口参数中的至少一种。
  12. 根据权利要求10所述的装置，所述访问请求还包括登录信息，
    所述目标鉴权***对所述访问请求进行鉴权包括：
    所述目标鉴权***根据所述登录信息对所述访问请求进行鉴权。
  13. 根据权利要求10所述的装置，所述装置还包括：接收单元，
    所述接收单元接收第一权限信息，所述第一权限信息为所述目标鉴权***在所述访问请求通过鉴权后，响应所述访问请求发送的权限信息；
    所述发送单元向所述访问请求的发送方发送所述第一权限信息，以使所述发送方将所述第一权限信息设置于新的访问请求中。
  14. 根据权利要求13所述的装置，在所述访问请求为http请求时，
    所述装置还包括：建立单元
    通过所述建立单元与所述目标鉴权***建立会话；
    所述接收第一权限信息包括：
    基于所述会话接收第一权限信息，以使所述目标鉴权***基于所述会话进行会话控制。
  15. 根据权利要求10所述的装置，
    所述确定所述访问请求未拥有访问权限步骤包括：
    所述确定单元判断所述访问请求中是否包含第二权限信息，所述第二权限信息包括所述目标鉴权***在包含登录信息的访问请求鉴权通过时生成的权限信息，所述包含登录信息的访问请求为所述访问请求的发送方发送所述访问请求之前发送的访问请求；
    若所述访问请求未包含所述第二权限信息，则所述确定单元根据所述第二权限信息确定所述访问请求未拥有访问权限。
  16. 根据权利要求15所述的装置，
    若所述访问请求包含所述第二权限信息，则所述确定单元确定所述访问请求是否拥有访问权限。
  17. 一种鉴权***，包括：鉴权单元和拦截单元；
    所述鉴权单元中基于微服务框架部署有至少两个鉴权***，所述至少两个鉴权***各自作为微服务组件独立部署于所述微服务框架中；
    所述拦截单元接收访问请求；
    当所述拦截单元确定所述访问请求未拥有访问权限时，按预设的鉴权***确定策略，根据所述访问请求中的标识信息，从所述至少两个鉴权***中确定目标鉴权***，所述鉴权***确定策略包括标识信息与鉴权***之间的对应关系；
    所述拦截单元将所述访问请求发送至所述目标鉴权***，以使所述目标鉴权***对所述访问请求进行鉴权。
  18. 一种业务服务装置，包括：
    接收单元，接收业务服务请求；
    确定单元，当确定所述业务服务请求未拥有访问权限时，按预设的鉴权***确定策略，根据所述业务服务请求中的标识信息，从至少两个鉴权***中确定目标鉴权***，所述鉴权***确定策略包括标识信息与鉴权***之间的对应关系，所述至少两个鉴权***各自作为微服务组件独立部署于微服务框架中；
    发送单元，将所述业务服务请求发送至所述目标鉴权***，以使所述目标鉴权***对所述业务服务请求进行鉴权；
    当确定所述业务服务请求在所述目标鉴权***中鉴权通过时，所述发送单元将所述业务服务请求发送至对应的业务服务***，以使所述业务服务***根据所述业务服务请求提供业务服务。
  19. 根据权利要求18所述的装置，
    当确定所述业务服务请求拥有访问权限时，所述发送单元将所述业务服务请求发送至对应的服务***，以使所述业务服务***根据所述业务服务请求提供业务服务。
  20. 一种用于鉴权的电子设备，包括：
    至少一个处理器；以及，
    与所述至少一个处理器通信连接的存储器；其中，
    所述存储器存储有可被所述至少一个处理器执行的指令，所述指令被所述至少一个处理器执行，以使所述至少一个处理器能够：
    接收访问请求；
    当确定所述访问请求未拥有访问权限时，按预设的鉴权***确定策略，根据所述访问请求中的标识信息，从至少两个鉴权***中确定目标鉴权***，所述鉴权***确定策略包括标识信息与鉴权***之间的对应关系，所述至少两个鉴权***各自作为微服务组件独立部署于微服务框架中；
    将所述访问请求发送至所述目标鉴权***，以使所述目标鉴权***对所述访问请求进行鉴权。
  21. 一种用于业务服务的电子设备，包括：
    至少一个处理器；以及，
    与所述至少一个处理器通信连接的存储器；其中，
    所述存储器存储有可被所述至少一个处理器执行的指令，所述指令被所述至少一个处理器执行，以使所述至少一个处理器能够：
    接收业务服务请求；
    当确定所述业务服务请求未拥有访问权限时，按预设的鉴权***确定策略，根据 所述业务服务请求中的标识信息，从至少两个鉴权***中确定目标鉴权***，所述鉴权***确定策略包括标识信息与鉴权***之间的对应关系，所述至少两个鉴权***各自作为微服务组件独立部署于微服务框架中；
    将所述业务服务请求发送至所述目标鉴权***，以使所述目标鉴权***对所述业务服务请求进行鉴权；
    当确定所述业务服务请求在所述目标鉴权***中鉴权通过时，将所述业务服务请求发送至对应的业务服务***，以使所述业务服务***根据所述业务服务请求提供业务服务。
PCT/CN2020/071977 2019-08-02 2020-01-14 一种鉴权与业务服务方法、装置以及设备 WO2021022792A1 (zh)

Priority Applications (1)

Application Number Priority Date Filing Date Title
US16/805,025 US10728247B1 (en) 2019-08-02 2020-02-28 Selecting an authentication system for handling an authentication request

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
CN201910710503.0A CN110460595B (zh) 2019-08-02 2019-08-02 一种鉴权与业务服务方法、装置以及设备
CN201910710503.0 2019-08-02

Related Child Applications (1)

Application Number Title Priority Date Filing Date
US16/805,025 Continuation US10728247B1 (en) 2019-08-02 2020-02-28 Selecting an authentication system for handling an authentication request

Publications (1)

Publication Number Publication Date
WO2021022792A1 true WO2021022792A1 (zh) 2021-02-11

Family

ID=68484587

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2020/071977 WO2021022792A1 (zh) 2019-08-02 2020-01-14 一种鉴权与业务服务方法、装置以及设备

Country Status (3)

Country Link
CN (1) CN110460595B (zh)
TW (1) TWI729718B (zh)
WO (1) WO2021022792A1 (zh)

Cited By (10)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN112995324A (zh) * 2021-03-10 2021-06-18 中国民航信息网络股份有限公司 服务调用方法、装置、计算机可读介质以及设备
CN113240136A (zh) * 2021-05-17 2021-08-10 上海中通吉网络技术有限公司 物流站点设备统一管理***及方法
CN113239377A (zh) * 2021-05-14 2021-08-10 北京百度网讯科技有限公司 权限控制方法、装置、设备以及存储介质
CN113672901A (zh) * 2021-08-30 2021-11-19 济南浪潮数据技术有限公司 访问请求处理方法、容器云平台、电子设备及存储介质
CN114221782A (zh) * 2021-11-09 2022-03-22 中央广播电视总台 一种认证鉴权方法、设备、芯片及存储介质
CN114675876A (zh) * 2022-03-30 2022-06-28 苏州浪潮智能科技有限公司 一种业务处理方法、装置、电子设备及存储介质
CN114785578A (zh) * 2022-04-13 2022-07-22 福建天晴数码有限公司 一种rpc服务权限管理的方法及***
CN115022389A (zh) * 2022-05-26 2022-09-06 携程旅游网络技术（上海）有限公司 全链路信息的处理方法、***、电子设备及存储介质
CN116980182A (zh) * 2023-06-21 2023-10-31 杭州明实科技有限公司 异常请求检测方法、装置和电子设备
CN117014226A (zh) * 2023-09-22 2023-11-07 云粒智慧科技有限公司 服务请求鉴权方法、装置、设备、***和存储介质

Families Citing this family (10)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US10728247B1 (en) 2019-08-02 2020-07-28 Alibaba Group Holding Limited Selecting an authentication system for handling an authentication request
CN110460595B (zh) * 2019-08-02 2021-03-30 创新先进技术有限公司 一种鉴权与业务服务方法、装置以及设备
CN111488598B (zh) * 2020-04-09 2023-04-07 腾讯科技（深圳）有限公司 访问控制方法、装置、计算机设备和存储介质
CN111835789B (zh) * 2020-07-28 2021-12-03 北京金山云网络技术有限公司 一种服务鉴权方法、装置、设备、***及存储介质
CN111935276B (zh) * 2020-08-07 2022-04-26 中国联合网络通信集团有限公司 远程主机访问方法、装置及设备
CN112600843B (zh) * 2020-12-15 2022-10-04 深圳康佳电子科技有限公司 一种鉴权方法、存储介质及网关
CN112804224B (zh) * 2021-01-07 2023-07-14 沈阳麟龙科技股份有限公司 一种基于微服务的认证鉴权方法、装置、介质及电子设备
CN114912148B (zh) * 2021-02-08 2024-07-23 网银在线（北京）科技有限公司 鉴权方法及装置、***、计算机存储介质、电子设备
CN113448568A (zh) * 2021-06-24 2021-09-28 未鲲(上海)科技服务有限公司 服务编排调用方法、装置、计算机设备及存储介质
CN116389103B (zh) * 2023-03-30 2024-01-26 成都道客数字科技有限公司 一种基于角色权限的云原生微服务分布式鉴权方法和***

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN1992596A (zh) * 2005-12-27 2007-07-04 国际商业机器公司 用户验证设备和用户验证方法
US20180330068A1 (en) * 2017-05-11 2018-11-15 Lenovo (Singapore) Pte. Ltd. Apparatus, systems, and method for determining authentication
CN109327477A (zh) * 2018-12-06 2019-02-12 泰康保险集团股份有限公司 认证鉴权方法、装置及存储介质
CN110460595A (zh) * 2019-08-02 2019-11-15 阿里巴巴集团控股有限公司 一种鉴权与业务服务方法、装置以及设备

Family Cites Families (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
GB0901589D0 (en) * 2009-01-30 2009-03-11 Omar Ralph M Improvements relating to multifunction authentication systems
CA2774648C (en) * 2009-09-30 2017-07-25 Amazon Technologies, Inc. Modular device authentication framework
US10754939B2 (en) * 2017-06-26 2020-08-25 International Business Machines Corporation System and method for continuous authentication using augmented reality and three dimensional object recognition
CN108462697B (zh) * 2018-02-07 2020-09-11 Oppo广东移动通信有限公司 数据处理方法和装置、电子设备、计算机可读存储介质

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN1992596A (zh) * 2005-12-27 2007-07-04 国际商业机器公司 用户验证设备和用户验证方法
US20180330068A1 (en) * 2017-05-11 2018-11-15 Lenovo (Singapore) Pte. Ltd. Apparatus, systems, and method for determining authentication
CN109327477A (zh) * 2018-12-06 2019-02-12 泰康保险集团股份有限公司 认证鉴权方法、装置及存储介质
CN110460595A (zh) * 2019-08-02 2019-11-15 阿里巴巴集团控股有限公司 一种鉴权与业务服务方法、装置以及设备

Cited By (17)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN112995324B (zh) * 2021-03-10 2023-07-14 中国民航信息网络股份有限公司 服务调用方法、装置、计算机可读介质以及设备
CN112995324A (zh) * 2021-03-10 2021-06-18 中国民航信息网络股份有限公司 服务调用方法、装置、计算机可读介质以及设备
CN113239377A (zh) * 2021-05-14 2021-08-10 北京百度网讯科技有限公司 权限控制方法、装置、设备以及存储介质
CN113239377B (zh) * 2021-05-14 2024-05-17 北京百度网讯科技有限公司 权限控制方法、装置、设备以及存储介质
CN113240136A (zh) * 2021-05-17 2021-08-10 上海中通吉网络技术有限公司 物流站点设备统一管理***及方法
CN113672901A (zh) * 2021-08-30 2021-11-19 济南浪潮数据技术有限公司 访问请求处理方法、容器云平台、电子设备及存储介质
CN113672901B (zh) * 2021-08-30 2024-03-29 济南浪潮数据技术有限公司 访问请求处理方法、容器云平台、电子设备及存储介质
CN114221782A (zh) * 2021-11-09 2022-03-22 中央广播电视总台 一种认证鉴权方法、设备、芯片及存储介质
CN114221782B (zh) * 2021-11-09 2023-11-24 中央广播电视总台 一种认证鉴权方法、设备、芯片及存储介质
CN114675876A (zh) * 2022-03-30 2022-06-28 苏州浪潮智能科技有限公司 一种业务处理方法、装置、电子设备及存储介质
CN114785578B (zh) * 2022-04-13 2023-09-29 福建天晴数码有限公司 一种rpc服务权限管理的方法及***
CN114785578A (zh) * 2022-04-13 2022-07-22 福建天晴数码有限公司 一种rpc服务权限管理的方法及***
CN115022389A (zh) * 2022-05-26 2022-09-06 携程旅游网络技术（上海）有限公司 全链路信息的处理方法、***、电子设备及存储介质
CN116980182A (zh) * 2023-06-21 2023-10-31 杭州明实科技有限公司 异常请求检测方法、装置和电子设备
CN116980182B (zh) * 2023-06-21 2024-02-27 杭州明实科技有限公司 异常请求检测方法、装置和电子设备
CN117014226A (zh) * 2023-09-22 2023-11-07 云粒智慧科技有限公司 服务请求鉴权方法、装置、设备、***和存储介质
CN117014226B (zh) * 2023-09-22 2024-01-12 云粒智慧科技有限公司 服务请求鉴权方法、装置、设备、***和存储介质

Also Published As

Publication number Publication date
TW202107362A (zh) 2021-02-16
TWI729718B (zh) 2021-06-01
CN110460595B (zh) 2021-03-30
CN110460595A (zh) 2019-11-15

Similar Documents

Publication Publication Date Title
WO2021022792A1 (zh) 一种鉴权与业务服务方法、装置以及设备
US11089023B2 (en) Computer readable storage media for tiered connection pooling and methods and systems for utilizing same
JP7080242B2 (ja) 認証方法及びブロックチェーンに基づいた認証データ処理方法及び装置
US10965664B2 (en) Single sign-on for unmanaged mobile devices
WO2021017427A1 (zh) 基于区块链的身份验证方法、装置及设备
EP3308525B1 (en) Single sign-on for unmanaged mobile devices
US9578015B2 (en) Step-up authentication for single sign-on
EP3092775B1 (en) Method and system for determining whether a terminal logging into a website is a mobile terminal
EP3333744A1 (en) Authorization code flow for in-browser applications
US11526620B2 (en) Impersonation for a federated user
US10728247B1 (en) Selecting an authentication system for handling an authentication request
US8819801B2 (en) Secure machine enrollment in multi-tenant subscription environment
US10623410B2 (en) Multi-level, distributed access control between services and applications
CN110447033B (zh) 基于客户访问限制的认证
CN108289080B (zh) 一种访问文件***的方法、装置和***

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 20849801

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 20849801

Country of ref document: EP

Kind code of ref document: A1