Authority management method, apparatus, storage medium, and electronic device

Abstract

This application discloses a permission management method, apparatus, storage medium, and electronic device. The method includes: responding to an authentication request from a client to obtain a first account, the first account being used to identify the client's identity in the permission management server; requesting an account association from an identity authentication server, the identity authentication server being used to generate a second account based on the first account and establish an association between the first account and the second account, the second account being an authorization identifier of the client obtained based on a preset authorization standard; and responding to successful account association, providing a permission management service based on a passwordless access token, the passwordless access token including the second account. This application can unify access standards, achieve unified authorization and unified authentication, and simplify the complex processes and authorization procedures for complex application integration in a hybrid cloud environment.

Description

Technical Field

[0001] This application relates to the field of computer technology, and in particular to permission management methods, devices, storage media and electronic devices. Background Technology

[0002] Software as a Service (SaaS) is a relatively new service delivery model. Service providers build all the necessary network infrastructure, software, and hardware operating platforms for users' IT needs, and are responsible for all pre-implementation and post-maintenance services. Users simply purchase the service and enjoy it via the internet without worrying about maintenance or operational details, significantly reducing user costs. However, platforms providing SaaS transactions face challenges such as complex authorization and authentication processes, making it difficult to provide fine-grained access control and significantly hindering the widespread adoption of SaaS. Summary of the Invention

[0003] In order to reduce the complexity of authentication and authorization processes on software service transaction platforms and provide users with fine-grained permission management, embodiments of this application provide permission management methods, devices, storage media, and electronic devices.

[0004] On one hand, embodiments of this application provide a permission management method applied to a permission management server, the method comprising:

[0005] In response to an authentication request from the client, a first account is obtained, which is used to identify the client's identity in the permission management server;

[0006] The system requests account association from the identity authentication server, which generates a second account based on the first account and establishes an association between the first account and the second account. The second account is the authorization identifier of the client obtained based on a preset authorization standard.

[0007] In response to the successful establishment of the account association, a permission management service based on a passwordless access token is provided, wherein the passwordless access token includes the second account.

[0008] On the other hand, embodiments of this application provide a permission management device applied to a permission management server, the device comprising:

[0009] The authentication request acquisition module is used to obtain a first account in response to an authentication request sent by the client. The first account is used to identify the client's identity in the permission management server.

[0010] The association establishment module is used to request account association from the identity authentication server. The identity authentication server is used to generate a second account based on the first account and establish an association relationship between the first account and the second account. The second account is the authorization identifier of the client obtained based on a preset authorization standard.

[0011] The access control service module is used to provide access control services based on passwordless access tokens in response to the successful establishment of the account association, wherein the passwordless access tokens include the second account.

[0012] On the other hand, embodiments of this application provide a computer-readable storage medium storing at least one instruction or at least one program, wherein the at least one instruction or at least one program is loaded and executed by a processor to implement the above-described permission management method.

[0013] On the other hand, embodiments of this application provide an electronic device, including at least one processor and a memory communicatively connected to the at least one processor; wherein the memory stores instructions executable by the at least one processor, and the at least one processor implements the above-mentioned permission management method by executing the instructions stored in the memory.

[0014] On the other hand, embodiments of this application provide a computer program product, including a computer program or instructions, which, when executed by a processor, implements the aforementioned permission management method.

[0015] The access control method provided in this application enables passwordless access between different SaaS applications. The passwordless access information carries a passwordless access token, which third-party SaaS applications can use for identity verification. Based on the OIDC protocol, the passwordless access token allows for a unified access standard. Different service providers can achieve unified authorization and authentication as long as they interface according to the standard. This simplifies the complex processes and authorization procedures for connecting complex applications in a hybrid cloud environment. Attached Figure Description

[0016] To more clearly illustrate the technical solutions and advantages in the embodiments of this application or related technologies, the drawings used in the description of the embodiments or related technologies will be briefly introduced below. Obviously, the drawings described below are only some embodiments of the embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0017] Figure 1 This is a schematic diagram of the OIDC workflow provided in the embodiments of this specification;

[0018] Figure 2 This is a schematic diagram of the cloud service framework provided in the embodiments of this specification;

[0019] Figure 3 This is a flowchart illustrating a permission management method provided in an embodiment of this application;

[0020] Figure 4 This is a schematic diagram of the authentication process flow provided in the embodiments of this application;

[0021] Figure 5 This is a schematic diagram of the purchasing process provided in an embodiment of this application;

[0022] Figure 6 This is a schematic diagram of the access service process provided in the embodiments of this application;

[0023] Figure 7 This is a schematic diagram of the verification process flow provided in the embodiments of this application;

[0024] Figure 8 This is a block diagram of the access control device provided in the embodiments of this application;

[0025] Figure 9 This is a schematic diagram of the hardware structure of a device for implementing the method provided in the embodiments of this application. Detailed Implementation

[0026] The technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the embodiments of this application, and not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those of ordinary skill in the art without creative effort are within the protection scope of the embodiments of this application.

[0027] It should be noted that the terms "first," "second," etc., in the specification, claims, and accompanying drawings of the embodiments of this application are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that embodiments of the present application described herein can be implemented in orders other than those illustrated or described herein. Furthermore, the terms "comprising" and "having," and any variations thereof, are intended to cover non-exclusive inclusion; for example, a process, method, system, product, or server that includes a series of steps or units is not necessarily limited to those steps or units explicitly listed, but may include other steps or units not explicitly listed or inherent to these processes, methods, products, or devices.

[0028] To make the objectives, technical solutions, and advantages disclosed in the embodiments of this application clearer, the embodiments of this application will be further described in detail below with reference to the accompanying drawings and examples. It should be understood that the specific embodiments described herein are merely illustrative of the embodiments of this application and are not intended to limit the embodiments of this application.

[0029] Hereinafter, the terms "first" and "second" are used for descriptive purposes only and should not be construed as indicating or implying relative importance or implicitly specifying the number of indicated technical features. Therefore, a feature defined as "first" or "second" may explicitly or implicitly include one or more of that feature. In the description of this embodiment, unless otherwise stated, "multiple" means two or more. To facilitate understanding of the above-described technical solutions and their resulting technical effects in the embodiments of this application, the embodiments of this application first explain the relevant technical terms:

[0030] Cloud technology refers to a hosting technology that unifies hardware, software, and network resources within a wide area network (WAN) or local area network (LAN) to achieve data computation, storage, processing, and sharing. It encompasses network technologies, information technologies, integration technologies, management platform technologies, and application technologies based on cloud computing business models. These technologies can form resource pools, allowing for flexible and convenient on-demand use. Cloud computing technology will become a crucial support. Backend services of technical network systems require substantial computing and storage resources, such as video websites, image websites, and many portal websites. With the rapid development and application of the internet industry, every item may have its own identification mark in the future, requiring transmission to backend systems for logical processing. Data at different levels will be processed separately, and various industry data will require robust system support, which can only be achieved through cloud computing.

[0031] Software as a Service (SaaS). A SaaS platform is a platform for operating SaaS software. SaaS providers build all the network infrastructure and software / hardware operating platforms needed for enterprise IT infrastructure, and are responsible for all pre-implementation and post-maintenance services. Enterprises can use information systems via the internet without purchasing hardware and software, building server rooms, or hiring computer professionals. SaaS is a software deployment model whose applications are designed for network delivery, facilitating hosting, deployment, and access by users via the internet.

[0032] SaaS Applications: SaaS applications are a model of software delivered over the web. Users no longer need to purchase software, but instead rent web-based software from a provider to manage their business operations. Furthermore, users do not need to maintain the software, as the service provider manages and maintains the software entirely.

[0033] OAuth: Open Authorization. The OAuth protocol provides a secure, open, and simple standard for authorizing user resources. Unlike previous authorization methods, OAuth authorization does not allow third parties to access the user's account information (such as username and password). In other words, third parties can request authorization for the user's resources without using the user's username and password, therefore OAuth is secure.

[0034] OIDC: OpenID Connect, which builds an identity layer on top of OAuth2.0, is an identity authentication standard protocol based on the OAuth2.0 protocol. OIDC uses the OAuth2.0 authorization server to provide user authentication for third-party clients and passes the corresponding authentication information to the clients.

[0035] IDaaS (Identity as a Service) is a trusted identity authentication service that provides enterprises with unified and efficient identity management. IDaaS supports centralized management of enterprise user identities and authentication methods, enabling a single account to access all application services. Users only need to authenticate once to log in to all applications and systems within their authorized scope without a password. User login and access behavior can also be monitored uniformly, greatly improving enterprise management efficiency and reducing maintenance costs.

[0036] Password-free mode SsoUrl: The password-free SsoUrl address relies on the IDaaS unified authorization center. After purchasing the application, the service provider provides the login address information. Users can access the purchased SaaS service through the SsoUrl without password verification.

[0037] JWT: JSON Web Token, is an open standard based on JSON for transmitting claims between web application environments. A JWT consists of three parts: a header, a payload, and a signature.

[0038] Related technologies offer solutions for passwordless access, with OAuth 2.0 being a particularly effective one. OAuth 2.0's main function is to grant a user's permission for a service provider to send a token to a third party. OAuth 2.0 is an authorization mechanism where the service provider authorizes a third party, generating a short-term access token, granting the third-party application permission to access the system. When accessing the system, the third party carries this token. The system verifies the token's validity with the resource server; if verification is successful, service access is granted. OAuth 2.0 comprehensively solves the trust issue among the user, service provider, and third party during a service transaction. Through the token, mutual trust and passwordless access are achieved.

[0039] However, while the OAuth 2.0 authorization mechanism can implement the authorization process, it is an authorization protocol and cannot provide comprehensive identity authentication functionality, making it difficult to apply to scenarios requiring more granular authorization and authentication. For example, in a hybrid cloud scenario, not only are multi-tenant relationships involved, but also complex multi-account authorization issues may arise. Specifically, in a hybrid cloud scenario, there may be a main enterprise account and sub-accounts, with the main account potentially having many sub-accounts. The main account can authorize some sub-accounts to access SaaS services. However, if OAuth 2.0 is followed, all main and sub-accounts share the same token, making user identity recognition and authentication impossible, and failing to achieve permission isolation and access control. Any user who obtains the token can enjoy the same services.

[0040] To achieve more granular access control, this application provides an access control method. This method enables account-level authorization and authentication, optimizes information exchange in the access control process based on the OAuth protocol, relies on an OAuth authorization server as a trusted third party, and combines account information to provide account-level identity authentication services, managing access based on the authentication results. This application not only manages account access in complex situations but is also fully compatible with related technical solutions built on the OAuth protocol, providing users with more granular access control services. This application can be applied to various cloud environments, especially hybrid cloud scenarios.

[0041] The permission management method provided in this application embodiment can be implemented based on the OAuth protocol or the OAuth 2.0 protocol. OAuth is an open standard that allows users to authorize third-party mobile applications to access information they store on another service provider without having to provide their username and password to the third-party mobile application or share all of their data. OAuth 2.0 is a continuation of the OAuth protocol.

[0042] OAuth 2.0 provides Access Tokens to address the issue of authorizing third-party clients to access protected resources; OIDC, building upon this, provides ID Tokens to address the issue of third-party client authentication of user identities. The core of OIDC lies in providing the user's authentication information (ID Token) to the third-party client within the OAuth 2.0 authorization process. The ID Token is packaged in JWT format, and thanks to JWT's self-containment, compactness, and tamper-proof mechanism, it can be securely transmitted to third-party client programs and is easily verified. Simultaneously, the OIDC service can also provide an interface for UserInfo, allowing users to obtain more complete user information. The OIDC protocol's main constituent terms include:

[0043] EU: End User, a human user, which in this application embodiment can be understood as the account corresponding to the user.

[0044] RP: Relying Party, used to refer to the trusted client in OAuth 2.0, the consumer of authentication and authorization information;

[0045] OP: OpenID Provider, capable of providing EU authentication services (such as the authorization service in OAuth2.0) to provide EU identity authentication information for RP;

[0046] ID Token: Data in JWT format containing EU identity authentication information.

[0047] UserInfo Endpoint: User information interface (protected by OAuth 2.0).

[0048] When the RP accesses the interface using an Access Token, it returns information about the authorized user. This interface must use HTTPS. HTTPS stands for Hyper Text Transfer Protocol over SecureSocket Layer, which is a Hyper Text Transfer Protocol (HTTP) channel designed for security. It ensures the security of the transmission process through transmission encryption and authentication on top of HTTP.

[0049] Please refer to Figure 1 The OIDC workflow involves interactions between three entities: EU, RP, and OP, and includes the following steps:

[0050] (1) The trusted client publishes an authentication request (AuthN Request), where AuthN stands for Authentication;

[0051] (2) The authentication provider authorizes the user account.

[0052] (3) The authentication provider sends an authentication response (AuthN Response) to the trusted client. Specifically, the OP returns the IDToken and Access Token (if required) to the RP.

[0053] (4) The trusted client sends a UserInfo Request to the authentication provider.

[0054] (5) The authentication provider provides a user information response.

[0055] The RP sends a request for a UserInfo Endpoint using an Access Token; the UserInfo Endpoint returns the EU's Claims (authorization information). The most significant extension of OIDC to OAuth2 is the provision of the ID Token. The ID Token is a security token, a JWT-formatted data structure provided by an authorization server containing user information (consisting of a set of Claims and other auxiliary Claims). It follows the standard JWT format. Once the service receives the ID Token, it can perform JWT verification and parsing to retrieve the account data information within the JWT.

[0056] The methods provided in this application embodiment may involve blockchain, meaning that the methods provided in this application embodiment can be implemented based on blockchain, or the data involved in the methods provided in this application embodiment can be stored based on blockchain, or the executing entity of the methods provided in this application embodiment can be located in blockchain. Blockchain is a new application model of computer technologies such as distributed data storage, peer-to-peer transmission, consensus mechanisms, and encryption algorithms. Essentially, a blockchain is a decentralized database, a chain of data blocks linked using cryptographic methods. Each data block contains information about a batch of network transactions, used to verify the validity of the information (anti-counterfeiting) and generate the next block. A blockchain may include a blockchain underlying platform, a platform product service layer, and an application service layer.

[0057] The underlying blockchain platform can include processing modules such as user management, basic services, smart contracts, and operational monitoring. The user management module is responsible for managing the identity information of all blockchain participants, including maintaining public and private key generation (account management), key management, and maintaining the correspondence between user real identities and blockchain addresses (access management). Furthermore, under authorization, it monitors and audits transactions of certain real identities and provides risk control rule configuration (risk control audit). The basic services module is deployed on all blockchain node devices to verify the validity of business requests. After consensus is reached on valid requests, they are recorded in storage. For a new business request, the basic services first perform interface adaptation parsing and authentication (interface adaptation), and then encrypt the business information through a consensus algorithm (consensus management). The encryption process ensures that the encrypted data is transmitted completely and consistently to the shared ledger (network communication) and recorded and stored. The smart contract module is responsible for contract registration, issuance, triggering, and execution. Developers can define contract logic using a programming language and publish it to the blockchain (contract registration). Based on the contract terms, the module calls keys or other events to trigger execution and complete the contract logic. It also provides functions for contract upgrades and cancellations. The operation monitoring module is mainly responsible for deployment, configuration modification, contract settings, cloud adaptation, and real-time visualization of the product's running status during product release, such as alarms, monitoring network conditions, and monitoring the health status of node devices.

[0058] The platform's product service layer provides the basic capabilities and implementation frameworks for typical applications. Developers can leverage these basic capabilities, along with the specific characteristics of their business needs, to implement blockchain-based business logic. The application service layer provides blockchain-based application services to business stakeholders.

[0059] This application's embodiments can be applied to public cloud, private cloud, or hybrid cloud scenarios. A private cloud is created within a firewall, housing cloud infrastructure and hardware / software resources for various departments within an organization or enterprise to share resources within a data center. Creating a private cloud typically involves cloud equipment (IaaS, Infrastructure as a Service) software, in addition to hardware resources. Private cloud computing also comprises three layers: cloud hardware, cloud platform, and cloud services. The difference is that cloud hardware consists of the user's own personal computer or server, rather than the cloud computing vendor's data center. Cloud computing vendors build data centers to provide public cloud services to millions of users, thus requiring hundreds of thousands or even millions of servers. For individuals, private cloud computing only serves close friends and family; for enterprises, it only serves their own employees, customers, and suppliers. Therefore, the personal computers or servers of individuals or enterprises are sufficient to provide cloud services.

[0060] Public cloud typically refers to a cloud service provided by a third-party provider to users. Public clouds are generally accessible via the Internet and may be free or inexpensive. The core attribute of a public cloud is shared resource services. Many instances of this type of cloud exist, providing services across today's open public networks.

[0061] Hybrid cloud, which combines public cloud and private cloud, has become a major model and development direction of cloud computing in recent years. Private cloud primarily targets enterprise users; for security reasons, enterprises prefer to store data in private clouds, but at the same time, they also want access to the computing resources of public clouds. Hybrid cloud is increasingly adopted in this context, combining and matching public and private clouds to achieve optimal results. This personalized solution achieves both cost-effectiveness and security.

[0062] Public clouds, private clouds, or hybrid clouds can all be used to deploy various applications. Applications published, sold, or operated through public clouds, private clouds, or hybrid clouds are called cloud applications. This application's embodiments are not limited to the fields related to cloud applications; for example, they may involve cloud IoT, cloud calling, cloud security, cloud social networking, cloud healthcare, cloud computing, cloud storage, etc.

[0063] In one embodiment, this application can be applied to a cloud service framework, the architecture of which is shown in the figure below. Figure 2 As shown, the cloud service framework includes a billing module, an application module, a permission management module, and an account management module.

[0064] The account management module includes an account center, a permission center, and an IdaaS information center. The account center is responsible for basic operations such as user account information, login management, user registration, and activation. The permission center is responsible for the permission system management of the hybrid cloud platform. The IdaaS information center is used to bind the association between the SaaS applications purchased by the user and the account, including the associated application information Application ID and public key certificate, which are used for user login authorization operations.

[0065] The billing module comprises several core functions: a billing center, an order center, and payment management. The order center handles the entire application purchase process for an account, including order placement, payment, instance delivery notification, refunds, and cloud marketplace integration. Users associated with an account browse applications through the product center in the application module, click to purchase, place an order through the order center, make payment, and upon successful payment, the order notification center handles the delivery logic. The billing center manages the billing information after a user pays for an order.

[0066] The application module is responsible for the unified management and configuration of goods from various sources, including a product center, instance center, and access center. This product can be a SaaS application. In this embodiment, if the goods originate from different clouds, the aforementioned cloud service framework is a hybrid cloud framework. The scenarios involving goods in the product center include importing from the cloud, reviewing, listing, delisting, and selling, all of which involve the participation of the aforementioned product center. Goods can be listed via public or private clouds; that is, the aforementioned hybrid cloud framework can provide a unified product listing interface for both private and public clouds. The product center also provides services for product information display and maintenance, and is a key link in the entire product information maintenance process, achieving unified maintenance of product information for public and private cloud goods.

[0067] The Instance Center is responsible for managing application instance information after a user purchases a SaaS application. This includes instance management, covering basic information such as instance details, access address, and expiration date. It serves as the entry point for users to access and purchase SaaS applications. In a hybrid cloud environment, it connects with cloud marketplaces and service providers. The Instance Center controls the lifecycle of purchased SaaS products, including instance delivery, renewal, expiration, configuration upgrades, and shutdown. The Instance Center handles all subsequent processes after purchase, making it a core component of the product delivery process.

[0068] The access center is responsible for connecting with public and private cloud service providers, streamlining delivery integration, interface verification, data integration, and information synchronization. As a management center in a hybrid cloud scenario, the access center handles functional integration, primarily connecting with local service providers (ISVs) for the entire process of service activation, renewal, upgrade, expiration, and destruction. When an instance center delivers local services, it integrates with the business side, calling the access center. The access center then notifies the service provider to process the delivery, the service provider returns delivery information, the instance center verifies the delivery information, and returns the final delivery result, completing the entire delivery process.

[0069] The access control module provides enterprises with unified and efficient identity management services. Unlike the traditional model of multiple systems maintaining different user information and distributed identity authentication, the access control module supports centralized management of enterprise user identities and authentication methods, enabling a single account to access all application services. Users only need to authenticate once to log in to all applications and systems within their authorized scope without a password. User login and access behavior can also be monitored uniformly, greatly improving enterprise management efficiency and reducing maintenance costs. IDaaS, based on the OIDC protocol, can not only perform service authorization but also service authentication, meeting both passwordless and security requirements during passwordless login.

[0070] In this application embodiment, the SaaS application sources include public cloud and private cloud. For public cloud and private cloud SaaS products, they can be provided by third-party SaaS services. The providers of third-party services are collectively referred to as service providers (ISVs). The services purchased by users may be self-developed applications or they may come from relevant service providers. Service providers need to complete the entire delivery integration in accordance with the framework standards of this application embodiment. At the same time, based on the OIDC protocol, they need to verify and decode account information, identify account identity, and provide corresponding services for the account.

[0071] The following describes a permission management method according to an embodiment of this application. Figure 3 This document illustrates a flowchart of a permission management method provided by an embodiment of this application. The embodiment provides the method operation steps described in the embodiments or flowchart, but based on conventional or non-inventive methods, more or fewer operation steps may be included. The order of steps listed in the embodiments is merely one possible execution order among many and does not represent the only possible execution order. In actual systems, terminal devices, or server products, the method can be executed sequentially according to the embodiments or accompanying drawings, or in parallel (e.g., in a parallel processor or multi-threaded processing environment). The above method may include:

[0072] S101. In response to the authentication request sent by the client, a first account is obtained, wherein the first account is used to identify the identity of the client in the permission management server.

[0073] In this application embodiment, the permission management server can be the permission center and permission management module in the aforementioned cloud service framework. The permission center can provide services to users in the form of a website. Users can trigger the aforementioned authentication request by logging into the URL corresponding to the permission center. The authentication request can include basic information required for authentication, such as user nickname, user identifier, and user password. This application does not limit the information carried in the authentication request.

[0074] S102. Request an account association from the identity authentication server. The identity authentication server is used to generate a second account based on the first account and establish an association between the first account and the second account. The second account is the authorization identifier of the client obtained based on a preset authorization standard.

[0075] The identity authentication server in this embodiment can be the IdaaS information center of the aforementioned cloud service framework, which is built based on OIDC. The preset authorization standard can be OAuth or OAuth 2.0. The identity authentication server is used to provide users with trusted identity information authentication services. In subsequent permission processing, the permission management server can interact with the application service provider based on a second account, thereby hiding the information corresponding to the first account and achieving the technical effect of information security. Furthermore, different application service providers serving the same client can provide services based on the passwordless access tokens provided by the IdaaS information center, thereby achieving the technical effect of one-click connection of the interaction process of various application services.

[0076] S103. In response to the successful establishment of the aforementioned account association, provide access control services based on a passwordless access token, wherein the passwordless access token includes the aforementioned second account.

[0077] Specifically, please refer to Figure 4 The certification process includes the following steps:

[0078] S1. Request authentication from the access control server.

[0079] S2. In response to successful authentication, the access control server requests the aforementioned identity authentication server to enable trusted identity authentication service.

[0080] S3. The aforementioned identity authentication server creates and reports the aforementioned second account, and reports the second account to the permission management server.

[0081] S4. The permission management server creates application information and the first account, and sends them to the identity authentication server. This application information represents basic information generated for the purpose of purchasing an application. Specifically, this application information can be understood as pre-set information for purchasing an application, such as pre-set empty fields like application identifier and application description information. During the user's application service purchase process, this application information is updated based on the user's actual purchase, thus improving the speed of the entire transaction process.

[0082] S5. The identity authentication server updates the information.

[0083] The above-mentioned request to the identity authentication server for account association includes: transmitting the above-mentioned application information and the above-mentioned first account to the above-mentioned identity authentication server to trigger the above-mentioned identity authentication server to update the above-mentioned application information; and receiving the above-mentioned application information and public key information fed back by the above-mentioned identity authentication server if the account association is successful.

[0084] S6. Under the verified Qin Guang, the client performs sub-account verification.

[0085] When a user registers an account, the permission management server creates a corresponding tenant account (second account) on the identity authentication server side. At the same time, it creates application information under the tenant to bind the corresponding service instance to the second account when the user purchases SaaS services. Of course, this information can also be updated to the permission management server.

[0086] In enterprise access control scenarios, the above embodiments illustrate the authentication process for an enterprise administrator's client. Other enterprise users can also refer to the preceding description to establish a binding relationship with the aforementioned second account. The enterprise administrator serves as the primary account, and other enterprise users serve as sub-accounts. Sub-accounts can request authentication from the identity authentication server by carrying the primary account information, thereby binding their own accounts with the aforementioned second account and enabling one-click passwordless access with the support of the identity authentication server. The aforementioned second account can correspond to the primary account and at least one sub-account, and in subsequent scenarios involving the consumption of target application services, it provides corresponding passwordless one-click access support for each account. In other words, this application can provide authorization and authentication services at a multi-level account granularity.

[0087] In one embodiment, the access control server can also, upon successful account association, respond to the purchase of a target application service by obtaining the order information corresponding to that target application service; updating the application information based on the order information; and providing a purchase service for the target application service based on the updated application information, the public key information, and the second account. Specifically, application information can be obtained by interacting with an app store, where the app store is... Figure 2 Services provided by the product center within the Zhongyun service framework. The updated application information may include the application identifier of that application in the identity authentication server.

[0088] The access control server can generate a purchase request based on the updated application information, the public key information (certification), the second account, and the preset verification information. The purchase request is then sent to the application server. The preset verification information is used to verify the legitimacy of the access control server. The application server is used to provide the target application service to trigger the application server to create a third account and establish an association between the information in the purchase request and the third account. The third account is the user's identity information when consuming the target application service.

[0089] Upon successful purchase, the system retrieves purchase information from the application server, including the target address (ssoURL) and target instance identifier (signID) corresponding to the target application service. A purchase information update request is then sent to the authentication server to trigger the establishment of an association between the second account and the purchase information. Alternatively, the user can authorize other users to consume the purchased target application service; this is achieved by associating those other users with the second account corresponding to the first user.

[0090] Please refer to the preceding text. Figure 5 It illustrates the purchase process. Specifically, it includes the following steps:

[0091] S10. The client purchases SaaS applications from the access control server.

[0092] S20. The access control server purchases SaaS applications from the application marketplace.

[0093] S30. The app store sends a notification to the permission management server that the order has been placed and the purchase was successful.

[0094] S40. The access control server updates the application information to the identity authentication server, and carries the authentication information.

[0095] S50. The identity authentication server sends out application information, along with authentication information.

[0096] S60. The access control server sends a delivery notification to the SaaS service provider (preset verification information, applicationId, public key).

[0097] The S70.SaaS service provider platform updated its information and reported successful delivery.

[0098] S80. The permission management server associates applications.

[0099] S90. The client requests authorization and receives an authorization response.

[0100] In one embodiment, the above method further includes:

[0101] In response to a request to consume the aforementioned target application service, the access control server queries the identity authentication server for a passwordless access token (id_token) based on the first account and the application information. This triggers the identity authentication server to generate a passwordless access token based on the first account, the second account, and the target instance identifier. Furthermore, it generates an access address based on the target address and the passwordless access token, linking to the target application service corresponding to that access address.

[0102] Specifically, the above-mentioned method of generating an access address based on the target address and the passwordless access token, and linking to the target application service corresponding to the access address, includes: encrypting the passwordless access token to obtain an encryption result; generating the access address based on the target address and the encryption result; redirecting to the access address to trigger the application server to decrypt the encryption result to obtain a decryption result; and verifying the decryption result, and providing the target application service if the verification is successful.

[0103] Please refer to the preceding text. Figure 6 It shows a schematic diagram of the access service process, which specifically includes the following steps:

[0104] S100. Password-free login for purchased SaaS applications.

[0105] S200. Redirect to query the association between the first account, the second account, and application information.

[0106] S300. Verify the generated token.

[0107] S400. Redirect to the service address, which can be expressed as ssoUrl+id_token, where the token contains applicationId and UserId.

[0108] S500. Access service address.

[0109] S600. The app store parses the id_token and verifies it. If the verification is successful, the service is allowed.

[0110] In one embodiment, the verification includes the following steps: parsing to obtain the application information to be verified and the second account to be verified; querying the corresponding public key information based on the application information to be verified; verifying the legitimacy of the passwordless access token based on the public key information; querying the legitimacy of the second account to be verified in response to successful verification; and determining that the verification is successful in response to the legitimacy of the second account to be verified.

[0111] like Figure 7As shown, the encrypted result includes the target address and a passwordless access token. The passwordless access token can be parsed using JWT for verification. Specifically, the verification process involves base64 decoding of the `id_token`'s payload to obtain the application information and the second account to be verified. Base64 is a common encoding method used on the internet for transmitting 8-bit byte code; it's a method of representing binary data using 64 printable characters.

[0112] This application's embodiments are particularly suitable for use in hybrid cloud scenarios, which involve not only multiple accounts but also situations where one account is associated with multiple accounts. This application's embodiments can leverage the IDaaS service based on the OIDC protocol to implement SaaS application authorization, resolving the issues of SaaS application authorization, authentication, and identity recognition in public cloud, private cloud, and hybrid cloud scenarios. It integrates with hybrid cloud platform accounts, enabling passwordless login. Users only need to log in to the cloud platform once to achieve passwordless access between different SaaS applications. The passwordless information carries an id_token, which third-party SaaS applications can use for identity verification. Based on the OIDC protocol's id_token, a unified access standard can be established. Different service providers can achieve unified authorization and authentication as long as they interface according to the standard. This simplifies the complex processes and authorization procedures for connecting complex applications in a hybrid cloud environment.

[0113] Hybrid cloud, which integrates public and private clouds, represents a major development model and direction for cloud technology. From a user perspective, public cloud caters to individual and enterprise users, while private cloud primarily targets enterprise users, especially large enterprises. These enterprises often prefer the private cloud model while simultaneously seeking access to public cloud SaaS application resources. In this hybrid cloud scenario, customization can be achieved, along with security and cost savings. Hybrid cloud offers numerous advantages to enterprise users, with data security and localization being fundamental requirements. It also includes more robust system construction and greater scalability. As the hybrid cloud model continues to take root, hybrid cloud platforms, combined with public cloud platforms, leverage the rich product features of the public cloud to enjoy abundant public cloud resources, including SaaS services, while also creating locally tailored solutions. Major enterprises are increasingly adopting cloud migration for digital transformation, with traditional applications fully embracing the cloud and receiving SaaS support.

[0114] In a hybrid cloud model, SaaS applications not only originate from selected applications in the public cloud marketplace but also from applications provided by service providers in private cloud environments and enterprise-owned applications. When users purchase SaaS applications through the hybrid cloud platform, they don't need to know whether the application comes from the public or private cloud marketplace. They simply follow the standard purchase process, and the hybrid cloud platform handles the integration with different service providers to process SaaS delivery. Users only need to log in. Accessing the purchased application requires no further login or authorization; they can access it directly via a password-free address.

[0115] This application's embodiments enable SaaS application access and authorization in a hybrid cloud model based on the OIDC protocol's IdaaS. It defines the overall process and standard for service access, service authentication, authorization, and authorization for SaaS services in both public and hybrid cloud scenarios, using the OIDC protocol. In hybrid cloud scenarios, it achieves access and authorization standards for multi-source SaaS applications. Through the OIDC protocol's IdaaS, it uses an OAuth 2.0 authorization server to provide user authentication for third-party clients and transmits the corresponding authentication information to the clients. This is applicable to various types of clients (such as server-side applications, mobile apps, and JS applications) and is fully compatible with OAuth 2.0. For public cloud SaaS application and private cloud SaaS application service providers, they can rely on the OIDC protocol's IdaaS to achieve unified application authorization and authentication standards, eliminating the hassle and inconvenience of repeatedly connecting to different platforms and providing a unified standard. IdaaS, based on the OIDC protocol, enables standardized access and use of SaaS from different sources in a hybrid cloud platform. After users register a cloud platform account and purchase services, the purchased application instances are automatically connected, achieving a passwordless process. Service providers only need to connect according to the id_token verification standard, reducing intrusion into business operations.

[0116] Please refer to Figure 8 This diagram illustrates a block diagram of a permission management device in this embodiment, the device comprising:

[0117] The authentication request acquisition module 101 is used to obtain a first account in response to the authentication request sent by the client. The first account is used to identify the identity of the client in the permission management server.

[0118] The association establishment module 102 is used to request account association from the identity authentication server. The identity authentication server is used to generate a second account based on the first account and establish an association relationship between the first account and the second account. The second account is the authorization identifier of the client obtained based on a preset authorization standard.

[0119] The permission management service module 103 is used to provide permission management services based on passwordless access tokens in response to the successful establishment of the above account association, wherein the above passwordless access tokens include the above second account.

[0120] In one embodiment, the above-mentioned permission management service module is used to perform the following operations:

[0121] The above response to the authentication request sent by the client yields the first account, including:

[0122] In response to successful authentication, a request is made to the aforementioned identity authentication server to activate the trusted identity authentication service, thereby triggering the aforementioned identity authentication server to create and provide feedback on the aforementioned second account;

[0123] Create application information and a primary account. The aforementioned application information represents the basic information generated for the purpose of purchasing the application.

[0124] The above request to the identity authentication server for account association includes: transmitting the above application information and the above first account to the above identity authentication server to trigger the above identity authentication server to update the above application information;

[0125] If the account is successfully linked, the application information and public key information will be received from the aforementioned identity authentication server.

[0126] In one embodiment, the above-mentioned permission management service module is used to perform the following operations:

[0127] If the account is successfully linked, in response to the purchase of the target application service, the order information corresponding to the target application service will be obtained.

[0128] Update the application information based on the order details above;

[0129] Based on the updated application information, the aforementioned public key information, and the aforementioned second account, a purchase service for the aforementioned target application is provided.

[0130] In one embodiment, the above-mentioned permission management service module is used to perform the following operations:

[0131] Based on the updated application information, the public key information, the second account, and the preset verification information, a purchase request is generated and sent to the application server. The preset verification information is used to verify the legitimacy of the permission management server. The application server is used to provide the target application service to trigger the application server to create a third account and establish the association between the information in the purchase request and the third account. The third account is the user's identity information when consuming the target application service.

[0132] In response to a successful purchase, obtain the purchase information returned by the application server, which includes the target address and target instance identifier corresponding to the target application service.

[0133] Send a purchase information update request to the aforementioned identity authentication server to trigger the aforementioned identity authentication server to establish an association between the aforementioned second account and the aforementioned purchase information.

[0134] In one embodiment, the above-mentioned permission management service module is used to perform the following operations:

[0135] In response to the request to consume the aforementioned target application service, the system queries the aforementioned identity authentication server for a passwordless access token based on the aforementioned first account and the aforementioned application information, thereby triggering the aforementioned identity authentication server to generate a passwordless access token based on the aforementioned first account, the aforementioned second account, and the aforementioned target instance identifier.

[0136] An access address is generated based on the target address and the passwordless access token, and a link is generated to the target application service corresponding to the access address.

[0137] In one embodiment, the above-mentioned permission management service module is used to perform the following operations:

[0138] The above passwordless access token is encrypted to obtain the encrypted result;

[0139] The above access address is generated based on the above target address and the above encryption result;

[0140] Redirecting to the above access address triggers the application server to decrypt the encryption result, obtain the decryption result, and verify the decryption result. If the verification is successful, the target application service is provided.

[0141] In one embodiment, the above-mentioned permission management service module is used to perform the following operations:

[0142] The parsing process yields the application information to be verified and the second account to be verified.

[0143] Based on the application information to be verified above, query the corresponding public key information;

[0144] The validity of the passwordless access token is verified based on the aforementioned public key information;

[0145] In response to a successful verification, check the legitimacy of the aforementioned second account to be verified;

[0146] In response to the above-mentioned valid status of the second account to be verified, the verification is confirmed to be successful.

[0147] The permission management device and method embodiments provided in this application are based on the same inventive concept and will not be described in detail here.

[0148] Furthermore, Figure 9 A schematic diagram of a hardware structure for implementing the method provided in the embodiments of this application is shown. This device can participate in or include the apparatus or system provided in the embodiments of this application. Figure 9 As shown, device 10 may include one or more processors 102 (shown as 102a, 102b, ..., 102n in the figure) 102 (processor 102 may include, but is not limited to, a microprocessor MCU or a programmable logic device FPGA, etc.), a memory 104 for storing data, and a transmission device 106 for communication functions. In addition, it may also include: a display, an input / output interface (I / O interface), a universal serial bus (USB) port (which may be included as one of the ports of the I / O interface), a network interface, a power supply, and / or a camera. Those skilled in the art will understand that... Figure 9 The structure shown is for illustrative purposes only and does not limit the structure of the electronic device described above. For example, device 10 may also include a... Figure 9 The more or fewer components shown, or having the same Figure 9 The different configurations shown.

[0149] It should be noted that the aforementioned one or more processors 102 and / or other data processing circuits are generally referred to herein as "data processing circuits". These data processing circuits may be embodied, in whole or in part, in software, hardware, firmware, or any other combination thereof. Furthermore, the data processing circuits may be a single, independent processing module, or may be integrated, in whole or in part, into any other element within the device 10 (or mobile device). As involved in the embodiments of this application, the data processing circuits serve as a processor control mechanism (e.g., selection of a variable resistor termination path connected to an interface).

[0150] The memory 104 can be used to store software programs and modules of application software, such as the program instructions / data storage device corresponding to the method described in the embodiments of this application. The processor 102 executes various functional applications and data processing by running the software programs and modules stored in the memory 104, thereby realizing the above-mentioned permission management method. The memory 104 may include high-speed random access memory, and may also include non-volatile memory, such as one or more magnetic storage devices, flash memory, or other non-volatile solid-state memory. In some instances, the memory 104 may further include memory remotely located relative to the processor 102, and these remote memories can be connected to the device 10 via a network. Examples of such networks include, but are not limited to, the Internet, corporate intranets, local area networks, mobile communication networks, and combinations thereof.

[0151] The transmission device 106 is used to receive or send data via a network. Specific examples of the network described above may include a wireless network provided by the communication provider of device 10. In one example, the transmission device 106 includes a Network Interface Controller (NIC), which can connect to other network devices via a base station to communicate with the Internet. In another example, the transmission device 106 may be a radio frequency (RF) module used for wireless communication with the Internet.

[0152] The display may be, for example, a touchscreen liquid crystal display (LCD) that allows a user to interact with the user interface of device 10 (or a mobile device).

[0153] It should be noted that the order of the embodiments described above is merely for descriptive purposes and does not represent the superiority or inferiority of the embodiments. Furthermore, the above description focuses on specific embodiments of this application. Other embodiments are within the scope of the appended claims. In some cases, the actions or steps described in the claims can be performed in a different order than that shown in the embodiments and still achieve the desired result. Additionally, the processes depicted in the drawings do not necessarily require a specific or sequential order to achieve the desired result. In some implementations, multitasking and parallel processing are also possible or may be advantageous.

[0154] The embodiments in this application are described in a progressive manner. Similar or identical parts between embodiments can be referred to mutually. Each embodiment focuses on describing the differences from other embodiments. In particular, the device and server embodiments are basically similar to the method embodiments, so the descriptions are relatively simple; relevant parts can be referred to the descriptions of the method embodiments.

[0155] Those skilled in the art will understand that all or part of the steps of the above embodiments can be implemented by hardware or by a program instructing related hardware. The program can be stored in a computer-readable storage medium, such as a read-only memory, a disk, or an optical disk.

[0156] The instructions in the aforementioned storage medium can execute a permission management method applied to a permission management server, the method including:

[0157] In response to the authentication request sent by the client, a first account is obtained, which is used to identify the client's identity in the permission management server.

[0158] The system requests account association from the identity authentication server, which generates a second account based on the first account and establishes an association between the first account and the second account. The second account is the authorization identifier of the client obtained based on a preset authorization standard.

[0159] In response to the successful establishment of the aforementioned account association, a permission management service based on a passwordless access token is provided, wherein the aforementioned passwordless access token includes the aforementioned second account.

[0160] In one embodiment, obtaining a first account in response to an authentication request from a client includes:

[0161] In response to successful authentication, a request is made to the aforementioned identity authentication server to activate the trusted identity authentication service, thereby triggering the aforementioned identity authentication server to create and provide feedback on the aforementioned second account;

[0162] Create application information and a primary account. The aforementioned application information represents the basic information generated for the purpose of purchasing the application.

[0163] The above request to the identity authentication server for account association includes: transmitting the above application information and the above first account to the above identity authentication server to trigger the above identity authentication server to update the above application information;

[0164] If the account is successfully linked, the application information and public key information will be received from the aforementioned identity authentication server.

[0165] In one embodiment, the above method further includes:

[0166] If the account is successfully linked, in response to the purchase of the target application service, the order information corresponding to the target application service will be obtained.

[0167] Update the application information based on the order details above;

[0168] Based on the updated application information, the aforementioned public key information, and the aforementioned second account, a purchase service for the aforementioned target application is provided.

[0169] In one embodiment, the aforementioned purchase service for the target application service based on the updated application information, the aforementioned public key information, and the aforementioned second account includes:

[0170] Based on the updated application information, the public key information, the second account, and the preset verification information, a purchase request is generated and sent to the application server. The preset verification information is used to verify the legitimacy of the permission management server. The application server is used to provide the target application service to trigger the application server to create a third account and establish the association between the information in the purchase request and the third account. The third account is the user's identity information when consuming the target application service.

[0171] In response to a successful purchase, obtain the purchase information returned by the application server, which includes the target address and target instance identifier corresponding to the target application service.

[0172] Send a purchase information update request to the aforementioned identity authentication server to trigger the aforementioned identity authentication server to establish an association between the aforementioned second account and the aforementioned purchase information.

[0173] In one embodiment, the above method further includes:

[0174] In response to the request to consume the aforementioned target application service, the system queries the aforementioned identity authentication server for a passwordless access token based on the aforementioned first account and the aforementioned application information, thereby triggering the aforementioned identity authentication server to generate a passwordless access token based on the aforementioned first account, the aforementioned second account, and the aforementioned target instance identifier.

[0175] An access address is generated based on the target address and the passwordless access token, and a link is generated to the target application service corresponding to the access address.

[0176] In one embodiment, the above-mentioned generation of an access address based on the target address and the passwordless access token, and linking to the target application service corresponding to the access address, includes:

[0177] The above passwordless access token is encrypted to obtain the encrypted result;

[0178] The above access address is generated based on the above target address and the above encryption result;

[0179] Redirecting to the above access address triggers the application server to decrypt the encryption result, obtain the decryption result, and verify the decryption result. If the verification is successful, the target application service is provided.

[0180] In one embodiment, the above verification includes the following steps:

[0181] The parsing process yields the application information to be verified and the second account to be verified.

[0182] Based on the application information to be verified above, query the corresponding public key information;

[0183] The validity of the passwordless access token is verified based on the aforementioned public key information;

[0184] In response to a successful verification, check the legitimacy of the aforementioned second account to be verified;

[0185] In response to the above-mentioned valid status of the second account to be verified, the verification is confirmed to be successful.

[0186] The above description is only a preferred embodiment of the present application and is not intended to limit the present application. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of the present application should be included within the protection scope of the present application.

Claims

1. A method for managing access permissions, characterized in that, Applied to a permission management server, the method includes: In response to an authentication request from the client, a first account is obtained, which is used to identify the client's identity in the permission management server; The system requests account association from the identity authentication server, which generates a second account based on the first account and establishes an association between the first account and the second account. The second account is the authorization identifier of the client obtained based on a preset authorization standard. In response to the successful establishment of the account association, a permission management service based on a passwordless access token is provided, wherein the passwordless access token includes the second account; The step of obtaining the first account in response to an authentication request from the client includes: In response to successful authentication, a request is made to the identity authentication server to activate the trusted identity authentication service, thereby triggering the identity authentication server to create and respond to the second account; Create application information and a first account, wherein the application information represents basic information generated for the purpose of purchasing an application; The step of requesting account association from the identity authentication server includes: transmitting the application information and the first account to the identity authentication server to trigger the identity authentication server to update the application information; If the account is successfully associated, the application information and public key information are received from the identity authentication server.

2. The method according to claim 1, characterized in that, The method further includes: If the account is successfully linked, in response to the purchase of the target application service, the order information corresponding to the target application service is obtained. Update the application information based on the order information; Based on the updated application information, the public key information, and the second account, a purchase service for the target application is provided.

3. The method according to claim 2, characterized in that, The provision of purchase services for the target application based on the updated application information, the public key information, and the second account includes: A purchase request is generated based on the updated application information, the public key information, the second account, and the preset verification information. The purchase request is sent to the application server. The preset verification information is used to verify the legitimacy of the permission management server. The application server is used to provide the target application service to trigger the application server to create a third account and establish an association between the information in the purchase request and the third account. The third account is the user's identity information when consuming the target application service. In response to a successful purchase, the purchase information fed back by the application server is obtained, including the target address and target instance identifier corresponding to the target application service; A purchase information update request is sent to the identity authentication server to trigger the identity authentication server to establish an association between the second account and the purchase information.

4. The method according to claim 3, characterized in that, The provision of access control services based on passwordless access tokens includes: In response to a request to consume the target application service, the system queries the identity authentication server for a passwordless access token based on the first account and the application information, thereby triggering the identity authentication server to generate a passwordless access token based on the first account, the second account, and the target instance identifier. An access address is generated based on the target address and the passwordless access token, and a link is established to the target application service corresponding to the access address.

5. The method according to claim 4, characterized in that, The step of generating an access address based on the target address and the passwordless access token, and linking to the target application service corresponding to the access address, includes: The passwordless access token is encrypted to obtain the encryption result; The access address is generated based on the target address and the encryption result; Redirecting to the access address triggers the application server to decrypt the encryption result, obtain the decryption result, and verify the decryption result. If the verification is successful, the target application service is provided.

6. The method according to claim 5, characterized in that, The verification includes the following steps: The parsing process yields the application information to be verified and the second account to be verified. Query the corresponding public key information based on the application information to be verified; The validity of the passwordless access token is verified based on the public key information; In response to a successful verification, the legitimacy of the second account to be verified is queried; In response to the validity of the second account to be verified, the verification is confirmed to be successful.

7. A permission management device, characterized in that, The device, used in a permission management server, includes: The authentication request acquisition module is used to obtain a first account in response to an authentication request sent by the client. The first account is used to identify the client's identity in the permission management server. The association establishment module is used to request account association from the identity authentication server. The identity authentication server is used to generate a second account based on the first account and establish an association relationship between the first account and the second account. The second account is the authorization identifier of the client obtained based on a preset authorization standard. The access control service module is used to provide access control services based on passwordless access tokens in response to the successful establishment of the account association, wherein the passwordless access tokens include the second account; The step of obtaining the first account in response to an authentication request from the client includes: In response to successful authentication, a request is made to the identity authentication server to activate the trusted identity authentication service, thereby triggering the identity authentication server to create and respond to the second account; Create application information and a first account, wherein the application information represents basic information generated for the purpose of purchasing an application; The step of requesting account association from the identity authentication server includes: transmitting the application information and the first account to the identity authentication server to trigger the identity authentication server to update the application information; If the account is successfully associated, the application information and public key information are received from the identity authentication server.

8. The access control method according to claim 7, characterized in that, The permission management service module is used to perform the following operations: If the account is successfully linked, in response to the purchase of the target application service, the order information corresponding to the target application service is obtained. Update the application information based on the order information; Based on the updated application information, the public key information, and the second account, a purchase service for the target application is provided.

9. The access control method according to claim 8, characterized in that, The permission management service module is used to perform the following operations: A purchase request is generated based on the updated application information, the public key information, the second account, and the preset verification information. The purchase request is sent to the application server. The preset verification information is used to verify the legitimacy of the permission management server. The application server is used to provide the target application service to trigger the application server to create a third account and establish an association between the information in the purchase request and the third account. The third account is the user's identity information when consuming the target application service. In response to a successful purchase, the purchase information fed back by the application server is obtained, including the target address and target instance identifier corresponding to the target application service; A purchase information update request is sent to the identity authentication server to trigger the identity authentication server to establish an association between the second account and the purchase information.

10. The access control method according to claim 9, characterized in that, The permission management service module is used to perform the following operations: In response to a request to consume the target application service, the system queries the identity authentication server for a passwordless access token based on the first account and the application information, thereby triggering the identity authentication server to generate a passwordless access token based on the first account, the second account, and the target instance identifier. An access address is generated based on the target address and the passwordless access token, and a link is established to the target application service corresponding to the access address.

11. The access control method according to claim 10, characterized in that, The permission management service module is used to perform the following operations: The passwordless access token is encrypted to obtain the encryption result; The access address is generated based on the target address and the encryption result; Redirecting to the access address triggers the application server to decrypt the encryption result, obtain the decryption result, and verify the decryption result. If the verification is successful, the target application service is provided.

12. The access control method according to claim 11, characterized in that, The permission management service module is used to perform the following operations: The parsing process yields the application information to be verified and the second account to be verified. Query the corresponding public key information based on the application information to be verified; The validity of the passwordless access token is verified based on the public key information; In response to a successful verification, the legitimacy of the second account to be verified is queried; In response to the validity of the second account to be verified, the verification is confirmed to be successful.

13. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores at least one instruction, which is loaded and executed by a processor to implement a permission management method as described in any one of claims 1 to 6.

14. An electronic device, characterized in that, The system includes at least one processor and a memory communicatively connected to the at least one processor; wherein the memory stores instructions executable by the at least one processor, and the at least one processor implements a permission management method as described in any one of claims 1 to 6 by executing the instructions stored in the memory.

15. A computer program product comprising computer instructions, characterized in that, When the computer instructions are executed by the processor, they implement the permission management method according to any one of claims 1 to 6.

Images