Single sign-on method and device based on zero-trust proxy

Abstract

The invention discloses a single sign-on method and device based on zero-trust proxy. According to the application, a permission authentication request sent by a first application is responded, and a corresponding application token is obtained through a permission service according to the permission authentication request; the authority authentication request comprises a user token; the user token is obtained by responding to a first identity authentication request of a user terminal logging in the first application; and returning the application token to the first application to enable the first application to obtain the use permission of the first application from a permission service according to the application token, and sending the application token to a security risk control service to perform real-time risk management and control. According to the method and the device, the security degree of the system is effectively improved while the execution efficiency of the user login operation is ensured.

Description

Technical Field

[0001] The present application relates to the field of network security verification, and in particular to a single sign-on method and device based on zero-trust agent. Background Art

[0002] Currently, most IT (Information Technology) systems of various enterprises use single sign-on technology as an identity authentication mechanism. Through this mechanism, users only need to enter their credentials when logging in for the first time, and the system will automatically verify their identities when accessing other related applications. This mechanism effectively simplifies the user's login operation process, improves operational efficiency, and reduces the security risks caused by multiple logins. However, this mechanism often relies on the trust relationship between identity providers and service providers to achieve cross-system identity authentication and authorization through standard protocols.

[0003] However, when a user's login credentials are stolen, since the same login credentials are used between different application systems, the attacker will gain access to multiple application systems at the same time, seriously affecting the user's network security; and, when the login credentials expire, all application systems will expire at the same time, which does not conform to the zero-trust system's security concept of "never trust, always verify."

[0004] Therefore, how to reduce the security risks when users use different application systems in a single sign-on scenario while ensuring user operation efficiency is a technical problem that needs to be solved at present. Summary of the invention

[0005] The present application provides a single sign-on method and device based on zero-trust agent to solve the technical problem of how to reduce the security risks when users use different application systems in a single sign-on scenario while ensuring the user's operating efficiency.

[0006] In order to solve the above technical problems, in a first aspect, an embodiment of the present application provides a single sign-on method based on a zero-trust agent, comprising:

[0007] Responding to a permission authentication request sent by the first application, and obtaining a corresponding application token through a permission service according to the permission authentication request; the permission authentication request includes: a user token; the user token is obtained by responding to a first identity authentication request of a user terminal that logs in to the first application;

[0008] The application token is returned to the first application, so that the first application obtains the permission to use the first application from the permission service according to the application token, and sends the application token to the security risk control service for real-time risk management and control.

[0009] Compared with the prior art, the embodiments of the present application have the following beneficial effects: through double-layer token authentication, it is more difficult for an attacker to use a stolen token to access the first application, thereby effectively improving the security of access to the first application; further, by configuring corresponding permissions for different first applications and combining corresponding application tokens, users can only access their authorized first applications, thereby effectively improving the data security of other unauthorized first applications when the user's application token is stolen; finally, by performing real-time risk management on application tokens, the real-time identification of attackers' attack operations is effectively improved to ensure the security of the system.

[0010] In some embodiments of the first aspect of the present application, the responding to the permission authentication request sent by the first application and obtaining the corresponding application token through the permission service according to the permission authentication request includes:

[0011] The permission authentication request further includes: an application identifier; the permission authentication request is generated when the user terminal sends the user token to the first application; the application identifier is an identifier corresponding to the first application;

[0012] Sending the user token to the permission service, so that the permission service returns a list of accessible applications according to the user token;

[0013] When the application identifier exists in the accessible application list, the corresponding application token is generated.

[0014] Compared with the prior art, the above embodiment has the following beneficial effects: by introducing application identification, the granularity of user authority management is improved, and application tokens are further granted only to authorized applications, preventing applications from being abused by unauthorized users, thereby improving the security of the system; further, through a manageable accessible application list mechanism, flexible access control of users to multiple applications is achieved, thereby improving the scalability and flexibility of the system.

[0015] In some embodiments of the first aspect of the present application, the user token is obtained by responding to a first identity authentication request of a user terminal logging into the first application, including:

[0016] Responding to the identity authentication request of the user terminal, generating a corresponding user token according to the identity authentication request, and sending the user token to the security risk control service for real-time risk management;

[0017] The user token is returned to the user terminal.

[0018] Compared with the prior art, the above embodiment has the following beneficial effects: when the user logs in for the first time, a user token for identity authentication is generated, thereby avoiding the user from repeating identity authentication when using the application, thereby improving the user's operating efficiency when using the application; further, when the user token corresponding to the user is generated, the user token is subjected to real-time risk monitoring, thereby avoiding system risks brought about by changes in the user's usage environment and improving security.

[0019] In some embodiments of the first aspect of the present application, the real-time risk management and control includes:

[0020] When responding to an identity authentication request or a permission authentication request of the user terminal, obtaining a risk level updated by the security risk control service according to the user token or the application token of the user terminal and the device information of the user terminal; the device information of the user terminal is collected and obtained in real time by the security risk control service in response to the identity authentication request of the user terminal;

[0021] According to the risk level, restricting operations on the user token or the application token;

[0022] When the state of the user token or the application token changes, the token with the changed state is sent to the authority service.

[0023] Compared with the prior art, the above embodiment has the following beneficial effects: through the security risk control service, the changing status of the user token or application token is monitored in real time, and further combined with the device information of the user terminal, the actual operating environment when the user logs in is reflected, and the risk level of the user terminal is accurately updated, thereby dynamically adjusting the access rights of the corresponding token according to the real-time updated risk level, quickly responding to potential security threats, and significantly improving the security and responsiveness of the system.

[0024] In some embodiments of the first aspect of the present application, returning the application token to the first application so that the first application obtains the first application use permission from the permission service according to the application token includes:

[0025] After the corresponding application token is obtained through the permission service, the application token is sent to the permission service, so that the permission service verifies the application token pushed by the first application and returns the corresponding first application usage permission.

[0026] Compared with the prior art, the above embodiment has the following beneficial effects: by returning the generated application token to the permission service, the validity of the application token returned by the application can be accurately verified, thereby avoiding system risks caused by token forgery or abuse, and improving the security of single sign-on; in addition, the token transmission and verification between the permission service and the application form a closed loop, ensuring the strictness and compliance of permission management, and improving the security of the system.

[0027] In a second aspect, an embodiment of the present application further provides a single sign-on device based on a zero-trust agent, comprising: an application token generation module and a first application usage permission acquisition module;

[0028] The application token generation module is used to respond to the permission authentication request sent by the first application, and obtain the corresponding application token through the permission service according to the permission authentication request; the permission authentication request includes: a user token and an application identifier; the user token is obtained by responding to the first identity authentication request of the user terminal that logs in to the first application; the application identifier is the identifier corresponding to the first application;

[0029] The first application usage permission acquisition module is used to return the application token to the first application, so that the first application obtains the first application usage permission from the permission service according to the application token, and sends the application token to the security risk control service for real-time risk management.

[0030] In some embodiments of the second aspect of the present application, the responding to the permission authentication request sent by the first application and obtaining the corresponding application token through the permission service according to the permission authentication request includes:

[0031] The permission authentication request is generated by the user terminal sending the user token to the first application;

[0032] Sending the user token to the permission service, so that the permission service returns a list of accessible applications according to the user token;

[0033] When the application identifier exists in the accessible application list, the corresponding application token is generated.

[0034] In some embodiments of the second aspect of the present application, the user token is obtained by responding to a first identity authentication request of a user terminal logging into the first application, including:

[0035] Responding to the identity authentication request of the user terminal, generating a corresponding user token according to the identity authentication request, and sending the user token to the security risk control service for real-time risk management;

[0036] The user token is returned to the user terminal.

[0037] In some embodiments of the second aspect of the present application, the real-time risk management and control includes:

[0038] When responding to an identity authentication request or a permission authentication request of the user terminal, obtaining a risk level updated by the security risk control service according to the user token or the application token of the user terminal and the device information of the user terminal; the device information of the user terminal is collected and obtained in real time by the security risk control service in response to the identity authentication request of the user terminal;

[0039] According to the risk level, restricting operations on the user token or the application token;

[0040] When the state of the user token or the application token changes, the token with the changed state is sent to the authority service.

[0041] In some embodiments of the second aspect of the present application, returning the application token to the first application so that the first application obtains the first application use permission from the permission service according to the application token includes:

[0042] After the corresponding application token is obtained through the permission service, the application token is sent to the permission service, so that the permission service verifies the application token pushed by the first application and returns the corresponding first application usage permission. BRIEF DESCRIPTION OF THE DRAWINGS

[0043] Figure 1 A flowchart of a single sign-on method based on a zero-trust agent provided in some embodiments of the present application;

[0044] Figure 2 Another flowchart of a single sign-on method based on a zero-trust agent provided in some embodiments of the present application;

[0045] Figure 3 This is a structural diagram of a single sign-on device based on a zero-trust agent provided in some embodiments of the present application. DETAILED DESCRIPTION

[0046] Currently, most IT systems of enterprises use single sign-on technology as an authentication mechanism. Through this mechanism, users only need to enter their credentials when logging in for the first time, and the system will automatically verify their identities when accessing other related applications. However, when the user's login credentials are stolen, since the same login credentials are used between different application systems, the attacker can obtain access rights to multiple application systems at the same time, seriously affecting the user's network security.

[0047] In order to solve the above technical problems, the technical solutions in the embodiments of the present application will be clearly and completely described below in conjunction with the drawings in the embodiments of the present application. Obviously, the described embodiments are only part of the embodiments of the present application, not all of the embodiments. Based on the embodiments in the present application, all other embodiments obtained by ordinary technicians in this field without creative work are within the scope of protection of this application.

[0048] Embodiment 1

[0049] Please refer to Figure 1 , a single sign-on method based on zero trust agent provided in an embodiment of the present application, including S10 to S20. Figure 2 , is another flow chart of a single sign-on method based on zero trust agent provided in an embodiment of the present application, from Figure 2 It can be seen that the single sign-on method based on zero-trust agent provided in the embodiment of the present application can be used in a single sign-on system that includes at least the following modules: business application, authentication service, security risk control service, and permission service; further, in some embodiments of the present application, the security risk control service includes at least: environment perception service and business security policy service. The execution subject of S10 to S20 mentioned in the embodiment of the present application is the authentication service in the above-mentioned single sign-on system.

[0050] Further, in some embodiments of the present application, S10 to S20 are specifically:

[0051] S10: Respond to the permission authentication request sent by the first application, and obtain the corresponding application token through the permission service according to the permission authentication request; the permission authentication request includes: a user token; the user token is obtained by responding to the first identity authentication request of the user terminal that logs in to the first application.

[0052] Further, in some embodiments of the present application, the user token is obtained by responding to a first identity authentication request of a user terminal logging into the first application, including:

[0053] Responding to the identity authentication request of the user terminal, generating a corresponding user token according to the identity authentication request, and sending the user token to the security risk control service for real-time risk management;

[0054] The user token is returned to the user terminal.

[0055] When a user logs in for the first time, a user token is generated for identity authentication to avoid the user having to repeat identity authentication when using the application, thereby improving the user's operational efficiency when using the application; further, when the user token corresponding to the user is generated, the user token is monitored for risks in real time to avoid system risks caused by changes in the user's usage environment and improve security.

[0056] Preferably, reference Figure 2 , the user token can be obtained through the following preferred implementation steps:

[0057] S11: The user accesses the login address provided by the business application through the user terminal (the business application here is the first application that any user needs to log in). At this time, the single sign-on system will automatically redirect to the login address provided by the authentication service. The user terminal sends an identity authentication request to the authentication service. At the same time, the user terminal synchronously submits the device information and user identification to the authentication service.

[0058] S12: When the authentication service passes the identity authentication request of the user terminal, a user token is generated based on the device information, user ID, timestamp and other information submitted in S11, and the user token is returned to the user terminal. The user token is a special string generated by a certain algorithm based on data content including at least user ID, creation time, expiration time, etc. A user is only allowed to have one user token in a login cycle.

[0059] Further, in some embodiments of the present application, the responding to the permission authentication request sent by the first application and obtaining the corresponding application token through the permission service according to the permission authentication request includes:

[0060] The permission authentication request further includes: an application identifier; the permission authentication request is generated when the user terminal sends the user token to the first application; the application identifier is an identifier corresponding to the first application;

[0061] Sending the user token to the permission service, so that the permission service returns a list of accessible applications according to the user token;

[0062] When the application identifier exists in the accessible application list, the corresponding application token is generated.

[0063] By introducing application identification, the granularity of user permission management is improved, and application tokens are further granted only to authorized applications, preventing applications from being abused by unauthorized users and improving the security of the system. Furthermore, through a manageable accessible application list mechanism, flexible access control of users to multiple applications is achieved, improving the scalability and flexibility of the system.

[0064] Preferably, reference Figure 2 In some embodiments of the present application, the application token can be obtained by the following preferred implementation:

[0065] S13: After the user terminal receives the user token returned by the authentication service, it automatically redirects to the login address of the business application with the user token to execute the login process of the business application.

[0066] S14: The business application pushes the user token sent by the user terminal and the application identifier of the business application to the authentication service, and the authentication service generates an application token according to the obtained user token and application identifier.

[0067] S15: The authentication service pushes the user token to the authorization service.

[0068] S16: The permission service queries and returns the corresponding application list to the authentication service based on the obtained user token. The application list includes application identifiers of applications that the user can use.

[0069] S17: The authentication service checks whether there is an application identifier of the business application currently logged in by the user based on the returned application list. If so, it proves that the user has access rights to the business application. A corresponding application token is generated based on the user token, application identifier, timestamp and other parameters, and the application token is returned to the business application. At the same time, the application token is returned to the permission service. The same user can have application tokens corresponding to different business applications in one login cycle. User information, user rights and other content can only be directly obtained through the application token.

[0070] S20: Return the application token to the first application, so that the first application obtains the permission to use the first application from the permission service according to the application token, and sends the application token to the security risk control service for real-time risk management.

[0071] Further, in some embodiments of the present application, returning the application token to the first application so that the first application obtains the first application use permission from the permission service according to the application token includes:

[0072] After the corresponding application token is obtained through the permission service, the application token is sent to the permission service, so that the permission service verifies the application token pushed by the first application and returns the corresponding first application usage permission.

[0073] By returning the generated application token to the permission service, the validity of the application token returned by the application can be accurately verified to avoid system risks caused by token forgery or abuse, thereby improving the security of single sign-on. In addition, the token transmission and verification between the permission service and the application form a closed loop to ensure the strictness and compliance of permission management, thereby improving the security of the system.

[0074] Preferably, reference Figure 2 In some embodiments of the present application, the following preferred implementations can be used to enable users to obtain the right to use business applications:

[0075] S21: The business application pushes the received application token to the permission service.

[0076] S22: The permission service performs verification based on the obtained application token, including but not limited to verifying whether the application token is valid, legal, cancelled, frozen, etc. When the verification passes, it returns relevant functional permissions, data permissions, etc. to the business application, unlocking the user's relevant access rights to the business application.

[0077] Preferably, in some embodiments of the present application, after the user completes the first identity authentication login, if the user needs to change the currently logged-in business application to another business application, then S14 to S22 are executed in sequence starting from S14 to obtain relevant access rights for the new business application.

[0078] Preferably, in some embodiments of the present application, when the user token of a user expires, all application tokens will also become invalid, and it is necessary to re-perform identity authentication and login starting from S11.

[0079] Furthermore, in some embodiments of the present application, the real-time risk management and control includes:

[0080] When responding to an identity authentication request or a permission authentication request of the user terminal, obtaining a risk level updated by the security risk control service according to the user token or the application token of the user terminal and the device information of the user terminal; the device information of the user terminal is collected and obtained in real time by the security risk control service in response to the identity authentication request of the user terminal;

[0081] According to the risk level, restricting operations on the user token or the application token;

[0082] When the state of the user token or the application token changes, the token with the changed state is sent to the authority service.

[0083] Preferably, reference Figure 2 In some embodiments of the present application, risk management can be performed through the following preferred implementations:

[0084] S31: After the user terminal completes identity authentication and login, the environmental perception service continues to collect device information of the user terminal, including: MAC address, IP address, geographic location, whether the firewall is enabled, access time and other information, and performs security rating based on the above device information to obtain the risk level of the current user terminal.

[0085] S32: The environmental perception service pushes the currently updated risk level and collected device information to the business security policy service in real time; the authentication service pushes the user token generated by the user's identity authentication login and the application token generated by the business application requesting the application token to the business security policy service; the authentication service pushes the user token generated by the user's identity authentication login and the application token generated by the business application requesting the application token to the permission service.

[0086] S33: The business security policy service performs risk assessment based on the device information of the same user terminal in combination with the user token or application token. For example, it continuously updates the risk level of the current user terminal based on changes in the login IP, geographic location, login time, and firewall of the user terminal. When the risk level of the user terminal changes, the business security policy service pushes the changed risk level and the device information of the user terminal to the authentication service.

[0087] S34: The authentication service changes the status of the user token or application token of the user terminal according to the risk level returned and the device information of the user terminal, including but not limited to freezing or canceling the user token or application token. When the user token expires, all application tokens will expire. Further, the user token or application token after the status change is pushed to the permission service. When the user token expires, the invalid user token is pushed to the permission service, so that the user cannot obtain the relevant access rights of any application from the permission service; when the application token expires, the invalid application token is pushed to the permission service, so that the user cannot obtain the access rights of the corresponding business application from the permission service.

[0088] In summary, the single sign-on based on zero-trust agent provided by the embodiment of the present application has the following beneficial effects: through double-layer token authentication, it is more difficult for an attacker to use a stolen token to access the first application, thereby effectively improving the security of access to the first application; further, by configuring corresponding permissions for different first applications and combining corresponding application tokens, users can only access their authorized first applications, thereby effectively improving the data security of other unauthorized first applications when the user's application token is stolen; finally, by performing real-time risk management on application tokens, the real-time identification of attackers' attack operations is effectively improved to ensure the security of the system.

[0089] Embodiment 2

[0090] refer to Figure 3 , a single sign-on device based on zero-trust agent provided in an embodiment of the present application, includes: an application token generation module 11 and a first application usage permission acquisition module 12.

[0091] Furthermore, in some embodiments of the present application, the application token generation module 11 is used to respond to a permission authentication request sent by the first application, and obtain a corresponding application token through a permission service according to the permission authentication request; the permission authentication request includes: a user token and an application identifier; the user token is obtained by responding to the first identity authentication request of a user terminal that logs in to the first application; the application identifier is an identifier corresponding to the first application; the first application usage permission acquisition module 12 is used to return the application token to the first application, so that the first application obtains the first application usage permission from the permission service according to the application token, and sends the application token to the security risk control service for real-time risk management.

[0092] Furthermore, in some embodiments of the present application, the response to the permission authentication request sent by the first application, and obtaining a corresponding application token through a permission service based on the permission authentication request, include: the permission authentication request is generated for the user terminal to send the user token to the first application; the user token is sent to the permission service so that the permission service returns a list of accessible applications based on the user token; and when the application identifier exists in the list of accessible applications, generating the corresponding application token.

[0093] Furthermore, in some embodiments of the present application, the user token is obtained by responding to the first identity authentication request of the user terminal logging into the first application, including: responding to the identity authentication request of the user terminal, generating a corresponding user token according to the identity authentication request, and sending the user token to the security risk control service for real-time risk management; returning the user token to the user terminal.

[0094] Furthermore, in some embodiments of the present application, the real-time risk management includes: when responding to the identity authentication request or the permission authentication request of the user terminal, obtaining the risk level updated by the security risk control service based on the user token or the application token of the user terminal and the device information of the user terminal; the device information of the user terminal is collected and acquired in real time by the security risk control service in response to the identity authentication request of the user terminal; according to the risk level, restricting operations on the user token or the application token; when the status of the user token or the application token changes, sending the token with the changed status to the permission service.

[0095] Further, in some embodiments of the present application, returning the application token to the first application so that the first application obtains the first application usage permission from the permission service according to the application token includes: after obtaining the corresponding application token through the permission service, sending the application token to the permission service so that the permission service verifies the application token pushed by the first application and returns the corresponding first application usage permission.

[0096] It can be understood that the above-mentioned device item embodiments correspond to the method item embodiments of the present invention. A single sign-on device based on a zero trust agent provided in the embodiment of the present invention can implement any method item embodiment of the present invention, that is, the single sign-on method based on a zero trust agent provided in Embodiment 1.

[0097] In summary, the single sign-on device based on zero-trust agent provided by the embodiment of the present application has the following beneficial effects: through double-layer token authentication, it is more difficult for an attacker to use a stolen token to access the first application, thereby effectively improving the security of access to the first application; further, by configuring corresponding permissions for different first applications and combining corresponding application tokens, users can only access their authorized first applications, thereby effectively improving the data security of other unauthorized first applications when the user's application token is stolen; finally, by performing real-time risk management on application tokens, the real-time identification of attackers' attack operations is effectively improved to ensure the security of the system.

[0098] Embodiment 3

[0099] Based on the above-mentioned embodiment of the single sign-on method based on zero trust agent, another embodiment of the present application provides a single sign-on terminal device based on zero trust agent. The single sign-on terminal device based on zero trust agent includes a processor, a memory, and a computer program stored in the memory and configured to be executed by the processor. When the processor executes the computer program, the single sign-on method based on zero trust agent of any embodiment of the present application is implemented.

[0100] Exemplarily, in this embodiment, the computer program may be divided into one or more modules, and the one or more modules are stored in the memory and executed by the processor to complete the present application. The one or more modules may be a series of computer program instruction segments capable of completing specific functions, and the instruction segments are used to describe the execution process of the computer program in the single sign-on device based on the zero trust agent.

[0101] The zero-trust agent-based single sign-on device can be a computing device such as a desktop computer, a notebook, a PDA, a cloud server, etc. The zero-trust agent-based single sign-on terminal device can include, but is not limited to, a processor and a memory.

[0102] The processor may be a central processing unit (CPU), or other general-purpose processors, digital signal processors (DSP), application-specific integrated circuits (ASIC), field-programmable gate arrays (FPGA) or other programmable logic devices, discrete gates or transistor logic devices, discrete hardware components, etc. The general-purpose processor may be a microprocessor or any conventional processor, etc. The processor is the control center of the zero-trust agent-based single sign-on device, and uses various interfaces and lines to connect the various parts of the entire zero-trust agent-based single sign-on device. The memory may be used to store the computer program and / or module, and the processor implements various functions of the zero-trust agent-based single sign-on device by running or executing the computer program and / or module stored in the memory, and calling the data stored in the memory. The memory may mainly include a program storage area and a data storage area, wherein the program storage area may store an operating system, a first application required for at least one function, etc.; the data storage area may store data created according to the use of the mobile phone, etc. In addition, the memory may include a high-speed random access memory, and may also include a non-volatile memory, such as a hard disk, a memory, a plug-in hard disk, a smart memory card (Smart Med ia Card, SMC), a secure digital (Secure Digital, SD) card, a flash card (Flash Card), at least one disk storage device, a flash memory device, or other volatile solid-state storage devices.

[0103] Embodiment 4

[0104] Based on the above-mentioned embodiment of the single sign-on method based on zero trust agent, another embodiment of the present application provides a storage medium, which includes a stored computer program, wherein when the computer program is running, the device where the storage medium is located is controlled to execute the single sign-on method based on zero trust agent of any embodiment of the present application.

[0105] In this embodiment, the storage medium is a computer-readable storage medium, and the computer program includes computer program code, which may be in source code form, object code form, executable file or some intermediate form, etc. The computer-readable medium may include: any entity or device capable of carrying the computer program code, recording medium, USB flash drive, mobile hard disk, magnetic disk, optical disk, computer memory, read-only memory (ROM), random access memory (RAM), electric carrier signal, telecommunication signal and software distribution medium, etc. It should be noted that the content contained in the computer-readable medium may be appropriately increased or decreased according to the requirements of legislation and patent practice in the jurisdiction. For example, in some jurisdictions, according to legislation and patent practice, computer-readable media do not include electric carrier signals and telecommunication signals.

[0106] The specific embodiments described above further describe the purpose, technical solutions and beneficial effects of the present application in detail. It should be understood that the above description is only a specific embodiment of the present application and is not intended to limit the scope of protection of the present application. It is particularly pointed out that for those skilled in the art, any modification, equivalent replacement, improvement, etc. made within the spirit and principle of the present application should be included in the scope of protection of the present application.

Claims

1. A single sign-on method based on zero trust agent, characterized in that: include: Responding to the permission authentication request sent by the first application, and obtaining a corresponding application token through the permission service according to the permission authentication request; The permission authentication request includes: a user token; the user token is obtained by responding to the first identity authentication request of the user terminal logging into the first application; The application token is returned to the first application, so that the first application obtains the permission to use the first application from the permission service according to the application token, and sends the application token to the security risk control service for real-time risk management and control.

2. A single sign-on method based on zero trust agent as claimed in claim 1, characterized in that: The responding to the permission authentication request sent by the first application and obtaining a corresponding application token through the permission service according to the permission authentication request includes: The permission authentication request further includes: an application identifier; the permission authentication request is generated when the user terminal sends the user token to the first application; the application identifier is an identifier corresponding to the first application; Sending the user token to the permission service, so that the permission service returns a list of accessible applications according to the user token; When the application identifier exists in the accessible application list, the corresponding application token is generated.

3. A single sign-on method based on zero trust agent as claimed in claim 1, characterized in that: The user token is obtained by responding to a first identity authentication request of a user terminal logging into the first application, including: Responding to the identity authentication request of the user terminal, generating a corresponding user token according to the identity authentication request, and sending the user token to the security risk control service for real-time risk management; The user token is returned to the user terminal.

4. A single sign-on method based on zero trust agent as claimed in claim 3, characterized in that: The real-time risk management and control includes: When responding to an identity authentication request or a permission authentication request of the user terminal, obtaining a risk level updated by the security risk control service according to the user token or the application token of the user terminal and the device information of the user terminal; the device information of the user terminal is collected and obtained in real time by the security risk control service in response to the identity authentication request of the user terminal; According to the risk level, restricting operations on the user token or the application token; When the state of the user token or the application token changes, the token with the changed state is sent to the authority service.

5. A single sign-on method based on zero trust agent as claimed in claim 1, characterized in that: The returning the application token to the first application so that the first application obtains the first application use permission from the permission service according to the application token includes: After the corresponding application token is obtained through the permission service, the application token is sent to the permission service, so that the permission service verifies the application token pushed by the first application and returns the corresponding first application usage permission.

6. A single sign-on device based on zero-trust agent, characterized in that: include: An application token generation module and a first application usage permission acquisition module; The application token generation module is used to respond to the permission authentication request sent by the first application, and obtain the corresponding application token through the permission service according to the permission authentication request; the permission authentication request includes: a user token and an application identifier; the user token is obtained by responding to the first identity authentication request of the user terminal that logs in to the first application; the application identifier is the identifier corresponding to the first application; The first application usage permission acquisition module is used to return the application token to the first application, so that the first application obtains the first application usage permission from the permission service according to the application token, and sends the application token to the security risk control service for real-time risk management.

7. A single sign-on device based on zero trust agent as claimed in claim 6, characterized in that: The responding to the permission authentication request sent by the first application and obtaining a corresponding application token through the permission service according to the permission authentication request includes: The permission authentication request is generated by the user terminal sending the user token to the first application; Sending the user token to the permission service, so that the permission service returns a list of accessible applications according to the user token; When the application identifier exists in the accessible application list, the corresponding application token is generated.

8. A single sign-on device based on zero trust agent as claimed in claim 6, characterized in that: The user token is obtained by responding to a first identity authentication request of a user terminal logging into the first application, including: Responding to the identity authentication request of the user terminal, generating a corresponding user token according to the identity authentication request, and sending the user token to the security risk control service for real-time risk management; The user token is returned to the user terminal.

9. A single sign-on device based on zero trust agent as claimed in claim 8, characterized in that: The real-time risk management and control includes: When responding to an identity authentication request or a permission authentication request of the user terminal, obtaining a risk level updated by the security risk control service according to the user token or the application token of the user terminal and the device information of the user terminal; the device information of the user terminal is collected and obtained in real time by the security risk control service in response to the identity authentication request of the user terminal; According to the risk level, restricting operations on the user token or the application token; When the state of the user token or the application token changes, the token with the changed state is sent to the authority service.

10. A single sign-on device based on zero trust agent as claimed in claim 6, characterized in that: The returning the application token to the first application so that the first application obtains the first application use permission from the permission service according to the application token includes: After the corresponding application token is obtained through the permission service, the application token is sent to the permission service, so that the permission service verifies the application token pushed by the first application and returns the corresponding first application usage permission.

Images