Multi-tenant identity switching and dynamic permission control method and device, and electronic equipment

Abstract

The application provides a multi-tenant identity switching and dynamic permission control method, device and electronic equipment. The method comprises the following steps: querying the valid organization membership relationship of a user, and determining a current organization context; checking a target organization membership relationship, and issuing an access token after the checking is passed; when a business request reaches a gateway, checking and analyzing the access token, writing the target organization context into a request context, and performing data access filtering based on the organization identifier in the request context; performing permission judgment on the business request, and generating a permission judgment result; performing invalidation processing on permission cache data; controlling access execution of the business request based on the permission judgment result, and performing token rotation based on a refresh chain identifier in a refresh token reissuing process, and performing link invalidation processing on the reuse of the invalidated refresh token. The application can reduce state synchronization cost, reduce the risk of exceeding authority, and improve the timeliness of permission change and replay disposal.

Description

Technical Field

[0001] This application relates to the field of software service platform technology, and in particular to a method, apparatus and electronic device for multi-tenant identity switching and dynamic permission control. Background Technology

[0002] With the widespread adoption of enterprise-level Software as a Service (SaaS) platforms, scenarios where the same user simultaneously participates in business collaborations across multiple organizations are becoming increasingly common. Users may have different member identities, role permissions, data scopes, and audit policies across different organizations. While supporting switching between organizational identities, the system needs to ensure that the access control and data isolation after the switch remain consistent with the current organizational identity.

[0003] Existing multi-tenant systems typically achieve organization switching and data access control by recording the current organization status through server-side sessions or by having clients include organization identifiers in request parameters and headers. Some systems also use a re-login method to generate an identity token corresponding to the target organization and combine it with role-based access control caching to complete interface authorization. While these methods can support multi-organization access to some extent, they still have shortcomings in distributed deployments, stateless gateways, and microservice architectures.

[0004] Specifically, server-side session-based solutions rely on the server to store the current organizational state, which can easily lead to state synchronization issues in multi-node forwarding scenarios. Client-side solutions that transmit organizational identifiers are susceptible to tampering, requiring business interfaces to repeatedly verify user-organization affiliation, potentially causing omissions. Re-login-based organization switching disrupts the workflow and increases the complexity of token refresh and revocation management. Single-role permissions or fixed-cache-period access control methods struggle to respond promptly to changes in members, roles, and policies. Even when token refresh only performs expiration checks, it's difficult to promptly identify token reuse after leakage. Therefore, it is necessary to provide a stateless identity switching and dynamic access control method suitable for multi-tenant scenarios. Summary of the Invention

[0005] In view of this, embodiments of this application provide a method, apparatus and electronic device for multi-tenant identity switching and dynamic permission control, in order to solve the problems of difficulty in synchronizing organizational status, easy tampering of organizational identifiers, and lag in processing permission changes and token replays in the prior art.

[0006] A first aspect of this application provides a multi-tenant identity switching and dynamic access control method, comprising: receiving a user login request and completing account authentication; querying the user's valid organizational member relationship; determining the current organizational context based on the valid organizational member relationship; responding to the user's organizational switching request; verifying the target organizational member relationship based on the user identifier and the target organizational identifier; issuing an access token containing the target organizational context after successful verification; updating the valid organizational context record; when a business request arrives at the gateway, verifying and parsing the access token; writing the obtained target organizational context into the request context; and performing data access filtering based on the organizational identifier in the request context; obtaining member permission data based on the target organizational context; performing permission judgment on the business request based on the member permission data and attribute control rules; generating a permission judgment result; invalidating the permission cache data when the organizational member relationship, role permission relationship, or attribute control rules change; controlling the access execution of the business request based on the permission judgment result; performing token rotation based on the refresh chain identifier during the refresh token reissue process; and performing link invalidation processing for the reuse of expired refresh tokens.

[0007] A second aspect of this application provides a multi-tenant identity switching and dynamic permission control device, comprising: a receiving module, configured to receive a user login request and complete account authentication, query the user's valid organizational member relationship, and determine the current organizational context based on the valid organizational member relationship; a verification module, configured to respond to the user's organizational switching request, verify the target organizational member relationship based on the user identifier and the target organizational identifier, issue an access token containing the target organizational context after successful verification, and update the valid organizational context record; a filtering module, configured to verify and parse the access token when a business request arrives at the gateway, write the obtained target organizational context into the request context, and perform data access filtering based on the organizational identifier in the request context; a generation module, configured to obtain member permission data based on the target organizational context, and perform permission judgment on the business request based on the member permission data and attribute control rules, and generate a permission judgment result; a processing module, configured to perform invalidation processing on the permission cache data when the organizational member relationship, role permission relationship, or attribute control rules change; and an execution module, configured to control the access execution of the business request based on the permission judgment result, and perform token rotation based on the refresh chain identifier during the refresh token reissue process, and perform link invalidation processing for the reuse of expired refresh tokens.

[0008] A third aspect of this application provides an electronic device, including a memory, a processor, and a computer program stored in the memory and running on the processor, wherein the processor executes the computer program to implement the steps of the above-described method.

[0009] A fourth aspect of this application provides a computer-readable storage medium storing a computer program that, when executed by a processor, implements the steps of the above-described method.

[0010] The above-described technical solutions adopted in the embodiments of this application can achieve the following beneficial effects: By receiving user login requests and completing account authentication, the system queries the user's valid organizational membership relationships and determines the current organizational context based on these relationships. In response to user organization switching requests, it verifies the target organization membership relationship based on the user identifier and the target organization identifier. Upon successful verification, it issues an access token containing the target organization context and updates the valid organizational context record. When a business request arrives at the gateway, the access token is verified and parsed, and the obtained target organization context is written into the request context. The business service performs data access filtering based on the organization identifier in the request context. Member permission data is obtained based on the target organization context, and permission judgment is performed on the business request based on the member permission data and attribute control rules, generating a permission judgment result. When organizational membership relationships, role permission relationships, or attribute control rules change, permission cache data is invalidated. Access execution of business requests is controlled based on the permission judgment result, and token rotation is performed based on the refresh chain identifier during refresh token reissue. Reusing an expired refresh token triggers a chain invalidation process. This application can reduce state synchronization costs, reduce the risk of unauthorized access, and improve the timeliness of permission change and replay processing. Attached Figure Description

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

[0012] Figure 1 This is a flowchart illustrating the multi-tenant identity switching and dynamic access control method provided in the embodiments of this application; Figure 2 This is a schematic diagram of the structure of the multi-tenant identity switching and dynamic access control device provided in the embodiments of this application; Figure 3 This is a schematic diagram of the structure of the electronic device provided in the embodiments of this application. Detailed Implementation

[0013] In the following description, specific details such as particular system architectures and techniques are set forth for illustrative purposes and not for limitation, in order to provide a thorough understanding of the embodiments of this application. However, those skilled in the art will understand that this application may also be implemented in other embodiments without these specific details. In other instances, detailed descriptions of well-known systems, apparatuses, circuits, and methods have been omitted so as not to obscure the description of this application with unnecessary detail.

[0014] With the increasing prevalence of enterprise-level Software as a Service (SaaS) platforms, the number of instances where a single user simultaneously participates in business collaborations across multiple organizations is gradually increasing. Current technologies typically achieve organizational identity switching and data access control by recording the current organizational status through server-side sessions or by passing organizational identifiers via request parameters and headers. Some systems also generate new identity tokens upon re-login and combine this with role-based permission caching to implement interface authorization checks. While these methods can support multi-organizational access to some extent, they lack a unified and reliable connection mechanism between organizational identity status, permission judgment criteria, and token refresh links.

[0015] Existing technologies have at least the following problems: Organization switching based on server-side sessions relies on the server to save the current organization state, which can easily lead to state synchronization issues in multi-node deployments, gateway forwarding, and microservice architectures; the method of transmitting organization identifiers via the client carries the risk of organization identifier tampering, requiring business interfaces to repeatedly verify the affiliation between users and organizations, increasing development costs and increasing the risk of verification omissions; switching organizations by re-login causes fragmented user operations and increases the complexity of token refresh and revocation management; single-role permission judgment or fixed-cache-period permission control methods are difficult to respond promptly to changes in organization members, role permissions, and attribute rules; when refresh tokens only undergo validity period verification, it is also difficult to promptly identify the risk of expired refresh tokens being reused.

[0016] To address the aforementioned issues, this application proposes a multi-tenant identity switching and dynamic access control method. After a user completes account authentication, this method queries the user's valid organizational membership relationships and determines the current organizational context based on these relationships. When a user initiates an organizational switching request, the method verifies the target organizational membership relationship based on the user identifier and the target organizational identifier. Upon successful verification, an access token containing the target organizational context is issued, and the valid organizational context record is updated. This effectively separates organizational identity from the server-side session state and client-side request parameters, transforming it into a signature-protected access token payload.

[0017] During business access, this application verifies and parses the access token through a gateway, writing the parsed target organization context into the request context. This allows business services to perform data access filtering based on the organization identifier in the request context, rather than relying on the organization identifier submitted by the client itself as the basis for data isolation. Simultaneously, this application obtains member permission data based on the target organization context and performs permission checks on business requests in conjunction with attribute control rules. When organizational member relationships, role permission relationships, or attribute control rules change, the cached permission data is invalidated, enabling subsequent requests to retrieve the updated permission data.

[0018] Furthermore, this application performs token security management in conjunction with the refresh token reissue process after access control. Specifically, during refresh token reissue, token rotation is performed based on the refresh chain identifier, the current refresh token is set to invalid, and a new refresh token and access token are issued; when an invalidated refresh token is detected to be used again, the refresh token that is still valid under the same refresh chain is invalidated based on the refresh chain identifier, thereby extending the handling of abnormal reuse of refresh tokens to the refresh chain dimension.

[0019] Through the above technical solutions, this application can reduce the cost of synchronizing organizational state in distributed scenarios, reduce the risk of unauthorized access caused by client tampering with organizational identifiers, and improve data isolation consistency after organizational identity switching; at the same time, it can improve the timeliness of the effect of permission changes and enhance the link handling capability when refresh tokens are reused, thereby improving the security and consistency of multi-tenant identity switching and dynamic permission control processes.

[0020] The technical solution of this application will now be described in detail with reference to the accompanying drawings and specific embodiments.

[0021] Figure 1 This is a flowchart illustrating the multi-tenant identity switching and dynamic access control method provided in an embodiment of this application. Figure 1 As shown, the multi-tenant identity switching and dynamic access control method may specifically include: S101: Receive user login request and complete account authentication, query user's valid organizational member relationship, and determine the current organizational context based on the valid organizational member relationship; S102, in response to the user's organization switching request, verify the target organization membership relationship based on the user identifier and the target organization identifier, issue an access token containing the target organization context after the verification is successful, and update the valid organization context record; S103, when a business request arrives at the gateway, the access token is verified and parsed, the obtained target organization context is written into the request context, and the business service performs data access filtering based on the organization identifier in the request context; S104: Obtain member permission data based on the target organization context, and perform permission judgment on business requests based on member permission data and attribute control rules to generate permission judgment results; S105, When the organizational member relationship, role permission relationship or attribute control rule changes, the permission cache data is invalidated; S106 controls the access execution of business requests based on the permission judgment result, and performs token rotation based on the refresh chain identifier during the refresh token reissue process, and performs chain failure handling for the reuse of expired refresh tokens.

[0022] In some embodiments, receiving a user login request and completing account authentication, querying the user's valid organizational membership relationships, and determining the current organizational context based on the valid organizational membership relationships include: The system authenticates the account credentials in the user login request. After successful authentication, it queries the organizational member relationships associated with the user based on the user identifier and filters the valid organizational member relationships according to the member status and validity period. When there is only one valid organization member relationship, the corresponding organization identifier and member identifier are determined as the current organization context, and an access token containing the current organization context is issued. When multiple valid organizational memberships exist, a temporary access token without organizational context is issued, and organizational selection information is generated to determine the target organizational context.

[0023] Specifically, after receiving a user login request, the system first authenticates the account credentials carried in the login request. Account credentials may include username, password, SMS verification code, single sign-on credentials, or authentication tickets returned by the enterprise identity source. The authentication service performs format validation, validity validation, and account status validation on the account credentials. If the account credentials are successfully authenticated and the user account is not in a disabled, frozen, or cancelled state, a user identifier corresponding to the user is generated, and this user identifier is used as the basis for subsequent queries of organizational membership relationships.

[0024] After account authentication is completed, the system invokes the organization relationship query service to retrieve member relationship records between the user and various organizations based on the user identifier. Member relationship records include at least the organization identifier, member identifier, member status, member validity period, organization status, and the member's department. The system does not directly treat all retrieved member relationships as available organizations; instead, it filters member relationships according to preset screening criteria. Specifically, it first removes member relationships with statuses of inactive, pending review, or removed, and then removes member relationships with expired validity periods or unavailable organization statuses, thus obtaining valid organization member relationships. For member relationships with authorization start and end times, the system can also determine whether the member relationship is still within its validity period based on the current authentication time.

[0025] When only one valid organizational membership relationship exists after filtering, the system identifies the organization identifier and member identifier from that valid relationship as the current organizational context and generates an access token payload based on this context. In addition to the user identifier, the access token payload also includes the current organization identifier, the current member identifier, and the context version information corresponding to that organizational membership relationship. The token issuance service signs the access token payload and sets its validity period, generating an access token containing the current organizational context. When users subsequently access business interfaces, they no longer need to submit the organization identifier as a request parameter; the gateway can directly parse the current organizational context from the access token.

[0026] When multiple valid organizational member relationships exist after filtering, the system does not directly designate any one of them as the current organizational context. Instead, it issues a temporary access token that does not contain an organizational context. This temporary access token only indicates that the user account authentication is successful, but the identity of the currently accessed organization has not yet been determined. The system generates organization selection information based on multiple valid organizational member relationships. This information may include the organization name, organization type, member identity summary, default entry point identifier, and recent access flag of the available organizations. The front end displays a list of switchable organizations based on the organization selection information. After the user selects the target organization, they initiate an organization switching request. The subsequent organization switching process verifies the target organization's member relationships and issues an access token containing the target organization's context.

[0027] For example, after User A completes account authentication, the organization relationship query service finds that they belong to both Organization 1 and Organization 2, with both organizations having valid membership status. In this case, the system issues a temporary access token and returns the organization selection information for Organization 1 and Organization 2 to the front end. If User A belongs only to Organization 1, or their membership validity period in Organization 2 has expired, the system writes the organization identifier and member identifier corresponding to Organization 1 into the access token, directly forming the current organization context. If membership relationships change during the authentication process, the system uses the member status and validity period read during filtering and writes the corresponding context version information into the access token for subsequent gateway parsing and permission verification.

[0028] Through the above implementation method, the system completes the hierarchical processing of account identity and organizational member relationship during the user login stage, enabling single-organization users to directly enter the corresponding organizational context, and multi-organization users to enter the organization selection process through temporary access tokens. Subsequent business access is based on the access token protected by signature, carrying the current organizational context, thereby reducing server-side session dependency, reducing the risk of unauthorized access caused by client-side organization identifier transmission, and improving the consistency of multi-tenant identity switching entry.

[0029] In some embodiments, in response to a user's organization switching request, the member relationship of the target organization is verified based on the user identifier and the target organization identifier. Upon successful verification, an access token containing the target organization context is issued, and the valid organization context record is updated, including: Receive an organization switching request carrying the target organization identifier, query the organization member relationship between the user and the target organization based on the user identifier, and verify the member status, validity period and organization status of the organization member relationship; After the organization membership relationship verification is passed, the target organization context is generated based on the target organization identifier and the corresponding member identifier, and the target organization context is written into the access token payload and then signed and issued. Update the target organization context as the valid organization context record corresponding to the user, so that it can be called when the access token is refreshed.

[0030] Specifically, after completing account authentication and obtaining a temporary access token, or already being within an organizational context, users can submit an organization switch request through the front-end organization switch portal. The organization switch request carries the identifier of the target organization selected by the user. Upon receiving the request, the server does not directly generate an access token based on the target organization identifier submitted by the client. Instead, it first reads the user identifier from the authenticated identities and then queries the organizational membership relationship between the user and the target organization based on the user identifier and the target organization identifier. This query retrieves corresponding records from the organization membership relationship table, member role relationship table, and organization status table to confirm whether the user actually belongs to the target organization and whether the target organization is accessible.

[0031] When verifying member relationships within a target organization, the system can sequentially determine the membership status, validity period, and organization status. Member status determines whether the user's membership in the target organization is in a normal and usable state; if the member status is disabled, removed, pending review, or frozen, the verification fails. Validity period determines whether the membership relationship is within its authorized period; if the current time is earlier than the member's effective time or later than the member's expiration time, the verification fails. Organization status determines whether the target organization is operating normally; if the target organization is disabled, deregistered, or suspended, switching to that organization is not allowed. For member relationships with additional information such as department affiliation, member type, and organization entry domain, the system can also read this information in the same verification process and use it as part of the target organization's context or as the basis for subsequent interface routing.

[0032] Furthermore, after the organization membership verification passes, the system generates a target organization context based on the target organization identifier and the corresponding member identifier. The target organization context at least includes the current organization identifier corresponding to the user identifier, the current member identifier, and context version information corresponding to the target organization membership relationship. In some implementations, the target organization context can also be associated with the target organization's default menu field, member role summary, data scope version, and audit policy identifier. The token issuance service writes the target organization context into the access token payload, signs the access token payload, and sets the issuance time and validity period of the access token, thus forming an access token containing the target organization context. After this access token is returned to the client, the client carries this access token in subsequent business requests, and the gateway can parse the target organization context from the access token without requiring the business interface to trust the organization identifier additionally submitted by the client.

[0033] For example, User A belongs to both Organization 1 and Organization 2. In Organization 1, User A is an administrator, and in Organization 2, User A is a regular member. After logging in, User A selects Organization 2 through the organization selection interface. The front-end submits an organization switch request carrying the Organization 2 identifier to the server. The server queries the membership relationship based on User A's user identifier and Organization 2 identifier. After confirming that User A's membership status in Organization 2 is valid, the membership period has not expired, and Organization 2 is in a normal state, the server reads the corresponding member identifier of Organization 2 and generates a target organization context centered on the Organization 2 identifier and the member identifier. Subsequently, the system issues an access token containing the target organization context, ensuring that all subsequent business access by User A is within the data and permission scope of Organization 2.

[0034] After issuing the access token, the system writes the target organization context into the user's corresponding valid organization context record. This valid organization context record can store the last valid organization identifier, member identifier, update time, and context version information. When the access token expires and the client uses a refresh token to reissue the access token, the token issuance service can read this valid organization context record and restore the user's most recent valid organization context after verifying the validity of the refresh token. This eliminates the need for the user to reselect an organization or log in again. If it is subsequently detected that the target organization's membership relationship has expired, the refresh phase can refuse to restore the organization context and require the user to select a valid organization again.

[0035] Through the above implementation, the system performs server-side verification of the target organization's member relationships during the organization switching phase, and carries the target organization's context through a signed access token, so that the organization switching does not depend on server-side session migration and client-side organization parameter transmission; at the same time, by updating the valid organization context record, the access token can continue the most recent valid organization identity when refreshed, thereby reducing the state synchronization cost during the organization switching process, reducing the risk of unauthorized access caused by organization identifier tampering, and improving the continuity and consistency of multi-organization access process.

[0036] In some embodiments, when a business request arrives at the gateway, the access token is verified and parsed, the obtained target organization context is written into the request context, and the business service performs data access filtering based on the organization identifier in the request context, including: After receiving a service request, the gateway performs signature verification, validity verification, and load parsing on the access token carried in the service request to obtain the target organization context associated with the user identifier. Write the organization identifier, member identifier, and corresponding context fields from the target organization context into the request context, and forward the request context to the corresponding business service along with the business request; The business service reads the organization identifier from the request context and uses it as a filter for data querying, resource ownership determination, and business processing, while ignoring the organization identifier submitted by the client with the business request.

[0037] Specifically, when a client accesses a business interface, it sends the previously issued access token along with the business request to the unified gateway. As the unified authentication entry point before the business service, the gateway first extracts the access token from the authentication field of the business request and performs signature verification according to the signature algorithm and key identifier used when the token was issued to confirm that the access token has not been tampered with. After the signature verification passes, it continues to read the issuance time, validity period, and token type from the access token and performs validity and type verification on the access token. If the access token has expired, the signature is inconsistent, or the token type does not match, the gateway directly blocks the business request and generates a corresponding access record, no longer forwarding the business request to the backend business service.

[0038] After the access token is verified, the gateway parses the access token payload to obtain the target organization context associated with the user identifier. The target organization context may include fields such as organization identifier, member identifier, context version, data scope version, and audit policy identifier. The gateway further performs basic context integrity checks based on the parsed organization identifier and member identifier, such as determining whether the access token simultaneously contains the user identifier, organization identifier, and member identifier, and whether the organization context is consistent with the context version in the token issuance record. For ordinary business requests initiated by temporary access tokens, if the token payload does not contain an organization context, the gateway may reject the business request or guide the client into the organization selection process.

[0039] Furthermore, after completing the target organization context resolution, the gateway writes the organization identifier, member identifier, and corresponding context fields from the target organization context into the request context. The request context can be transmitted internally through internal request headers, call chain context fields, or gateway forwarding parameters, but it is generated and written by the gateway and cannot be directly modified by the client. The gateway forwards the business request carrying the request context to the corresponding business service, enabling the backend business service to read the trusted organization context without repeatedly resolving the access token. For interfaces requiring auditing, the gateway can also write the user identifier, organization identifier, member identifier, request path, access time, and token context version into the audit data, providing a basis for subsequent access tracing.

[0040] After receiving a business request forwarded by the gateway, the business service reads the organization identifier from the request context and uses this identifier as a filter for data querying, resource ownership determination, and business processing. Taking a work order management scenario as an example, when user A accesses the work order list interface under a second organization, even if the client's request parameters include the organization identifier of the first organization, the business service ignores the client's submitted organization identifier. Instead, it reads the second organization identifier injected by the gateway and appends the data filter condition corresponding to the second organization identifier to the work order query conditions, returning only work order data within the second organization's scope. For business operations such as adding, modifying, and deleting, the business service also uses the organization identifier in the request context as the basis for writing resource ownership or for ownership verification, and does not allow the client to change the organization to which the data belongs through parameters.

[0041] For example, User A is an administrator in the first organization and a regular member in the second organization. After switching organizations, User A obtains an access token containing the context of the second organization and requests access to the member management interface. The gateway verifies the access token, parses out the second organization identifier and the corresponding member identifier, writes them into the request context, and forwards them to the member management service. The member management service reads the second organization identifier from the request context, performs organization-level filtering on the member data table, and determines whether to allow further access based on the permissions corresponding to that member identifier. Even if the first organization identifier appears in the request address or request body, the member management service does not use it as the final isolation basis, thereby preventing client parameters from affecting the organizational data boundaries.

[0042] Through the above implementation, the system centralizes access token verification, target organization context parsing, and trusted context injection on the gateway side, enabling backend business services to perform data access filtering based on the organization identifier injected by the gateway. This reduces the implementation cost of repeatedly verifying organization affiliation on business interfaces, lowers the risk of unauthorized access caused by client tampering with organization identifiers, and improves the data isolation consistency of multi-tenant business requests in distributed services.

[0043] In some embodiments, member permission data is obtained based on the target organization context, and permission judgment is performed on business requests based on the member permission data and attribute control rules to generate permission judgment results, including: Based on the organization identifier and member identifier in the target organization context, query the corresponding member role relationship and role permission relationship, generate the member permission data under the current organization, and write the member permission data to the permission cache; Based on the access object and operation type corresponding to the business request, the basic permissions are matched from the member permission data to obtain the basic permission judgment result; When the basic permission judgment result is passed, the attribute control rules associated with the current organization, member permission data and access object are read, and the request-related attributes corresponding to the business request are matched by rules and evaluated by conditions. Based on the rule matching results and the preset conflict handling method, the permission judgment result corresponding to the business request is generated.

[0044] Specifically, after the gateway forwards the business request to the permission decision module, the permission decision module first reads the target organization context from the request context and obtains the organization identifier and member identifier. Based on the organization identifier and member identifier, the permission decision module queries the member role relationship to determine the role granted to the member within the current organization. Then, based on the role permission relationship, it queries the menu permissions, interface permissions, data operation permissions, and resource domain permissions corresponding to each role, and merges duplicate permissions to generate member permission data for the current organization. This member permission data can be cached using the organization identifier, member identifier, and permission version as a cache key, allowing high-frequency access by the same member within the same organization to directly read the cached member permission data.

[0045] When generating member permission data, the system does not determine permissions solely based on the user account's global identity. Instead, it always uses the organization identifier and member identifier within the target organization context as query conditions. Taking user A as an example, user A is an administrator member in the first organization and a regular member in the second organization. When user A switches to the second organization and accesses the member management interface, the permission decision module queries the user's role and permission relationships in the second organization based on the second organization identifier and the corresponding member identifier, rather than retaining the administrator permissions from the first organization. Therefore, the member permission data maintains a correspondence with the current organizational context.

[0046] When a business request enters the basic permission judgment stage, the permission decision module matches basic permissions from the member permission data based on the access object and operation type corresponding to the business request. The access object can be a business menu, interface resource, data object, or function button; the operation type can be a business action such as query, add, modify, delete, or export. If no permission identifier matches the access object and operation type in the member permission data, a failed basic permission judgment result is generated; if a matching permission identifier exists, a passed basic permission judgment result is generated, and the process proceeds to the attribute control rule judgment stage.

[0047] If the basic permission assessment is successful, the system further reads the attribute control rules associated with the current organization, member permission data, and access objects. These attribute control rules are stored in a structured format and describe the matching relationship between request-related attributes and access conditions. Request-related attributes can be extracted in real-time based on business requests, including information such as the member's department, resource scope, access time, terminal type, data sensitivity level, and resource creator. The permission decision module substitutes the request-related attributes into the attribute control rules, evaluates the rule nodes, and generates rule matching results according to rule hierarchy and priority. In cases where multiple rules are matched simultaneously, the system adjudicates according to a preset conflict handling method. When both allow and deny conditions exist, the denial result is used as the final decision.

[0048] For example, if User A has basic permission to query work orders in a second organization, and requests access to the work order list of the second organization, the system first matches the work order query permission in the member permission data, and the basic permission judgment result is passed. Subsequently, the system reads the attribute control rules associated with the work order resources of the second organization, and determines whether the member's department is consistent with the department of the work order, whether the access time is within the allowed period, and whether the sensitivity level of the work order exceeds the member's access range. If the department range matches and the data sensitivity level does not exceed the limit, an access permission judgment result is generated; if the basic permission matches, but the attribute control rules determine that the work order belongs to the restricted resource range, an access denial permission judgment result is generated.

[0049] Through the above implementation method, the system first completes basic permission matching based on the member permission data under the current organization, and then combines attribute control rules to make fine-grained judgments on the running conditions of business requests. This makes the permission judgment results subject to the organizational context, member role relationship and request association attributes, thereby improving the accuracy of permission control in multi-organization scenarios, reducing the risk of cross-organization permission mixing, and taking into account the efficiency of high-frequency permission reading and dynamic access control capabilities.

[0050] In some embodiments, when organizational membership, role-based permission relationships, or attribute control rules change, invalidation processing is performed on the permission cache data, including: Listen for change events related to organizational member relationships, role permission relationships, or attribute control rules, and determine the affected organizational identifiers, member identifiers, role identifiers, and access object scope based on the change events; Based on the affected organization identifier, member identifier, role identifier, and scope of access objects, generate corresponding permission cache location information; Based on the permission cache location information, locate the permission cache data associated with member permission data and attribute control rules, and perform deletion or invalidation processing on the found permission cache data; When performing permission checks on subsequent business requests, the member permission data and attribute control rules are retrieved again based on the permission cache status after deletion or invalidation.

[0051] Specifically, the system sets up change monitoring mechanisms on the permission configuration management side, organization member management side, and rule management side to monitor change events related to organization member relationships, role permission relationships, and attribute control rules. Change events can be triggered by management operations, approval processes, organization member synchronization tasks, or permission policy release tasks. When the system detects that a member has been added to an organization, removed from an organization, disabled, had their role adjusted, had role permissions added or deleted, or had attribute control rules modified, it generates a corresponding permission change event and records the changed object, change type, change time, and the scope of association before and after the change in the permission change event.

[0052] After generating a permission change event, the system determines the affected organization identifier, member identifier, role identifier, and access object scope based on the change event. For changes in organization member relationships, if a member's membership status in the target organization changes from active to inactive, the system determines the target organization identifier and the member identifier as the affected scope. If a member is removed from the organization, the system includes the member permission data and attribute control rule matching results of that member in that organization within the scope of invalidation. For changes in role permission relationships, if a role in the target organization gains new interface access permissions or loses data export permissions, the system performs a reverse lookup of the set of member identifiers with that role based on the role identifier and determines the corresponding access object scope as the affected scope. For changes in attribute control rules, if the work order resource rule of the second organization is changed from allowing access within the department to allowing only the responsible person, the system determines the second organization identifier, the work order access object scope, and the member permission data associated with that rule as the affected scope.

[0053] Furthermore, after determining the affected scope, the system generates permission cache location information based on the affected organization identifier, member identifier, role identifier, and access object scope. This permission cache location information is used to locate cache keys related to member permission data and attribute control rules within the permission cache. Cache keys can be generated by combining organization identifier, member identifier, role identifier, access object scope, and permission version, or an index mapping can be generated based on these fields to facilitate batch lookup of cached data when the scope of changes is large. For example, if user A corresponds to a regular member role in a second organization, and the administrator deletes the work order export permission for this regular member role, the system generates permission cache location information based on the second organization identifier, regular member role identifier, and work order export access object scope, and locates the permission caches of user A and other members with that role.

[0054] After the system locates the permission cache data based on the permission cache location information, it can delete the found member permission data cache, attribute control rule cache, and intermediate rule matching results, or add an invalidation flag. For scenarios with a small number of cached items, the corresponding cache key can be directly deleted. For scenarios where a role affects many members, the role permission version or rule version can be incremented, and the old version can be marked as invalid in the cache record, preventing subsequent requests from using the old cache. For systems deployed across nodes, the cache invalidation module can also publish permission change events to each gateway node and permission decision node, ensuring that the permission cache status of different nodes remains consistent.

[0055] When performing permission checks on subsequent business requests, the permission decision module reads the permission cache status based on the organization identifier and member identifier in the request context. If the corresponding cache is not found, or the found cache record has an invalidation mark, or the permission version of the cache record is lower than the current permission version, the system re-queries the member role relationship, role permission relationship, and attribute control rules, generates new member permission data, and re-executes the basic permission matching and attribute control rule evaluation. Taking the aforementioned user A as an example, after the work order export permission of the ordinary member role is deleted, when user A requests the work order export interface again, the system will not continue to use the old member permission cache, but will reload the updated role permission relationship and generate a failed permission check result.

[0056] Through the above implementation methods, when organizational member relationships, role permission relationships, or attribute control rules change, the system can locate and invalidate the relevant permission cache according to the scope of the change, so that subsequent business requests can re-obtain the updated member permission data and attribute control rules, thereby reducing the permission delay caused by fixed cache periods, improving the timeliness of permission changes taking effect, and reducing the risk of unauthorized access caused by inconsistencies between organizational identity and permission data.

[0057] In some embodiments, access execution of business requests is controlled based on permission judgment results, and token rotation is performed based on refresh chain identifier during refresh token reissue. Reuse of expired refresh tokens involves handling chain failures, including: The access status of the business request is determined based on the permission judgment result. If the permission judgment result is passed, the business request is forwarded to the corresponding business service. If the permission judgment result is failed, the business request is blocked and an access record is generated. Receive a token exchange request carrying a refresh token, and verify the validity status of the refresh token and the corresponding refresh chain identifier; After the refresh token is verified, the current refresh token is set to invalid, and a new refresh token and access token are issued, so that the new refresh token inherits the refresh chain identifier. When an expired refresh token is detected to be used again, the refresh token that is still valid in the same refresh chain is searched according to its corresponding refresh chain identifier, and the refresh token that is found is invalidated.

[0058] Specifically, the access control node determines the access status of a business request based on the permission assessment result. When the permission assessment result is successful, the access control node forwards the business request along with its request context to the corresponding business service, which then continues to perform data queries, resource ownership determinations, and business processing based on the organization identifier in the request context. When the permission assessment result is unsuccessful, the access control node blocks the business request and generates an access record. The access record may include user identifier, organization identifier, member identifier, access object, operation type, assessment result, blocking reason, and access time for subsequent auditing and security tracing.

[0059] For example, if User A only has work order query permissions in the second organization, and requests access to the work order details interface, the permission decision module determines that the user's member permission data contains work order query permissions, and the attribute control rules confirm that the work order belongs to User A's department. Therefore, the access control node allows the request to enter the work order service. If User A requests to perform a work order export operation, but the corresponding basic permission does not exist in the user's member permission data, or the attribute control rules determine that the work order belongs to the restricted sensitive data range, the access control node blocks the request and records the second organization identifier, User A's corresponding member identifier, and the blocking reason for the work order export operation. Thus, the execution status of the business request remains consistent with the current organizational context and permission judgment results.

[0060] When an access token expires or is about to expire, the client can submit a token renewal request carrying a refresh token. Upon receiving the token renewal request, the token service first verifies the validity of the refresh token, including whether it exists, has expired, has been revoked, and matches the current user's identity. If the verification passes, the token service reads the refresh chain identifier corresponding to the refresh token. The refresh chain identifier represents the sequential relationship of refresh tokens within the same device or session, enabling the server to identify the succession relationship between refresh tokens within the same refresh chain.

[0061] Furthermore, after the refresh token verification is successful, the token service invalidates the current refresh token and generates a new refresh token and a new access token. The new refresh token inherits the refresh chain identifier corresponding to the original refresh token to maintain the continuity of the same refresh chain; the new access token is generated based on the user's corresponding valid organizational context record, so that the user is still in the most recently valid organizational context after refreshing the access token.

[0062] For example, taking the aforementioned user A as an example, after user A completes the organization switch and updates the valid organization context record under the second organization, if the access token expires, when the client uses a valid refresh token to reissue the token, the token service reads the valid organization context record corresponding to the second organization and issues a new access token containing the second organization identifier and the corresponding member identifier. At the same time, the old refresh token is set to invalid, and a new refresh token inheriting the identifier of the same refresh chain is issued.

[0063] When the server detects that an expired refresh token has been used again, it indicates that there may be a risk of refresh token leakage or concurrent replay within the same refresh chain. In this case, the token service no longer simply rejects the current refresh request, but instead searches for a valid refresh token within the same refresh chain based on the refresh chain identifier corresponding to the expired refresh token, and invalidates the found refresh token.

[0064] Simultaneously, the system generates a security audit event, recording the user identifier, refresh chain identifier, abnormal token status, abnormal request time, and request source information. It then adjusts the user's access status under the corresponding device or session chain to require re-authentication. If user A's old refresh token is submitted again after being renewed, the system searches for a new refresh token in the same chain according to the refresh chain identifier of the old refresh token and invalidates it. Subsequent attackers, even if they possess the new refresh token, will be unable to renew access tokens.

[0065] Through the above implementation, the system can control whether a business request continues to be executed based on the permission judgment result, and form a rotation relationship in the process of refreshing token replacement, where the old token becomes invalid and the new token inherits the refresh chain identifier; when the expired refresh token reappears, the system can perform invalidation processing and auditing according to the refresh chain, thereby improving the consistency of access control execution, shortening the exploitable time after the refresh token is leaked, and enhancing the token security protection capability during multi-tenant identity switching.

[0066] The following are embodiments of the apparatus described in this application, which can be used to execute the embodiments of the method described in this application. For details not disclosed in the apparatus embodiments of this application, please refer to the embodiments of the method described in this application.

[0067] Figure 2 This is a schematic diagram of the multi-tenant identity switching and dynamic access control device provided in an embodiment of this application. Figure 2 As shown, the multi-tenant identity switching and dynamic access control device includes: The receiving module 201 is used to receive user login requests and complete account authentication, query the user's valid organizational member relationships, and determine the current organizational context based on the valid organizational member relationships; The verification module 202 is used to respond to the user's organization switching request, verify the member relationship of the target organization based on the user identifier and the target organization identifier, issue an access token containing the target organization context after the verification is passed, and update the valid organization context record. The filtering module 203 is used to verify and parse the access token when a business request arrives at the gateway, write the obtained target organization context into the request context, and the business service performs data access filtering based on the organization identifier in the request context. The generation module 204 is used to obtain member permission data based on the target organization context, and to perform permission judgment on business requests based on the member permission data and attribute control rules, and generate permission judgment results. Processing module 205 is used to invalidate permission cache data when organizational member relationships, role permission relationships, or attribute control rules change; The execution module 206 is used to control the access execution of business requests based on the permission judgment result, and to perform token rotation based on the refresh chain identifier during the refresh token reissue process, and to handle the failure of the execution chain for the reuse of expired refresh tokens.

[0068] In some embodiments, Figure 2 The receiving module 201 authenticates the account credentials in the user login request. After successful authentication, it queries the organizational member relationships associated with the user based on the user identifier and filters valid organizational member relationships according to member status and validity period. When there is only one valid organizational member relationship, the corresponding organizational identifier and member identifier are determined as the current organizational context, and an access token containing the current organizational context is issued. When there are multiple valid organizational member relationships, a temporary access token without organizational context is issued, and organizational selection information for determining the target organizational context is generated.

[0069] In some embodiments, Figure 2 The verification module 202 receives an organization switching request carrying the target organization identifier, queries the organization member relationship between the user and the target organization based on the user identifier, and verifies the member status, validity period and organization status of the organization member relationship; after the organization member relationship verification is passed, the target organization context is generated according to the target organization identifier and the corresponding member identifier, and the target organization context is written into the access token payload and then signed and issued; the target organization context is updated as the valid organization context record corresponding to the user, so that it can be called when the access token is refreshed.

[0070] In some embodiments, Figure 2After receiving a business request, the filtering module 203 gateway performs signature verification, timeliness verification, and load balancing on the access token carried by the business request to obtain the target organization context associated with the user identifier. It writes the organization identifier, member identifier, and corresponding context fields in the target organization context into the request context and forwards the request context to the corresponding business service along with the business request. The business service reads the organization identifier in the request context and uses the organization identifier as a filtering condition for data query, resource ownership judgment, and business processing, while ignoring the organization identifier submitted by the client with the business request.

[0071] In some embodiments, Figure 2 The generation module 204 queries the corresponding member role relationships and role permission relationships based on the organization identifier and member identifier in the target organization context, generates member permission data under the current organization, and writes the member permission data into the permission cache; based on the access object and operation type corresponding to the business request, it matches basic permissions from the member permission data to obtain the basic permission judgment result; when the basic permission judgment result is passed, it reads the attribute control rules associated with the current organization, member permission data, and access object, performs rule matching and condition evaluation on the request-related attributes corresponding to the business request; based on the rule matching result and the preset conflict handling method, it generates the permission judgment result corresponding to the business request.

[0072] In some embodiments, Figure 2 The processing module 205 listens for change events corresponding to organizational member relationships, role permission relationships, or attribute control rules, and determines the affected organizational identifiers, member identifiers, role identifiers, and access object ranges based on the change events; generates corresponding permission cache location information based on the affected organizational identifiers, member identifiers, role identifiers, and access object ranges; searches for permission cache data associated with member permission data and attribute control rules based on the permission cache location information, and performs deletion or invalidation marking on the found permission cache data; when performing permission judgment in subsequent business requests, it re-obtains member permission data and attribute control rules based on the permission cache status after deletion or invalidation marking.

[0073] In some embodiments, Figure 2The execution module 206 determines the access status of the business request based on the permission judgment result. If the permission judgment result is successful, the business request is forwarded to the corresponding business service. If the permission judgment result is unsuccessful, the business request is blocked and an access record is generated. It receives a token replacement request carrying a refresh token, verifies the validity status of the refresh token and the corresponding refresh chain identifier. After the refresh token is verified, the current refresh token is set to an invalid state, and a new refresh token and access token are issued, so that the new refresh token inherits the refresh chain identifier. When it is detected that an invalid refresh token is used again, it searches for a refresh token that is still valid in the same refresh chain according to its corresponding refresh chain identifier, and performs invalidation processing on the found refresh token.

[0074] It should be understood that the sequence number of each step in the above embodiments does not imply the order of execution. The execution order of each process should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of the embodiments of this application.

[0075] Figure 3 This is a schematic diagram of the electronic device 3 provided in an embodiment of this application. Figure 3 As shown, the electronic device 3 of this embodiment includes: a processor 301, a memory 302, and a computer program 303 stored in the memory 302 and executable on the processor 301. When the processor 301 executes the computer program 303, it implements the steps in the various method embodiments described above. Alternatively, when the processor 301 executes the computer program 303, it implements the functions of each module / unit in the various device embodiments described above.

[0076] Electronic device 3 can be a desktop computer, laptop, handheld computer, cloud server, or other electronic device. Electronic device 3 may include, but is not limited to, processor 301 and memory 302. Those skilled in the art will understand that... Figure 3 This is merely an example of electronic device 3 and does not constitute a limitation on electronic device 3. It may include more or fewer components than shown, or different components.

[0077] The processor 301 may be a central processing unit (CPU), or other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc.

[0078] The memory 302 can be an internal storage unit of the electronic device 3, such as a hard disk or memory of the electronic device 3. The memory 302 can also be an external storage device of the electronic device 3, such as a plug-in hard disk, smart media card (SMC), secure digital (SD) card, flash card, etc., equipped on the electronic device 3. The memory 302 can also include both internal and external storage units of the electronic device 3. The memory 302 is used to store computer programs and other programs and data required by the electronic device.

[0079] Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the above-described division of functional units and modules is merely an example. In practical applications, the above functions can be assigned to different functional units and modules as needed, that is, the internal structure of the device can be divided into different functional units or modules to complete all or part of the functions described above. The functional units and modules in the embodiments can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional unit.

[0080] If integrated modules / units are implemented as software functional units and sold or used as independent products, they can be stored in a readable storage medium (e.g., a computer-readable storage medium). Based on this understanding, all or part of the processes in the methods of the above embodiments can also be implemented by a computer program instructing related hardware. The computer program can be stored in a computer-readable storage medium, and when executed by a processor, it can implement the steps of the various method embodiments described above. The computer program may include computer program code, which may be in the form of source code, object code, executable files, or certain intermediate forms. The computer-readable storage medium may include: any entity or device capable of carrying computer program code, recording media, USB flash drives, portable hard drives, magnetic disks, optical disks, computer memory, read-only memory (ROM), random access memory (RAM), electrical carrier signals, telecommunication signals, and software distribution media, etc.

[0081] The above embodiments are only used to illustrate the technical solutions of this application, and are not intended to limit them. Although this application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of this application, and should all be included within the protection scope of this application.

Claims

1. A method for multi-tenant identity switching and dynamic access control, characterized in that, include: Receive user login requests and complete account authentication, query the user's valid organizational member relationships, and determine the current organizational context based on the valid organizational member relationships; In response to a user's organization switching request, the member relationship of the target organization is verified based on the user identifier and the target organization identifier. After the verification is successful, an access token containing the target organization context is issued, and the valid organization context record is updated. When a business request arrives at the gateway, the access token is verified and parsed, and the obtained target organization context is written into the request context. The business service performs data access filtering based on the organization identifier in the request context. Obtain member permission data based on the target organization context, and perform permission judgment on business requests based on member permission data and attribute control rules to generate permission judgment results; When organizational membership relationships, role permission relationships, or attribute control rules change, the permission cache data is invalidated. The system controls the access and execution of business requests based on the permission judgment results, and performs token rotation based on the refresh chain identifier during the refresh token reissue process. The system also handles the failure of the execution chain for the reuse of expired refresh tokens.

2. The method according to claim 1, characterized in that, The steps of receiving a user login request and completing account authentication, querying the user's valid organizational member relationships, and determining the current organizational context based on the valid organizational member relationships include: The system authenticates the account credentials in the user login request. After successful authentication, it queries the organizational member relationships associated with the user based on the user identifier and filters the valid organizational member relationships according to the member status and validity period. When there is only one valid organization member relationship, the corresponding organization identifier and member identifier are determined as the current organization context, and an access token containing the current organization context is issued. When multiple valid organizational memberships exist, a temporary access token without organizational context is issued, and organizational selection information is generated to determine the target organizational context.

3. The method according to claim 1, characterized in that, In response to a user's organization switching request, the system verifies the target organization membership relationship based on the user identifier and the target organization identifier. Upon successful verification, it issues an access token containing the target organization context and updates the valid organization context record, including: Receive an organization switching request carrying the target organization identifier, query the organization member relationship between the user and the target organization based on the user identifier, and verify the member status, validity period and organization status of the organization member relationship; After the organization membership relationship verification is passed, the target organization context is generated based on the target organization identifier and the corresponding member identifier, and the target organization context is written into the access token payload and then signed and issued. Update the target organization context as the valid organization context record corresponding to the user, so that it can be called when the access token is refreshed.

4. The method according to claim 1, characterized in that, When a business request arrives at the gateway, the access token is verified and parsed, and the obtained target organization context is written into the request context. The business service performs data access filtering based on the organization identifier in the request context, including: After receiving a service request, the gateway performs signature verification, validity verification, and load parsing on the access token carried in the service request to obtain the target organization context associated with the user identifier. Write the organization identifier, member identifier, and corresponding context fields from the target organization context into the request context, and forward the request context to the corresponding business service along with the business request; The business service reads the organization identifier from the request context and uses it as a filter for data querying, resource ownership determination, and business processing, while ignoring the organization identifier submitted by the client with the business request.

5. The method according to claim 1, characterized in that, The step of obtaining member permission data based on the target organization context, and performing permission judgment on business requests based on the member permission data and attribute control rules to generate permission judgment results includes: Based on the organization identifier and member identifier in the target organization context, query the corresponding member role relationship and role permission relationship, generate the member permission data under the current organization, and write the member permission data to the permission cache; Based on the access object and operation type corresponding to the business request, the basic permissions are matched from the member permission data to obtain the basic permission judgment result; When the basic permission judgment result is passed, the attribute control rules associated with the current organization, member permission data and access object are read, and the request-related attributes corresponding to the business request are matched by rules and evaluated by conditions. Based on the rule matching results and the preset conflict handling method, the permission judgment result corresponding to the business request is generated.

6. The method according to claim 1, characterized in that, When organizational membership relationships, role permission relationships, or attribute control rules change, the permission cache data is invalidated, including: Listen for change events related to organizational member relationships, role permission relationships, or attribute control rules, and determine the affected organizational identifiers, member identifiers, role identifiers, and access object scope based on the change events; Based on the affected organization identifier, member identifier, role identifier, and scope of access objects, generate corresponding permission cache location information; Based on the permission cache location information, locate the permission cache data associated with member permission data and attribute control rules, and perform deletion or invalidation processing on the found permission cache data; When performing permission checks on subsequent business requests, the member permission data and attribute control rules are retrieved again based on the permission cache status after deletion or invalidation.

7. The method according to claim 1, characterized in that, The process of controlling the access execution of service requests based on permission judgment results, and performing token rotation based on refresh chain identifier during refresh token reissue, and handling the failure of the execution chain for the reuse of expired refresh tokens, includes: The access status of the business request is determined based on the permission judgment result. If the permission judgment result is passed, the business request is forwarded to the corresponding business service. If the permission judgment result is failed, the business request is blocked and an access record is generated. Receive a token exchange request carrying a refresh token, and verify the validity status of the refresh token and the corresponding refresh chain identifier; After the refresh token is verified, the current refresh token is set to invalid, and a new refresh token and access token are issued, so that the new refresh token inherits the refresh chain identifier. When an expired refresh token is detected to be used again, the refresh token that is still valid in the same refresh chain is searched according to its corresponding refresh chain identifier, and the refresh token that is found is invalidated.

8. A multi-tenant identity switching and dynamic access control device, characterized in that, include: The receiving module is used to receive user login requests and complete account authentication, query the user's valid organizational member relationships, and determine the current organizational context based on the valid organizational member relationships. The verification module is used to respond to a user's organization switching request, verify the member relationship of the target organization based on the user identifier and the target organization identifier, issue an access token containing the target organization context after the verification is successful, and update the valid organization context record. The filtering module is used to verify and parse the access token when a business request arrives at the gateway, write the obtained target organization context into the request context, and the business service performs data access filtering based on the organization identifier in the request context. The generation module is used to obtain member permission data based on the target organization context, and to perform permission judgment on business requests based on the member permission data and attribute control rules, and generate permission judgment results. The processing module is used to invalidate the permission cache data when the organizational member relationship, role permission relationship or attribute control rules change; The execution module is used to control the access and execution of business requests based on the permission judgment result, and to perform token rotation based on the refresh chain identifier during the refresh token reissue process, and to handle the failure of the execution chain for the reuse of expired refresh tokens.

9. An electronic device, comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that, When the processor executes the computer program, it implements the steps of the method as described in any one of claims 1 to 7.

10. A computer-readable storage medium storing a computer program, characterized in that, When the computer program is executed by a processor, it implements the steps of the method as described in any one of claims 1 to 7.

Images