An SDK-based microservice permission information transparent transmission optimization method and system

Abstract

The application relates to the technical field of permission management, in particular to a micro-service permission information transparent transmission optimization method and system based on SDK, which comprises the following steps: developing a general SDK toolkit with built-in token token verification, account permission information acquisition and request forwarding methods; integrating the SDK toolkit in each service end project, and uniformly processing token verification and permission acquisition functions by the SDK; and uniformly taking over the whole-link token verification and permission processing logic by the general SDK toolkit, and transmitting the permission information encrypted as permission information ciphertext with an HTTP request header; the application can realize one-time acquisition of permission data and whole-link multiplexing, greatly reduces the number of database queries, improves the interface response speed, and improves the system performance and user experience.

Description

Technical Field

[0001] This invention relates to the field of permission management technology, and in particular to an optimized method and system for microservice permission information pass-through based on SDK. Background Technology

[0002] In current internet systems, whether applications are business-to-business (ToB), consumer-to-consumer (ToC), or government-to-government (ToG), they all commonly use account systems to manage user permission data. This permission information is usually stored in an underlying persistent database, and the system must query the database whenever it needs to verify user permissions.

[0003] In a microservices architecture, the system is broken down into multiple independent subsystems or modules. A single business request often requires the collaboration of multiple subsystems, and each subsystem may frequently access permission data, resulting in the same permission information being retrieved repeatedly. This repeated querying not only increases the database load and wastes computing and storage resources, but also significantly prolongs the response time of interfaces, impacting overall system performance and user experience.

[0004] To address this issue, existing technologies often employ centralized caching (such as Redis) to store permission data. However, this still presents risks of cross-service network overhead, cache penetration, and cache breakdown. If a service-local caching solution is adopted, the problem of delayed expiration after permission changes arises. If an administrator revokes a user's permissions in the background, the user can still access the service across different microservices before the cache expires, posing a significant security vulnerability. As the system scales up, the conflict between performance and security becomes increasingly prominent, necessitating an efficient and secure solution to optimize the transmission and caching mechanism of permission data. Summary of the Invention

[0005] To overcome the problems of numerous database queries and slow interface response times in existing technologies, which affect overall system performance and user experience, the purpose of this invention is to provide an SDK-based microservice permission information pass-through optimization method and system. This method enables permission data to be acquired once and reused throughout the entire process, significantly reducing the number of database queries, improving interface response speed, and enhancing system performance and user experience.

[0006] This invention is implemented using the following scheme: An optimized method for transparent transmission of microservice permission information based on SDK, the method steps are as follows: Step 1: Create a general SDK toolkit that includes methods for token verification, obtaining account and permission information, and forwarding external requests. Step 2: Integrate the SDK toolkit into all server-side projects, and entrust the token verification and account permission acquisition functions to the SDK toolkit for unified processing; Step 3: When the subsystem receives an HTTP request, it first calls the token verification method in the SDK to perform authentication verification. The token verification method can parse the validity of the token. If the verification fails, it immediately returns an error. Step 4: After the token verification is successful, the SDK will check whether the encrypted permission information already exists in the HTTP request header. If it exists, the encrypted permission information will be decrypted and its integrity verified. If the verification is successful, the plaintext permission information will be obtained. Otherwise, the account ID will be extracted from the token, and the detailed permission information of the account will be obtained. Step 5: After obtaining the account and permission information, the SDK toolkit stores it in plaintext in the local cache and sets a timeout period; Step 6: When a subsystem needs to call data from other subsystems, the SDK toolkit will encrypt the plaintext permission information in the local cache to generate ciphertext permission information, append the token and the ciphertext permission information to the HTTP request header, and forward the HTTP request. Step 7: The external subsystem receiving the HTTP request repeats the process from Step 3 to Step 6, directly decrypting and verifying the encrypted permission information to obtain the plaintext permission information.

[0007] Furthermore, the HTTP request header also includes a mandatory built-in Permission-Version field, which is used to identify the version of the corresponding account's permission data. When an account's permissions change, the server increments the permission version number corresponding to that account.

[0008] Furthermore, the SDK clients of each subsystem establish long-lived connections with the permission management server; when account permissions change, the permission management server pushes permission change notifications to all connected SDK clients through long-lived connections; after receiving the change notification, the SDK client adds the corresponding account ID to the local Bloom filter.

[0009] Furthermore, after the SDK toolkit detects the presence of encrypted permission information in the request header, it also performs the following invalidation verification steps: Extract the account ID and Permission-Version fields from the request header, and input the account ID into the local Bloom filter to perform an existence query; If the Bloom filter hits the account ID, or the extracted Permission-Version field is inconsistent with the latest permission version number in the local record, the SDK will block trust in the current encrypted permission information and jump to step 5 to query the permission database again to obtain the latest account permission information. If the Bloom filter does not match the account ID and the Permission-Version field matches the local version number, then proceed to step 4 for decryption and verification.

[0010] Furthermore, in step 6, the SDK toolkit uses the symmetric key of the current period and a randomly generated Nonce number to encrypt the plaintext using the ChaCha20-Poly1305 encryption algorithm to obtain the ciphertext of the authorization information, and at the same time generates an authentication tag for integrity and authenticity verification. The Nonce and authentication tag are appended to the HTTP request header along with the encrypted permission information and Permission-Version. After receiving the request, the downstream SDK toolkit decrypts and verifies the integrity of the request using the same key, Nonce, and authentication tag.

[0011] An SDK-based microservice permission information pass-through optimization system, the system comprising: an SDK encapsulation module, a project integration and management module, a request authentication and verification module, an encrypted detection and branch processing module, a local cache storage module, a cross-service encrypted forwarding module, and a downstream request loop processing module; The SDK encapsulation module is used to create a general SDK toolkit, which includes a built-in token verification method, a method for obtaining account and permission information, and an external request forwarding method. The project integration and management module is used to integrate the SDK toolkit into all server-side projects, and to uniformly entrust the token verification and account permission acquisition functions to the SDK toolkit. The request authentication and verification module is used to first call the token verification method in the SDK to perform authentication verification when the subsystem receives an HTTP request. The token verification method can parse the validity of the token. If the verification fails, it will immediately return an error. The encrypted detection branch processing module is used to check whether the encrypted permission information already exists in the HTTP request header after the token verification is successful. If it exists, the encrypted permission information is decrypted and its integrity is verified. If the verification is successful, the plaintext permission information is obtained. Otherwise, the account ID is extracted from the token, and the detailed permission information of the account is obtained. The local cache storage module is used to store the account and permission information in plaintext in the local cache after the SDK toolkit obtains the account and permission information, and sets a timeout period. The cross-service encrypted forwarding module is used when a subsystem needs to call data from other subsystems. The SDK toolkit encrypts the plaintext permission information in the local cache to generate ciphertext permission information, appends the token and ciphertext permission information to the HTTP request header, and forwards the HTTP request. The downstream request reuse processing module is used to receive HTTP requests from external subsystems and repeatedly execute the processes of the request authentication and verification module, the ciphertext detection branch processing module, the local cache storage module, and the cross-service encrypted forwarding module. It directly decrypts and verifies the ciphertext of the permission information to obtain the plaintext permission information.

[0012] Furthermore, the HTTP request header also includes a mandatory built-in Permission-Version field, which is used to identify the version of the corresponding account's permission data. When an account's permissions change, the server increments the permission version number corresponding to that account.

[0013] Furthermore, the SDK clients of each subsystem establish long-lived connections with the permission management server; when account permissions change, the permission management server pushes permission change notifications to all connected SDK clients through long-lived connections; after receiving the change notification, the SDK client adds the corresponding account ID to the local Bloom filter.

[0014] Furthermore, after the SDK toolkit detects the presence of encrypted permission information in the request header, it also performs the following invalidation verification steps: Extract the account ID and Permission-Version fields from the request header, and input the account ID into the local Bloom filter to perform an existence query; If the Bloom filter hits the account ID, or if the extracted Permission-Version field is inconsistent with the latest permission version number in the local record, the SDK will block trust in the current encrypted permission information and query the permission database again to obtain the latest account permission information. If the Bloom filter does not match the account ID and the Permission-Version field matches the local version number, the decryption and verification process continues.

[0015] Furthermore, in the cross-service encrypted forwarding module, the SDK toolkit uses the symmetric key of the current period and a randomly generated Nonce random number to encrypt the plaintext using the ChaCha20-Poly1305 encryption algorithm to obtain the ciphertext of the authorization information, and at the same time generates an authentication tag for integrity and authenticity verification. The Nonce and authentication tag are appended to the HTTP request header along with the encrypted permission information and Permission-Version. After receiving the request, the downstream SDK toolkit decrypts and verifies the integrity of the request using the same key, Nonce, and authentication tag.

[0016] The beneficial effects of this invention are as follows: This invention provides an optimized method and system for microservice permission information pass-through based on SDK. Permission information only needs to be queried once at the link entry point. All subsequent downstream subsystems can directly decrypt and reuse the information through the encrypted request header. The entire call chain only requires one database access, which completely solves the problem of resource waste caused by repeated queries across multiple services and significantly shortens the interface response time.

[0017] It also features a lightweight invalidation mechanism, eliminating the need for frequent queries to the centralized cache. Invalidation can be determined locally, and permission change results are converged in milliseconds. This retains the high-performance advantage of local caching while addressing the security vulnerability of untimely permission revocation in traditional TTL caches.

[0018] In this embodiment, the ChaCha20-Poly1305 authentication and encryption algorithm is used to simultaneously achieve encryption and confidentiality of permission data and integrity verification. Combined with random nonce to avoid replay attacks, it ensures that permission information is not tampered with or stolen during transmission between microservices.

[0019] In this invention, all permission processing logic is encapsulated through an SDK toolkit. Business services only need to integrate the SDK to reuse the entire set of capabilities, eliminating the need to repeatedly develop authentication, caching, encryption and other functions, thereby reducing development costs and ensuring that the permission processing logic is consistent throughout the system, thus improving maintainability. Attached Figure Description

[0020] Figure 1 This is a flowchart of the method of the present invention; Figure 2 This is a structural block diagram of the system of the present invention. Detailed Implementation

[0021] The invention will now be further described with reference to the accompanying drawings.

[0022] See Figure 1 An optimization method for microservice permission information pass-through based on SDK, the method steps are as follows: Step 1: Create a general SDK toolkit that includes methods for token verification, obtaining account and permission information, and forwarding external requests. Step 2: Integrate the SDK toolkit into all server-side projects, and entrust the token verification and account permission acquisition functions to the SDK toolkit for unified processing; Step 3: When the subsystem receives an HTTP request, it first calls the token verification method in the SDK to perform authentication verification. The token verification method can parse the validity of the token. If the verification fails, it immediately returns an error. Step 4: After the token verification is successful, the SDK will check whether the encrypted permission information already exists in the HTTP request header. If it exists, the encrypted permission information will be decrypted and its integrity verified. If the verification is successful, the plaintext permission information will be obtained. Otherwise, the account ID will be extracted from the token, and the detailed permission information of the account will be obtained. Step 5: After obtaining the account and permission information, the SDK toolkit stores it in plaintext in the local cache and sets a timeout period; Step 6: When a subsystem needs to call data from other subsystems, the SDK toolkit will encrypt the plaintext permission information in the local cache to generate ciphertext permission information, append the token and the ciphertext permission information to the HTTP request header, and forward the HTTP request. Step 7: The external subsystem receiving the HTTP request repeats the process from Step 3 to Step 6, directly decrypting and verifying the encrypted permission information to obtain the plaintext permission information.

[0023] The present invention will be further described below with reference to a specific embodiment: An optimization method for microservice permission information pass-through based on SDK, the method comprising the following steps: Step 1: Taking Java as an example, develop a general-purpose SDK toolkit. This toolkit includes built-in methods for token verification, account permission information retrieval, and request forwarding. The SDK design must ensure high availability and compatibility, facilitate integration with different server-side projects, and provide clear API interfaces to support flexible permission data processing and encryption operations, laying the foundation for subsequent permission information pass-through mechanisms.

[0024] Step 2: Each server-side project in the microservice architecture integrates the SDK toolkit, and the token verification and account permission acquisition functions are uniformly handled by the SDK toolkit. Through standardized integration, consistency in permission verification and data transmission across system modules is ensured, reducing redundant development work and improving the overall maintainability and scalability of the system.

[0025] Step 3: When the subsystem receives an HTTP request, it first calls the token verification method in the SDK for authentication. This method parses the token's validity and verifies the legitimacy of the request source. If the verification fails, it immediately returns an error, thereby ensuring system security and blocking unauthorized access.

[0026] Step 4: After successful token verification, the SDK checks whether the encrypted authorization information already exists in the HTTP request header. If the request header contains encrypted permission information, the encrypted permission information is decrypted and its integrity is verified. Once the verification is successful, the plaintext permission information is obtained directly without having to query the permission database again. If the request header does not contain encrypted permission information, the account ID is extracted from the token, and detailed permission information for the account is obtained through the interface or by directly querying the database to ensure data accuracy and real-time performance.

[0027] Step 5: After obtaining the account and permission information, the SDK toolkit stores the account and permission information in plaintext in the local cache as plaintext permission information, and sets a reasonable timeout period. This mechanism helps subsequent requests within the same service to quickly read permission data, reducing duplicate database queries. At the same time, the timeout mechanism avoids the long-term retention of expired data, balancing performance and data consistency.

[0028] The local caching TTL mechanism poses a risk of inconsistent permission data: if an administrator revokes a user's permissions in the background, the user can still access various microservices before the cache expires because the SDK has a local cache and downstream services rely on the encrypted permission information passed through the request header. This presents a security vulnerability.

[0029] To address this issue, this solution introduces a failure mechanism that combines Permission-Version permission version number comparison with a Bloom filter, as implemented below: The HTTP request header includes a mandatory built-in Permission-Version field along with the encrypted permission information. This field identifies the version of the corresponding account's permission data. When an administrator modifies user permissions, the permission management server increments the user's permission version number.

[0030] Each SDK client establishes a long connection with the permission management server. When the permission management server modifies the permission information of an account, it will push a permission change notification to all connected clients through the long connection. After receiving the notification, the client adds the corresponding account ID to the blacklist set of the local Bloom filter.

[0031] Here, the permission management server specifically refers to the unified authentication and authorization center or permission management service, which has write permissions to the permission database, is responsible for maintaining long-lived connections (such as WebSocket and TCP long connections) with all SDK clients, and actively pushes notifications when permissions change.

[0032] When a request carrying encrypted permission information arrives at a downstream subsystem, the downstream SDK toolkit first performs an invalidation check: it extracts the account ID and Permission-Version fields from the request header, inputs the account ID into a local Bloom filter for an existence check; if the Bloom filter matches the account ID, or if the extracted Permission-Version does not match the latest permission version number recorded locally, the SDK toolkit actively blocks trust in the current encrypted permission information, forces a new query to the database to obtain the latest permissions, and updates the encrypted permission information and version number in the local cache and request header; if the Bloom filter does not match the account ID and the Permission-Version matches the local version number, it directly trusts the transmitted encrypted permission information and continues the decryption verification process.

[0033] In this context, the "hit" of the Bloom filter refers to the data structure determining that the account ID may exist in the blacklist set, rather than comparing the encrypted content; this mechanism can achieve millisecond-level permission convergence without reducing performance.

[0034] Step 6: When a subsystem needs to access data from a downstream subsystem, the SDK toolkit encrypts the plaintext permission information in the local cache to generate ciphertext permission information. It then automatically appends the token and the ciphertext permission information to the HTTP request header via a request forwarding method, completing the request forwarding. This mechanism ensures the security and integrity of permission data during transmission.

[0035] The ciphertext of the authorization information is generated using the ChaCha20-Poly1305 symmetric encryption algorithm. A symmetric key and a randomly generated nonce are used to convert the plaintext of authorization information into ciphertext of authorization information, and an authentication tag is generated for verification. During decryption, the same key and nonce are used to perform the decryption operation, and the integrity and authenticity of the data are verified by the authentication tag.

[0036] All SDK clients and the permission management server share the same source key. The encrypted authentication tag is included as an independent field in the HTTP request header along with the encrypted permission information for downstream SDK toolkits to decrypt and verify.

[0037] In conjunction with the ChaCha20-Poly1305 encryption algorithm, this scheme introduces a decentralized dynamic key derivation and smooth rotation mechanism based on the key derivation function KDF (existing technology): each microservice node independently calculates the encryption and decryption key for the current period based on a unified key seed and a preset time window through the key derivation function KDF, and can achieve smooth periodic rotation of the key without frequent communication with the centralized key management service.

[0038] The downstream subsystem receiving the HTTP request repeats the processing flow from step 3 to step 6. However, since the request header already contains encrypted permission information, the subsystem does not need to retrieve permission information from the database again. It can directly decrypt and verify the encrypted permission information to obtain the plaintext permission information, thereby significantly reducing resource consumption and response latency.

[0039] Through the above steps, efficient transmission and sharing of permission information are achieved. In theory, the entire call chain only needs to acquire permissions once to support the collaboration of multiple subsystems, effectively reducing database load and improving interface response speed and overall system performance.

[0040] See Figure 2 An SDK-based microservice permission information pass-through optimization system, the system includes: an SDK encapsulation module, a project integration and management module, a request authentication and verification module, an encrypted detection and branch processing module, a local cache storage module, a cross-service encrypted forwarding module, and a downstream request loop processing module; The SDK encapsulation module is used to create a general SDK toolkit, which includes a built-in token verification method, a method for obtaining account and permission information, and an external request forwarding method. The project integration and management module is used to integrate the SDK toolkit into all server-side projects, and to uniformly entrust the token verification and account permission acquisition functions to the SDK toolkit. The request authentication and verification module is used to first call the token verification method in the SDK to perform authentication verification when the subsystem receives an HTTP request. The token verification method can parse the validity of the token. If the verification fails, it will immediately return an error. The encrypted detection branch processing module is used to check whether the encrypted permission information already exists in the HTTP request header after the token verification is successful. If it exists, the encrypted permission information is decrypted and its integrity is verified. If the verification is successful, the plaintext permission information is obtained. Otherwise, the account ID is extracted from the token, and the detailed permission information of the account is obtained. The local cache storage module is used to store the account and permission information in plaintext in the local cache after the SDK toolkit obtains the account and permission information, and sets a timeout period. The cross-service encrypted forwarding module is used when a subsystem needs to call data from other subsystems. The SDK toolkit encrypts the plaintext permission information in the local cache to generate ciphertext permission information, appends the token and ciphertext permission information to the HTTP request header, and forwards the HTTP request. The downstream request reuse processing module is used to receive HTTP requests from external subsystems and repeatedly execute the processes of the request authentication and verification module, the ciphertext detection branch processing module, the local cache storage module, and the cross-service encrypted forwarding module. It directly decrypts and verifies the ciphertext of the permission information to obtain the plaintext permission information.

[0041] In one embodiment of the present invention, the HTTP request header also includes a mandatory built-in Permission-Version field, which is used to identify the version of the corresponding account permission data, and when the account permissions change, the server increments the permission version number corresponding to the account.

[0042] In one embodiment of the present invention, the SDK client of each subsystem establishes a long connection with the permission management server; when account permissions change, the permission management server pushes a permission change notification to all connected SDK clients through the long connection; after receiving the change notification, the SDK client adds the corresponding account ID to the local Bloom filter.

[0043] In one embodiment of the present invention, after the SDK detects that there is encrypted permission information in the request header, it also performs the following invalidation verification steps: Extract the account ID and Permission-Version fields from the request header, and input the account ID into the local Bloom filter to perform an existence query; If the Bloom filter hits the account ID, or if the extracted Permission-Version field is inconsistent with the latest permission version number in the local record, the SDK will block trust in the current encrypted permission information and query the permission database again to obtain the latest account permission information. If the Bloom filter does not match the account ID and the Permission-Version field matches the local version number, the decryption and verification process continues.

[0044] In one embodiment of the present invention, in the cross-service encrypted forwarding module, the SDK toolkit uses the symmetric key of the current period and a randomly generated Nonce random number to encrypt the plaintext using the ChaCha20-Poly1305 encryption algorithm to obtain the ciphertext of the authorization information, and at the same time generates an authentication tag for integrity and authenticity verification. The Nonce and authentication tag are appended to the HTTP request header along with the encrypted permission information and Permission-Version. After receiving the request, the downstream SDK toolkit decrypts and verifies the integrity of the request using the same key, Nonce, and authentication tag.

[0045] The above description is only a preferred embodiment of the present invention. All equivalent changes and modifications made within the scope of the claims of the present invention should be included in the scope of the present invention.

Claims

1. A method for optimizing the transparent transmission of microservice permission information based on SDK, characterized in that, The method steps are as follows: Step 1: Create a general SDK toolkit that includes methods for token verification, obtaining account and permission information, and forwarding external requests. Step 2: Integrate the SDK toolkit into all server-side projects, and entrust the token verification and account permission acquisition functions to the SDK toolkit for unified processing; Step 3: When the subsystem receives an HTTP request, it first calls the token verification method in the SDK to perform authentication verification. The token verification method can parse the validity of the token. If the verification fails, it immediately returns an error. Step 4: After the token verification is successful, the SDK will check whether the encrypted permission information already exists in the HTTP request header. If it exists, the encrypted permission information will be decrypted and its integrity verified. If the verification is successful, the plaintext permission information will be obtained. Otherwise, the account ID will be extracted from the token, and the detailed permission information of the account will be obtained. Step 5: After obtaining the account and permission information, the SDK toolkit stores it in plaintext in the local cache and sets a timeout period; Step 6: When a subsystem needs to call data from other subsystems, the SDK toolkit will encrypt the plaintext permission information in the local cache to generate ciphertext permission information, append the token and the ciphertext permission information to the HTTP request header, and forward the HTTP request. Step 7: The external subsystem receiving the HTTP request repeats the process from Step 3 to Step 6, directly decrypting and verifying the encrypted permission information to obtain the plaintext permission information.

2. The method for optimizing the transparent transmission of microservice permission information based on SDK according to claim 1, characterized in that, The HTTP request header also includes a mandatory built-in Permission-Version field, which is used to identify the version of the corresponding account's permission data. When an account's permissions change, the server increments the permission version number corresponding to that account.

3. The method for optimizing the transparent transmission of microservice permission information based on SDK according to claim 2, characterized in that, Each subsystem's SDK client establishes a long connection with the permission management server; when account permissions change, the permission management server pushes permission change notifications to all connected SDK clients through the long connection. After receiving the change notification, the SDK client adds the corresponding account ID to the local Bloom filter.

4. The method for optimizing the transparent transmission of microservice permission information based on SDK according to claim 3, characterized in that, After the SDK detects the presence of encrypted permission information in the request header, it also performs the following invalidation verification steps: Extract the account ID and Permission-Version fields from the request header, and input the account ID into the local Bloom filter to perform an existence query; If the Bloom filter hits the account ID, or the extracted Permission-Version field is inconsistent with the latest permission version number in the local record, the SDK will block trust in the current encrypted permission information and jump to step 5 to query the permission database again to obtain the latest account permission information. If the Bloom filter does not match the account ID and the Permission-Version field matches the local version number, then proceed to step 4 for decryption and verification.

5. The method for optimizing the transparent transmission of microservice permission information based on SDK according to claim 2, characterized in that, In step 6, the SDK toolkit uses the symmetric key of the current period and a randomly generated Nonce number to encrypt the plaintext using the ChaCha20-Poly1305 encryption algorithm to obtain the ciphertext of the authorization information, and at the same time generates an authentication tag for integrity and authenticity verification. The Nonce and authentication tag are appended to the HTTP request header along with the encrypted permission information and Permission-Version. After receiving the data, the downstream SDK toolkit decrypts and verifies the integrity using the same key, nonce, and authentication tag.

6. A microservice permission information pass-through optimization system based on SDK, characterized in that, The system includes: an SDK encapsulation module, a project integration and management module, a request authentication and verification module, a ciphertext detection and branch processing module, a local cache storage module, a cross-service encrypted forwarding module, and a downstream request loop processing module; The SDK encapsulation module is used to create a general SDK toolkit, which includes a built-in token verification method, a method for obtaining account and permission information, and an external request forwarding method. The project integration and management module is used to integrate the SDK toolkit into all server-side projects, and to uniformly entrust the token verification and account permission acquisition functions to the SDK toolkit. The request authentication and verification module is used to first call the token verification method in the SDK to perform authentication verification when the subsystem receives an HTTP request. The token verification method can parse the validity of the token. If the verification fails, it will immediately return an error. The encrypted detection branch processing module is used to check whether the encrypted permission information already exists in the HTTP request header after the token verification is successful. If it exists, the encrypted permission information is decrypted and its integrity is verified. If the verification is successful, the plaintext permission information is obtained. Otherwise, the account ID is extracted from the token, and the detailed permission information of the account is obtained. The local cache storage module is used to store the account and permission information in plaintext in the local cache after the SDK toolkit obtains the information, and sets a timeout period. The cross-service encrypted forwarding module is used when a subsystem needs to call data from other subsystems. The SDK toolkit encrypts the plaintext permission information in the local cache to generate ciphertext permission information, appends the token and ciphertext permission information to the HTTP request header, and forwards the HTTP request. The downstream request reuse processing module is used to receive HTTP requests from external subsystems and repeatedly execute the processes of the request authentication and verification module, the ciphertext detection branch processing module, the local cache storage module, and the cross-service encrypted forwarding module. It directly decrypts and verifies the ciphertext of the permission information to obtain the plaintext permission information.

7. The SDK-based microservice permission information pass-through optimization system according to claim 6, characterized in that, The HTTP request header also includes a mandatory built-in Permission-Version field, which is used to identify the version of the corresponding account's permission data. When an account's permissions change, the server increments the permission version number corresponding to that account.

8. The SDK-based microservice permission information pass-through optimization system according to claim 7, characterized in that, Each subsystem's SDK client establishes a long connection with the permission management server; when account permissions change, the permission management server pushes permission change notifications to all connected SDK clients through the long connection. After receiving the change notification, the SDK client adds the corresponding account ID to the local Bloom filter.

9. The SDK-based microservice permission information pass-through optimization system according to claim 8, characterized in that, After the SDK detects the presence of encrypted permission information in the request header, it also performs the following invalidation verification steps: Extract the account ID and Permission-Version fields from the request header, and input the account ID into the local Bloom filter to perform an existence query; If the Bloom filter hits the account ID, or if the extracted Permission-Version field is inconsistent with the latest permission version number recorded locally, the SDK will block trust in the current encrypted permission information and redirect to query the permission database again to obtain the latest account permission information. If the Bloom filter does not match the account ID and the Permission-Version field matches the local version number, the decryption and verification process continues.

10. A microservice permission information pass-through optimization system based on SDK according to claim 9, characterized in that, In the cross-service encrypted forwarding module, the SDK toolkit uses the symmetric key of the current period and a randomly generated Nonce random number to encrypt the plaintext using the ChaCha20-Poly1305 encryption algorithm to obtain the ciphertext of the authorization information, and at the same time generates an authentication tag for integrity and authenticity verification. The Nonce and authentication tag are appended to the HTTP request header along with the encrypted permission information and Permission-Version. After receiving the data, the downstream SDK toolkit decrypts and verifies the integrity using the same key, nonce, and authentication tag.

Images