Identity authentication access system and method based on post-quantum hybrid signature and authorization code

Abstract

The application discloses an identity authentication access system and method based on a post-quantum hybrid signature and an authorization code, and belongs to the technical field of information security. The application aims to solve the problems of the lack of anti-quantum computing capability, the difficulty of post-quantum password migration and the insufficient security of the device authorization process of the existing OAuth 2.0 authorization framework. The system comprises a key management module, a authorization server and an API gateway. The API gateway is used for double signature verification of the hybrid signature JWT and forwards the extracted declaration information to the downstream service through the HTTP request header. The hybrid signature JWT generated by the application is completely consistent with the standard JWT in external format, maintaining compatibility with existing systems. The centralized verification of the post-quantum signature and the forwarding of the declaration by the API gateway significantly reduce the post-quantum migration cost of the business system. The application can be widely applied to identity authentication and Internet of Things device authorization scenarios that require quantum security.

Description

Technical Field This invention relates to the fields of information security and identity authentication technology, specifically to a hybrid signature authentication method and system based on post-quantum cryptography (PQC), and a device authorization authentication method and system based on the hybrid signature method. Background Technology The development of quantum computing poses a security threat to traditional signature and authentication systems based on RSA and elliptic curve cryptography (ECC). To address this threat, the National Institute of Standards and Technology (NIST) has been continuously advancing the standardization of post-quantum cryptography in recent years, releasing its first batch of post-quantum cryptography standards in 2024, including the FIPS 204 standard (Modular Lattice-Based Digital Signature Algorithm, ML-DSA). As one of the first post-quantum signature algorithms standardized by NIST, ML-DSA is effectively resistant to known quantum computing attacks.

[0001] However, the existing technology has the following main problems: 1. The Real-World Challenges of Post-Quantum Migration: Post-quantum signatures generate signatures with significantly longer byte lengths than traditional algorithms (e.g., the ML-DSA-65 standard generates signatures of approximately 3300 bytes, while traditional ECDSA signatures are only around 70 bytes). Direct replacement would lead to performance bottlenecks and even compatibility issues in existing systems regarding data transmission, storage, and processing. Furthermore, many existing application systems, middleware, and security gateways are already deeply integrated with classical algorithms, making replacement a massive undertaking with high risks.

[0002] 2. The existing OAuth 2.0 authorization framework lacks post-quantum protection: The OAuth 2.0 framework itself does not involve specific signature algorithms, relying on underlying secure transmission protocols such as TLS and the signature scheme used in the user authentication process to ensure the unforgeability of credentials. Existing OAuth 2.0-based authorization servers, resource servers, and token formats (JWT) lack support for post-quantum signature algorithms, directly facing the security threat of "steal first, then decrypt".

[0003] 3. Lack of a smooth post-quantum migration path: Currently, there is a lack of solutions on the market that can provide both post-quantum security strength and compatibility with the existing OAuth 2.0 / JWT ecosystem, which makes it impossible for most systems to smoothly transition from classical cryptography to post-quantum cryptography.

[0004] 4. Insufficient security of device authentication: In IoT scenarios, input-restricted devices obtain access tokens through the OAuth 2.0 device authorization code process. However, the key credentials in this process lack a unified anti-tampering and non-repudiation protection mechanism, which faces security risks such as credential forgery and man-in-the-middle attacks.

[0005] Therefore, there is an urgent need to provide a hybrid signature authentication system and method that is resistant to quantum computing attacks and supports device authorization code processes while maintaining full compatibility with the existing JWT ecosystem. Summary of the Invention (a) Purpose of the invention The purpose of this invention is to solve the problems of difficult post-quantum cryptography migration in existing distributed identity authentication systems, lack of post-quantum protection in the OAuth2.0 framework, and insufficient security of device authorization processes. It provides a hybrid signature identity authentication system and method that is resistant to quantum computing attacks and supports device authorization code processes while maintaining full compatibility with the existing JWT ecosystem.

[0006] (II) Technical Solution To achieve the above objectives, this invention provides a distributed identity authentication and access control system based on a post-quantum hybrid signature and authorization code mechanism, the system comprising: Key management module: configured to store at least one first key pair of a classical signature algorithm and at least one second key pair of a post-quantum signature algorithm in the key storage area, and provide a hybrid signature generation interface and a hybrid signature verification interface.

[0007] Authorization server: Configured to generate a hybrid signature JWT using the first key pair and the second key pair through the hybrid signature generation interface of the key management module. The authorization server also includes a device authorization module, configured to receive device authorization requests from input-restricted devices, generate and associate a device code and a user code, and after the user verifies the user code and approves the authorization through a user terminal, call the authorization server to generate a hybrid signature JWT as an access token.

[0008] API Gateway: Configured to perform dual signature verification on the hybrid signature JWT through the hybrid signature verification interface of the key management module, and extract the claim information from the JWT payload after successful verification, and forward it to the downstream service through the HTTP request header.

[0009] Furthermore, the header of the hybrid signature JWT contains an algorithm identifier that uniquely identifies the hybrid signature; the signature segment of the hybrid signature JWT contains a hybrid signature value formed by superimposing and combining a first signature value generated by the first key pair and a second signature value generated by the second key pair according to a predetermined rule.

[0010] Furthermore, the declaration information extracted by the API gateway includes at least one or more of the following: user identifier, permission scope, and device identifier; the declaration information is added to the forwarding request after being mapped through preset HTTP request header field names.

[0011] Furthermore, the key management module exposes the first public key of the first key pair and the second public key of the second key pair to the JWK Set endpoint when the system starts up, for the API gateway to download and cache.

[0012] This invention also provides a distributed identity authentication method based on post-quantum hybrid signatures and authorization code mechanisms, characterized by comprising: Key generation steps: Generate and store the first key pair for the classical signature algorithm and the second key pair for the post-quantum signature algorithm in the key storage area; Token generation steps: In response to the authorization request, the hybrid signature generation interface is called to generate a hybrid signature JWT using the first key pair and the second key pair; Token verification steps: In response to the API request carrying the hybrid signature JWT, the hybrid signature verification interface is called to perform dual signature verification on the hybrid signature JWT using the first public key of the first key pair and the second public key of the second key pair; Claim forwarding steps: After the dual signature verification is successful, the claim information is extracted from the payload of the hybrid signature JWT and forwarded to the downstream service via the HTTP request header.

[0013] Furthermore, the method also includes a device authorization step: in response to a device authorization request from an input-restricted device, generating and associating a device code and a user code; in response to the user's verification and approval of the user code via a user terminal, performing the token generation step.

[0014] Furthermore, the token generation step further includes: constructing a JWT header, wherein the algorithm field is set to a hybrid signature algorithm identifier; constructing a JWT payload; generating a first signature value using the first private key of the first key pair; generating a second signature value using the second private key of the second key pair; combining the first signature value and the second signature value into a single hybrid signature value; and encoding the header, payload, and hybrid signature value into a three-segment structure.

[0015] Furthermore, the dual signature verification step further includes: parsing the header, payload, and mixed signature value from the mixed signature JWT; separating the first signature value and the second signature value from the mixed signature value; verifying the first signature value using the first public key; verifying the second signature value using the second public key; and determining the token to be valid only when both are verified successfully.

[0016] Furthermore, the claim forwarding step further includes: extracting one or more of the user identifier, permission scope, and device identifier from the JWT payload; mapping the extracted claim information to preset HTTP request header field names; and adding the request header fields to the HTTP request forwarded to the downstream service.

[0017] (III) Beneficial Effects Compared with the prior art, the present invention has the following beneficial technical effects: 1. Achieving Smooth Transition to Post-Quantum Security: This invention employs a hybrid signature technology scheme, generating JWTs that are visually identical to standard JWTs. Existing system components that only support classical algorithms can correctly parse their headers and payloads. Simultaneously, the dual-signature verification mechanism of this invention requires all dependent parties to upgrade their verification capabilities before accepting tokens, creating a mandatory security upgrade effect. This ensures the full implementation of post-quantum security strength while avoiding destructive system modifications.

[0018] 2. Significantly Reduced System Migration Costs: By centralizing the verification logic of hybrid signature JWTs at the API gateway layer, downstream business microservices can obtain user identity and authorization information without integrating any post-quantum cryptography libraries. In a system containing dozens or even hundreds of microservices, this design reduces the migration effort from modifying each microservice to upgrading only the API gateway component, significantly lowering the implementation costs and risks of post-quantum migration.

[0019] 3. Ensuring end-to-end security for device authorization: This invention is the first to integrate hybrid signature technology into the OAuth 2.0 device authorization code process, providing non-repudiation and tamper-proof protection against quantum computing for authorization credentials in IoT input-restricted scenarios, filling a technological gap in this field.

[0020] 4. Maintaining standardization and compatibility: This invention fully complies with the OAuth 2.0 framework and related RFC standards (RFC6749, RFC 8628, etc.). The authorization process requires minimal changes to existing OAuth 2.0 clients and resource servers, and smooth integration can be achieved through declarative forwarding via the API gateway layer.

[0021] 5. Improved system security: This invention maintains classical and post-quantum keys separately in the key storage area. If one algorithm is compromised, the other algorithm can still provide security, effectively resisting the long-term security threat of "stealing first and then decrypting". Attached Figure Description (The details in this section will be implemented in the accompanying drawings; only the names of the drawings and their corresponding descriptions are listed here.) Figure 1A schematic diagram of the physical deployment architecture of a distributed identity authentication and access control system based on post-quantum hybrid signature and authorization code mechanism.

[0022] Figure 2 Flowchart of the hybrid signature JWT generation and verification method.

[0023] Figure 3 : Interaction sequence diagram of the device authorization code process.

[0024] Figure 4 Flowchart of API gateway signature verification and declaration forwarding method.

[0025] Figure 5 A diagram comparing the hybrid signature JWT format with the standard JWT format.

[0026] Figure 6 : Schematic diagram of the backend key storage area structure.

[0027] Figure 7 : Schematic diagram of the superposition encoding format of classical signature and post-quantum signature data. Detailed Implementation

[0028] To make the objectives, technical solutions, and advantages of this invention clearer, the invention will be further described in detail below with reference to the accompanying drawings and embodiments. The following embodiments are for illustrative purposes only and do not constitute a limitation on the scope of protection of this invention.

[0029] Example 1: System Architecture and Deployment Method like Figure 1 As shown, this embodiment adopts a microservice architecture deployment, and the system includes the following components: • MySQL database (auth_db): Serves as the storage unit for persistent data such as user accounts, roles, and OAuth 2.0 client configurations for the authorization server.

[0030] • PostgreSQL database (product_db): Serves as the business data storage unit for product service (product 1). It should be noted that the data storage method for downstream business services (relational database, non-relational database, key-value store, etc.) is not a limiting feature of this invention.

[0031] • Authorization Server (auth server): A Java application service built on Spring Boot 3.5.14, Spring Authorization Server 1.5.7, and Spring Security 6.5.10 frameworks. It is responsible for core authorization functions such as key management, user authentication, OAuth 2.0 token issuance (including device authorization code processing), and hybrid signature JWT generation. This server is containerized and exposes its service port 9090.

[0032] • API Gateway: A reactive API gateway built on Spring Cloud Gateway and Spring WebFlux. As the system's sole entry point, it is responsible for request routing, centralized verification of hybrid signed JWTs, extraction of verified claims and HTTP header forwarding, and role / permission-based access control. This server is containerized and exposes its service port 8222.

[0033] • Config server: Provides centralized configuration management for all microservices.

[0034] • Service Registry and Discovery Center (discovery): A service registration and discovery component based on Netflix Eureka, providing dynamic service location capabilities for microservice architectures. It exposes management port 8761 for monitoring service registration status and cluster health checks.

[0035] • Product Service (product-1): One of the downstream business microservices, responsible for CRUD operations on product data. This service uses the Spring WebFlux and R2DBC reactive data access technology stack, is containerized, and uses port 8181 internally. This port is not exposed externally and is only used for internal cluster communication and health checks.

[0036] • Device Service (device-1): One of the downstream business microservices, responsible for device status reporting and telemetry data collection. It uses the Spring WebFlux reactive technology stack and is deployed in a containerized manner. The internal service port is 8182, which is not exposed to the outside world and is only used for internal cluster communication and health checks.

[0037] The call relationships between services are as follows: API requests first arrive at the API gateway, and after hybrid signature verification, are routed to the product service or device service according to the request path; the product service and device service read the user / device identifier and authorization scope information from the request header forwarded by the gateway, and execute the corresponding business logic; all microservices register their own instances with the registry and discovery center, and the gateway performs service discovery and load balancing through the registry and discovery center; the configuration server provides runtime configuration for each microservice; the authorization server communicates with the MySQL database for persistent storage and querying of user information and client configuration; the product service communicates with the PostgreSQL database for persistent storage and querying of product business data. All external API requests must enter the system through the API gateway (external port 8222). After the gateway completes the mixed signature JWT verification, it routes the request to the corresponding internal port (8181 or 8182) of the internal service (product-1 or device-1). Internal services must not directly expose ports to the external network.

[0038] Example 2: Key Generation and Initialization Process This embodiment describes in detail how the key management module in the authorization server completes the generation, storage, and management of keys. like Figure 6 As shown, in the key store area (in this embodiment, a keystore file keystore.p12 in PKCS#12 format), key pairs for the classical ECDSA algorithm and the post-quantum ML-DSA algorithm are generated using the Bouncy Castle cryptographic library (version 1.84). The ECDSA key pair is used for the first signature, and the ML-DSA key pair is used for the second signature. The generated classical and post-quantum key pairs are stored in the key store area and labeled with different aliases (in this embodiment, the aliases are "ecdsa-key" and "mldsa-key"). The key store area is protected by passwords (store-pass and key-pass) to prevent unauthorized access.

[0039] When the authorization server starts, it loads the key store through the key management module and exposes the classical public key and the post-quantum public key to externally accessible JWK Set endpoints ( / oauth2 / jwks and / oauth2 / jwks / internal) for the API gateway and downstream resource servers to download and cache the public key information. The hybrid signature generation (hybridSign) interface and hybrid signature verification (hybridVerify) interface of the key management module encapsulate the generation and verification logic of the first and second signatures, respectively, shielding the internal combination details from upper-layer callers.

[0040] Example 3: Method for Generating Hybrid Signature JWTs like Figure 2 As shown in the upper part, the hybrid signature JWT generation method of this embodiment specifically includes: (1) After the user completes authentication or the device authorization process is approved by the user, the token generation module of the authorization server receives a token generation request.

[0041] (2) Construct the header of the JWT, which includes a key identifier (kid) field and an algorithm (alg) field. The value of the algorithm field is uniquely set to "HYBRID-ECDSA-MLDSA" to identify that this JWT uses a hybrid signature of classical ECDSA and post-quantum ML-DSA.

[0042] (3) Construct the payload part of the JWT, declare the issuer (iss), subject (sub), audience (aud), JWT identifier (jti), expiration time (exp), issuance time (iat) and other information according to the OAuth 2.0 standard, and add custom declarations such as the scope of permissions according to the authorization type.

[0043] (4) Call the hybrid signature interface of the key management module, use the classical private key to perform a first signature on the combination of header and payload data, and generate a first signature value; use the post-quantum private key to perform a second signature on the same combination of header and payload data, and generate a second signature value.

[0044] (5) Combine the first signature value and the second signature value according to a predetermined encoding rule. For example... Figure 7 As shown, in this embodiment, the second signature value is appended to the first signature value to form a single mixed signature value using the "splitting and overlay" method.

[0045] (6) In accordance with the JWT specification, the header, payload and hybrid signature value are Base64URL encoded and concatenated with a dot (.) to generate the final hybrid signature JWT string.

[0046] Compared to alternatives that place the two signature values ​​as independent fields in the JWT header, the single-signature slot composite technology of this invention can ensure that the hybrid signature JWT maintains the same external three-segment structure as the standard JWT, and maintains maximum compatibility with existing resource servers that only support classic signature algorithm verification.

[0047] Example 4: Device Authorization Code Interaction Process like Figure 3 As shown, the complete interaction sequence of the input-restricted device obtaining the hybrid signature access token through the device authorization code process in this embodiment is as follows: (1) The client device sends a device authorization request to the device authorization endpoint ( / oauth2 / device_authorization) of the authorization server. The request includes the client identifier (client_id), the authorization type (grant_type=device_code), and the requested permission scope (scope=device:read). The request carries the client credentials using HTTPBasic authentication.

[0048] (2) The authorization server verifies the client's identity and the validity of the request parameters, and generates a unique user code (user_code) and device code (device_code). The user code is a short, readable code that is easy for the user to input (e.g., "PWDM-LJPG"), and the device code is a long, unreadable random string. The authorization server establishes a mapping relationship between the user code and the authorization session in the session storage area.

[0049] (3) The authorization server returns a device authorization response to the client device, which includes fields such as device code, user code, verification URI (verification_uri), and expiration date (expires_in). The client device saves the device code for subsequent polling and displays the verification URI and user code to the user.

[0050] (4) Users access the verification URI through their user terminals (such as smartphones, laptops, and other devices that support a full browser), enter the device authorization page, and enter their user code to complete identity authentication (login). (5) After verifying the validity of the user code, the authorization server displays the scope of permissions requested by the client device to the user and requests the user's approval. After verifying that the user code matches the one displayed on the device, the user clicks the "Approve" button to confirm the authorization.

[0051] (6) After the user completes the approval, the authorization server marks the device authorization request as "approved". The client device sends a token acquisition request to the token endpoint ( / oauth2 / token) of the authorization server in a polling manner. The request carries the authorization type (grant_type=urn:ietf:params:oauth:grant-type:device_code), device code and client identifier.

[0052] (7) After receiving the token request, the authorization server checks the authorization status corresponding to the device code. If the user has not yet approved, it returns the "authorization_pending" error; if the user has approved, it calls the hybrid signature JWT generation method described in Example 3 to issue a hybrid signature access token (and optional refresh token) using the classic private key and the post-quantum private key.

[0053] (8) The authorization server returns a success response to the client device containing the access_token field, where the value of the access_token field is a mixed-signature JWT.

[0054] Example 5: API Gateway Signature Verification and Declaration Forwarding Method like Figure 4 As shown, in this embodiment, the workflow of the API gateway completing the hybrid signature JWT verification and forwarding the claim to the downstream service is as follows: (1) The API gateway downloads and caches the classic public key and the post-quantum public key from the JWK Set endpoint ( / oauth2 / jwks) of the authorization server for subsequent signature verification.

[0055] (2) The API gateway intercepts the HTTP API request sent by the client and extracts the Bearer token from the Authorization field of the request header. The token is a mixed-signature JWT.

[0056] (3) The API gateway parses the hybrid signature JWT and separates the header, payload and hybrid signature value.

[0057] (4) The API gateway separates the first signature value (ECDSA signature) and the second signature value (ML-DSA signature) from the mixed signature value. (5) The API gateway uses the cached classic public key to verify the validity of the first signature value and the post-quantum public key to verify the validity of the second signature value. The token is considered valid only if both signature values ​​are verified; otherwise, HTTP401 Unauthorized is returned.

[0058] (6) If the token is valid, the API gateway extracts the identity and permission claims from the JWT payload. In this embodiment, at least the following claims are extracted: sub (subject identifier, such as user email or device identifier), scope (list of permission scopes, such as "device:read" or "device:write"), and device_id (device identifier, which exists only in tokens issued through the device authorization code process). (7) The API gateway adds the extracted claim information to the requests forwarded to downstream services via HTTP request header fields. The specific mapping relationship is as follows: sub claim is mapped to X-User-Id request header; scope claim is mapped to X-Scope request header (multiple permissions are separated by commas); device_id claim is mapped to X-Device-Id request header.

[0059] (8) The API gateway forwards the request with the added request header to the corresponding downstream microservice based on the request path.

[0060] (9) The downstream microservice receives the request, reads the X-User-Id, X-Scope, and X-Device-Id fields from the HTTP request header, and executes the business logic based on this information. The downstream microservice does not need to integrate any post-quantum cryptography library, nor does it need to have any hybrid signature verification capabilities.

[0061] Example 6: Implementation of Downstream Microservices This embodiment further illustrates the specific implementation method of downstream microservices. Taking downstream device service (device-1) as an example: (1) The device-1 service is built on Spring Boot 3.5.14 and Spring WebFlux. It is a reactive web application that listens on port 8182 and registers its own instance with the service registry and discovery center.

[0062] (2) The controller of the device-1 service (DeviceController) provides an HTTP GET endpoint " / devices / status", which receives three optional request header fields: X-Device-Id, X-Scope and X-User-Id, and returns a response body in JSON format containing device identifier, permission scope and status information.

[0063] (3) When device-1 service receives a request from the API gateway, the controller method reads the X-Device-Id and X-Scope fields from the request header using the @RequestHeader annotation. If the X-Device-Id field exists in the request header, the controller method returns the device identifier as part of the response; if the X-Device-Id field does not exist in the request header, the default value "unknown" is returned. Similarly, the controller method returns the content of the X-Scope field as the "scopes" field and the preset status "online" as the "status" field.

[0064] (4) After the device-1 service is verified and forwarded through the API gateway, the received request header contains X-Scope=device:read. Therefore, the JSON response returned by the controller contains “scopes”:“device:read”. If the token payload is configured with device_id declaration, the X-Device-Id field exists, and the returned JSON response contains the corresponding device identifier.

[0065] It's important to note that the device-1 service itself does not store any key materials, does not invoke any post-quantum cryptography libraries, and does not perform any signature verification operations; all its security relies on the API gateway layer. This design ensures that downstream microservices do not require any code modifications for post-quantum migration.

[0066] Similarly, the product service (product-1) performs CRUD operations on product data after obtaining user identity and permission information through the API gateway, without involving any post-quantum cryptography related processing.

[0067] Through the cooperation of the above embodiments, this invention constructs a complete distributed identity authentication system that conforms to the OAuth 2.0 standard, supports device authorization code processes, possesses resistance to quantum computing attacks, and is highly compatible with existing business systems. The API gateway layer is responsible for hybrid signature verification and forwarding claim information downstream, enabling the entire system to achieve post-quantum security goals while minimizing the impact on existing business systems.

Claims

1. An identity authentication and access control system based on post-quantum hybrid signatures and authorization codes, characterized in that, Include: 1) Key management module, configured to store at least one first key pair of classical signature algorithm and at least one second key pair of post-quantum signature algorithm in key storage area, and provide hybrid signature generation interface and hybrid signature verification interface; 2) The authorization server is configured to generate a hybrid signature JWT using the first key pair and the second key pair through the hybrid signature generation interface of the key management module; 3) API gateway, configured to perform dual signature verification on the hybrid signature JWT through the hybrid signature verification interface of the key management module, and extract the claim information from the JWT payload after successful verification, and forward it to the downstream service through the HTTP request header.

2. The system according to claim 1, characterized in that, The authorization server also includes a device authorization module, which is configured to receive device authorization requests from input-restricted devices, generate and associate device codes and user codes, and after the user verifies the user code and approves the authorization through a user terminal, call the authorization server to generate a hybrid signature JWT as an access token.

3. The system according to claim 1, characterized in that, The header of the hybrid signature JWT contains an algorithm identifier that uniquely identifies the hybrid signature; the signature segment of the hybrid signature JWT contains a hybrid signature value formed by superimposing and combining a first signature value generated by the first key pair and a second signature value generated by the second key pair according to a predetermined rule.

4. The system according to claim 1, characterized in that, The claim information extracted by the API gateway includes at least one or more of the following: user identifier, permission scope, and device identifier; the claim information is added to the forwarding request after being mapped through preset HTTP request header field names.

5. The system according to claim 1, characterized in that, When the system starts, the key management module exposes the first public key of the first key pair and the second public key of the second key pair to the JWK Set endpoint for the API gateway to download and cache.

6. A method for identity authentication and access control based on post-quantum hybrid signatures and authorization codes, characterized in that, include: 1) Key generation steps: Generate and store the first key pair of the classical signature algorithm and the second key pair of the post-quantum signature algorithm in the key storage area; 2) Token generation step: In response to the authorization request, the hybrid signature generation interface is called to generate a hybrid signature JWT using the first key pair and the second key pair; 3) Token verification step: In response to the API request carrying the hybrid signature JWT, the hybrid signature verification interface is called to perform dual signature verification on the hybrid signature JWT using the first public key of the first key pair and the second public key of the second key pair; 4) Declaration forwarding step: After the dual signature verification is passed, the declaration information is extracted from the payload of the hybrid signature JWT and forwarded to the downstream service through the HTTP request header.

7. The method according to claim 6, characterized in that, It also includes a device authorization step: in response to a device authorization request from an input-restricted device, generating and associating a device code and a user code; in response to the user's verification and approval of the user code through a user terminal, executing the token generation step.

8. The method according to claim 6, characterized in that, The token generation step further includes: 1) Construct the JWT header, where the algorithm field is set to the hybrid signature algorithm identifier; 2) Construct the JWT load; 3) Generate a first signature value using the first private key of the first key pair; 4) Generate a second signature value using the second private key of the second key pair; 5) Combine the first signature value and the second signature value into a single hybrid signature value; 6) Encode the header, payload, and hybrid signature value into a three-part structure.

9. The method according to claim 6, characterized in that, The dual signature verification step further includes: 1) Parse the header, payload, and hybrid signature value from the hybrid signature JWT; 2) Separate the first signature value and the second signature value from the mixed signature value; 3) Verify the first signature value using the first public key; verify the second signature value using the second public key; 4) The token is considered valid only if both verifications pass.

10. The method according to claim 6, characterized in that, The statement forwarding step further includes: 1) Extract one or more of the user identifier, permission scope, and device identifier from the JWT payload; 2) Map the extracted declaration information to preset HTTP request header field names; 3) Add the request header fields to the HTTP request forwarded to the downstream service.

11. The method according to claim 10, characterized in that, The downstream service reads the declaration information from the HTTP request header and uses it for business logic processing or access control, without performing any signature verification operation.

12. The method according to claim 6, characterized in that, Also includes: When the system starts up, the first public key and the second public key are exposed to the JWK Set endpoint; the API gateway downloads and caches the first public key and the second public key from the JWK Set endpoint.

13. A computer program product comprising executable instructions that, when executed by one or more processors, cause the processors to perform the method of any one of claims 6 to 12.

14. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by a processor, it implements the steps of the method according to any one of claims 6 to 12.

15. An API gateway device for a distributed identity authentication and access control system according to any one of claims 1 to 5, characterized in that, Include: 1) Public key caching module, configured to download and cache classic public keys and post-quantum public keys from the JWK Set endpoint of the authorization server; 2) Token verification module, configured to intercept API requests, extract hybrid signature JWTs, and perform dual signature verification on the JWTs using cached classic public keys and post-quantum public keys; 3) Declaration forwarding module, configured to extract declaration information from the JWT payload after successful verification and forward it to downstream services via HTTP request headers.

16. An authorization server device for a distributed identity authentication and access control system according to any one of claims 1 to 5, characterized in that, Include: 1) The key management module is configured to store the first key pair for the classical signature algorithm and the second key pair for the post-quantum signature algorithm; 2) Token generation module, configured to generate a hybrid signature JWT using the first key pair and the second key pair; 3) Device authorization module, configured to receive device authorization requests from input-restricted devices, generate and associate device codes and user codes, and trigger the token generation module after the user approves the authorization.

17. The authorization server apparatus according to claim 16, characterized in that, The device authorization module is also configured to: after verifying the validity of the user code, display the scope of permissions requested by the client device to the user and obtain the user's approval confirmation.

18. The authorization server apparatus according to claim 16, characterized in that, The header of the hybrid signature JWT generated by the token generation module contains an algorithm identifier that uniquely identifies the hybrid signature, and the signature segment contains a hybrid signature value formed by superimposing and combining the first signature value generated by the first key pair and the second signature value generated by the second key pair according to a predetermined rule.

19. The authorization server apparatus according to claim 16, characterized in that, The key management module is also configured to expose the first public key of the first key pair and the second public key of the second key pair to the JWKSet endpoint when the system starts.

Images