A multi-modal gateway authentication method, system, medium and product

Abstract

A multi-modal gateway authentication method, system, medium and product, wherein the method comprises: receiving an application access request sent by a client, extracting source credential data from the application access request, and based on a target business system pointed to by the application access request, calling an authentication adaptation descriptor corresponding to the target business system from a pre-set configuration center; determining the conversion logic definition and the sink credential type of the target business system; performing legality verification on the source credential data, constructing a unified identity context based on the source credential data; inputting the unified identity context into a target execution engine, performing credential instantiation processing based on a credential processing strategy, and obtaining sink credential data in a data structure conforming to the sink credential type; reorganizing the application access request based on the sink credential type and the sink credential data, and forwarding the reorganized application access request to the target business system. The present application can improve the gateway authentication processing efficiency.

Description

Technical Field

[0001] This application relates to the field of gateway authentication technology, specifically to a multimodal gateway authentication method, system, medium, and product. Background Technology

[0002] With the continuous development of enterprise information systems, more and more business systems are being deployed using heterogeneous protocols and different authentication and authorization mechanisms. These systems are typically built upon multiple service platforms, identity authentication mechanisms (such as OAuth, SAML, LDAP, JWT, etc.), and various access protocols (such as HTTP, gRPC, MQTT, etc.), forming a complex distributed architecture. In such an environment, users want to access multiple backend business systems through a unified entry point, thereby reducing integration costs and improving user experience.

[0003] In existing technologies, some gateway devices already support authentication of access requests and transmit the authentication results to the target business system. After receiving a user request, the gateway device relies on its built-in authentication module to verify the identity credentials in the request. If the verification is successful, it directly appends the original credentials or some intermediate token (such as a JWT) to the forwarding request, and then the target business system parses and verifies the identity information itself. However, in this case, the gateway typically only supports one or a few fixed authentication conversion modes (such as JWT pass-through). When it is necessary to access a backend system using a completely different authentication mechanism (such as a traditional web system that only supports Cookie-Session), the gateway's source code must be modified, and a new authentication processing module must be developed and deployed. This makes the gateway bloated and inflexible, and each adaptation to a new system requires downtime for updates, affecting the gateway's authentication processing efficiency. Summary of the Invention

[0004] This application provides a multimodal gateway authentication method, system, medium, and product to solve the technical problem that when there are protocol differences and structural inconsistencies between the source-end credentials and the credentials required by the target system, the access system needs to develop customized intermediate processing logic for each combination of source and target ends, thereby improving the efficiency of gateway authentication processing.

[0005] The first aspect of this application provides a multimodal gateway authentication method, applied to a gateway device, the method comprising: Receive application access request sent by client, extract source credential data from application access request, and retrieve authentication adaptation descriptor corresponding to target business system from preset configuration center based on target business system pointed to by application access request; Parse the authentication adaptation descriptor to determine the conversion logic definition and destination credential type of the target business system. The conversion logic definition is the conversion logic from the source credential data to the destination credential type. The conversion logic definition is used to associate credential processing strategy. The credential processing strategy is at least one of protocol conversion strategy, interactive exchange strategy and algorithm synthesis strategy. The source credential data is validated for legality. After the validity is validated, a unified identity context is constructed based on the source credential data. The unified identity context is a standard user data structure that eliminates differences in the source protocol. The target execution engine corresponding to the conversion logic definition is determined from multiple preset credential conversion engines, and the unified identity context is input to the target execution engine. Based on the credential processing strategy, credential instantiation is performed to obtain the destination credential data that conforms to the data structure of the destination credential type. Based on the destination credential type and the destination credential data, the application access request is reassembled, and the reassembled application access request is forwarded to the target business system.

[0006] Optionally, the authentication adapter descriptor is parsed to determine the conversion logic definition of the target business system and the destination credential type, specifically including: The application access request is analyzed by field analysis. If the application access request contains an authentication mode header field, it is determined whether the mode indicated by the authentication mode header field is in the list of supported modes defined by the authentication adaptation descriptor. If so, the mode indicated by the authentication mode header field is determined as the conversion logic definition. If the authentication mode header field does not exist, or if the mode indicated by the authentication mode header field does not exist in the list of supported modes, then the request context features of the application access request are parsed, and the mode switching conditions in the authentication adaptation descriptor are matched based on the request context features to obtain the matching result. Based on the matching results, the conversion logic definition is determined, and the destination credential type corresponding to the conversion logic definition is determined.

[0007] Optionally, the transformation logic definition is determined based on the matching result, specifically including: If a match is successful, the matched conditional pattern will be determined as the transformation logic definition. If a match fails, the default authentication mode defined in the authentication adapter descriptor will be determined as the conversion logic definition.

[0008] Optionally, the source credential data is validated for legality. After passing the validity validation, a unified identity context is constructed based on the source credential data, specifically including: Parse the header structure of the source credential data to extract the encryption algorithm identifier and key index; Obtain the verification key corresponding to the key index, and perform digital signature verification on the source credential data based on the algorithm logic corresponding to the encryption algorithm identifier and the verification key; If the digital signature verification is successful, the payload structure of the source credential data is parsed, and the timeliness parameter and unique identifier in the payload structure are verified by business rules. The timeliness parameter is used to verify whether the credential is within the effective time window, and the unique identifier is used to verify whether the credential has been revoked or replayed by retrieving the preset credential status cache. If the business rule verification passes, the user subject information, tenant affiliation information and permission set data in the payload structure are extracted, and the user subject information, tenant affiliation information and permission set data are mapped to a predefined standard data model to generate the unified identity context.

[0009] Optionally, based on the voucher processing strategy, voucher instantiation processing is performed to obtain destination voucher data that conforms to the data structure of the destination voucher type, specifically including: If the credential processing strategy is the interactive exchange strategy, then the user's unique identifier in the unified identity context is used as an index to retrieve the first session identifier associated with the target business system in the cache unit. If the first session identifier does not exist in the cache unit, then the login interface of the target business system is called based on the preset proxy login parameters to obtain the second session identifier. The mapping relationship between the user's unique identifier and the second session identifier is constructed and stored in the cache unit, and the second session identifier is determined as the destination credential data. If the credential processing strategy is the protocol conversion strategy, then user attribute information and permission scope data are extracted from the unified identity context, and according to the serialization rules defined by the destination credential type, the user attribute information and permission scope data are re-encapsulated into a standard token string, and the standard token string is determined as the destination credential data. If the credential processing strategy is the algorithm synthesis strategy, then the signature key bound to the target business system is obtained, and based on the hash algorithm corresponding to the destination credential type, a digital signature operation is performed on the unified identity context and the timestamp parameter of the current request to generate signature data. The signature data and the unified identity context are then assembled according to a preset format to obtain the target credential string, and the target credential string is determined as the destination credential data.

[0010] Optionally, the method further includes: If the required fields defined by the destination credential type are missing in the unified identity context, then the fault-tolerant filling rules associated with the target business system are obtained. The fault-tolerant filling rules are used to define the default placeholders for the missing fields or the hash derivation algorithm based on the known fields. The required fields are filled with virtual values ​​generated by the default placeholder or the hash derivation algorithm, and the permission set data in the unified identity context is reset to the preset minimum permission set. The credential instantiation process is performed based on the filled-in required fields and the reset unified identity context to obtain the client credential data containing the minimum permission set.

[0011] Optionally, the application access request is reassembled based on the destination credential type and the destination credential data, specifically including: Remove the source credential data carried in the application access request to obtain the target application access request; If the destination credential type is a token type, then an extended authentication field is constructed in the header of the target application access request, and the destination credential data is written into the extended authentication field; If the destination credential type is a session identifier type, then a session status string conforming to the target business system specification is constructed based on the destination credential data, and the session status string is written into the session status management field of the target application access request; If the destination credential type is a signature type, then the destination credential data is added to the Uniform Resource Locator parameter in the target application access request, or written to the signature verification header field of the target application access request.

[0012] Secondly, embodiments of this application provide a multimodal gateway authentication system, which includes: one or more processors and a memory; the memory is coupled to the one or more processors, and the memory is used to store computer program code, which includes computer instructions, and the one or more processors call the computer instructions to cause the multimodal gateway authentication system to perform the method described in the first aspect and any possible implementation thereof.

[0013] Thirdly, embodiments of this application provide a computer-readable storage medium including instructions that, when executed on a multimodal gateway authentication system, cause the multimodal gateway authentication system to perform the method described in the first aspect and any possible implementation thereof.

[0014] Fourthly, embodiments of this application provide a computer program product containing instructions that, when the computer program product is run on a multimodal gateway authentication system, cause the multimodal gateway authentication system to perform the method described in the first aspect and any possible implementation thereof.

[0015] In summary, one or more technical solutions provided in this application have at least the following technical effects or advantages: 1. By introducing an authentication adaptation descriptor mechanism, the conversion logic between source credentials and target business system destination credentials types is configurable. Combined with the construction of a unified identity context and the dynamic invocation of multiple credential processing strategies, it can automatically select the matching conversion engine to complete the cross-protocol and cross-mechanism credential adaptation process without modifying the gateway's core code. In the process, it avoids repeated development and downtime deployment caused by adding new systems, thereby improving the flexibility and automation of credential conversion in multimodal access scenarios, and thus improving the gateway's authentication processing efficiency for heterogeneous systems.

[0016] 2. During the authentication adaptation descriptor parsing process, a priority mechanism for identifying authentication mode header fields in application access requests is introduced, supplemented by matching logic of request context features and mode switching conditions. This enables dynamic determination of the conversion logic definition under different request carrying methods, while setting a default authentication mode to deal with matching failures. As a result, the adaptability to diverse access requests is effectively improved during operation, the flexibility and robustness of authentication mode selection are enhanced, and the accurate execution of the credential conversion process is ensured. This improves the efficiency of the gateway in automatically matching and executing authentication strategies in complex access scenarios.

[0017] 3. By parsing the header structure of the source credential data, the encryption algorithm identifier and key index are extracted. Digital signature verification is then completed by combining the corresponding algorithm logic and key. After the signature verification is passed, validity and security checks based on business rules are performed on the timeliness parameters and unique identifiers in the credential payload to ensure that the credential has not expired, been revoked, or replayed. Finally, the structured information containing user information, tenant ownership, and permission data is mapped to a unified standard data model to build a unified identity context. This achieves highly reliable verification and standardized information conversion of multi-source credentials during the process, effectively improving the security, standardization, and accuracy of subsequent credential adaptation in authentication data processing, thereby enhancing the overall stability and operational efficiency of the gateway authentication process. Attached Figure Description

[0018] Figure 1 This is a schematic diagram of the processing flow of a user accessing a business system through gateway authentication in an embodiment of this application; Figure 2This is a flowchart illustrating a multimodal gateway authentication method in an embodiment of this application; Figure 3 This is a schematic diagram of the gateway authentication and token update process in the embodiments of this application; Figure 4 This is a schematic diagram of the gateway-based user session authentication process in an embodiment of this application; Figure 5 This is a schematic diagram of the gateway authentication process based on token verification and session construction in the embodiments of this application; Figure 6 This is a flowchart illustrating the third-party user signature authentication access system in this application embodiment; Figure 7 This is a schematic diagram of the modular processing flow of the authentication process engine in the embodiments of this application; Figure 8 This is a schematic diagram of the structure of a multimodal gateway authentication system according to an embodiment of this application.

[0019] Explanation of reference numerals in the attached drawings: 301, Central Processing Unit; 302, Read-Only Memory; 303, Random Access Memory; 304, Bus; 305, Input / Output Interface; 306, Input Section; 307, Output Section; 308, Storage Section; 309, Communication Section; 310, Driver; 311, Removable Media. Detailed Implementation

[0020] To enable those skilled in the art to better understand the technical solutions in this specification, the technical solutions in the embodiments of this specification will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments.

[0021] In the description of the embodiments of this application, the words "for example" or "for instance" are used to indicate examples, illustrations, or explanations. Any embodiment or design that is described as "for example" or "for instance" in the embodiments of this application should not be construed as being more preferred or advantageous than other embodiments or design options. Rather, the use of the words "for example" or "for instance" is intended to present the relevant concepts in a specific manner.

[0022] In the description of the embodiments of this application, the term "multiple" means two or more. For example, multiple systems means two or more systems, and multiple screen terminals means two or more screen terminals. Furthermore, the terms "first" and "second" are used for descriptive purposes only and should not be construed as indicating or implying relative importance or implicitly specifying the indicated technical features. Thus, a feature defined with "first" or "second" may explicitly or implicitly include one or more of that feature. The terms "comprising," "including," "having," and variations thereof all mean "including but not limited to," unless otherwise specifically emphasized.

[0023] Figure 1 This is a schematic diagram of the processing flow of a user accessing a business system through gateway authentication in an embodiment of this application.

[0024] like Figure 1 As shown, when a user (client) initiates an application access request to the target business system, the request is first intercepted by the gateway device deployed at the service entry point. The gateway device, as the core node for authentication decision-making, forwards the request to the authentication service (or calls the internally integrated authentication module), which verifies the credentials (such as Token, SessionID, or signature) carried in the request according to a preset authentication policy. The authentication service executes the specific verification logic and returns the authentication result. The gateway determines the current authentication status based on this result: if authentication fails, the gateway directly intercepts the request and returns an authentication failure response to the user; if the authentication status is determined to be successful, the gateway performs subsequent credential conversion or pass-through operations, routing the request to the specific backend business system, thus completing a secure application access process.

[0025] Figure 2 This is a flowchart illustrating a multimodal gateway authentication method in an embodiment of this application.

[0026] Please see Figure 2 This application provides a multimodal gateway authentication method, applied to a gateway device, comprising: S101. Receive an application access request sent by the client, extract source credential data from the application access request, and retrieve the authentication adaptation descriptor corresponding to the target business system from the preset configuration center based on the target business system pointed to by the application access request. Step S101 provides the original credential information and policy basis required for subsequent execution of accurate, efficient and secure authentication mode matching and identity authentication. Its core is to realize the dynamic adaptation and binding of authentication modes between the request source and the target system, thereby realizing differentiated security management of multiple systems under a unified gateway entry.

[0027] When a client initiates an access request, the request first reaches the gateway access layer deployed at the service entry point. This access layer is the system's first processing node, responsible for preprocessing all external and internal traffic. The access layer intercepts and parses HTTP request messages, extracting authentication-related fields, primarily including request header fields (such as Authorization, Auth-Mode, X-Device-Type, etc.), request parameters (such as appId, signature, timestamp, nonce, etc.), and request path information (such as system identifier prefixes or routing keywords carried in the URL). These fields are collectively referred to as source credential data, representing clues to the request initiator's identity and authentication intent.

[0028] The extraction of source-side credential data employs a unified encapsulation method, constructing all authentication-related fields into a structured data object called GatewayAuthRequest. This data structure encapsulates request metadata, parameters, header fields, client IP, target system identifier, and other content, facilitating subsequent logical judgment and process scheduling by the authentication decision engine. The initial design intent of GatewayAuthRequest was to reduce the complexity of calls between different authentication modes, decoupling authentication logic from request data, thereby supporting the coexistence and flexible switching of multiple authentication modes.

[0029] After successfully constructing the GatewayAuthRequest object, the system needs to determine the target business system to which the current request points. Identification of the target business system is typically based on the path prefix of the request URL (e.g., / nacos / , / rocketmq / , etc.) or the X-Target-System field in the request header. The identified target system identifier serves as a key index, and the system retrieves the corresponding authentication adapter descriptor for that system from a pre-configured configuration center. The configuration center centrally manages the authentication mode policies, signature algorithms, token parameters, key information, and other configuration content for all access systems, maintaining them in YAML or JSON format and supporting hot updates and multi-cluster synchronization.

[0030] An authentication adaptation descriptor is a structured data object that contains information such as the authentication model, supported authentication sub-modes, default authentication mode, mode switching conditions, parameter parsing rules, JWT configuration parameters, and key binding information. It typically exists in the form of AuthModeConfig. Its purpose is to provide the gateway decision engine with the authentication methods supported by the target system of the current request and their execution conditions, thereby achieving accurate adaptation and scheduling of authentication models for different systems.

[0031] Step S101 not only extracts and structures the credentials from the access request source, but also accurately maps them to the target system's authentication policy. This provides all the input information for subsequent automatic selection of authentication modes, execution of authentication logic, permission verification, and JWT generation. This process is highly dynamic and scalable, supporting future additions of authentication modes or system access scenarios.

[0032] For example, a client initiates a request to access the path / nacos / config, and the request header carries the fields Auth-Mode:simple_token_auth and Authorization:Bearer. <jwt>The system identifies the target business system as "nacos-admin" through the path prefix. It then retrieves the corresponding authentication adaptation descriptor from the configuration center, finding that it supports authentication modes including simple_token_auth and token+session. The request header field is configured with the trigger condition X-Device-Type==mobile. Based on this, the gateway prepares for authentication mode matching and completes subsequent authentication logic calls. Through this process, dynamic adaptation and secure binding of the request source, authentication mode, and target system are effectively achieved.

[0033] S102. Parse the authentication adaptation descriptor to determine the conversion logic definition and destination credential type of the target business system. The conversion logic definition is the conversion logic from the source credential data to the destination credential type. The conversion logic definition is used to associate credential processing strategy. The credential processing strategy is at least one of protocol conversion strategy, interactive exchange strategy and algorithm synthesis strategy. After receiving application access requests, extracting source credential data, and retrieving the authentication adaptation descriptor corresponding to the target business system, the system needs to perform in-depth parsing of the authentication adaptation descriptor to accurately determine the authentication mode conversion logic required by the target business system and its corresponding destination credential type. The conversion logic definition is a key guiding rule for converting source credential data into destination credential data. It directly determines the credential processing strategy to be adopted in the subsequent authentication process, such as whether to re-encapsulate the protocol format (protocol conversion strategy), implement session proxy by calling the target system interface (interaction exchange strategy), or generate an encrypted signature for the credential content (algorithm synthesis strategy). Specifically, this includes steps S1021-S1023: S1021. Perform field analysis on the application access request. If the application access request contains an authentication mode header field, determine whether the mode indicated by the authentication mode header field is in the list of supported modes defined by the authentication adaptation descriptor. If so, determine the mode indicated by the authentication mode header field as the conversion logic definition. To achieve flexible and accurate adaptation to different business systems and authentication scenarios, step S1021 parses whether the authentication mode is explicitly specified in the access request, so as to establish a fast mapping relationship between the current request and the pre-configured authentication policy, thereby completing the establishment of the conversion logic definition.

[0034] When a client initiates an application access request through a gateway, the request typically includes several header fields to convey authentication-related control information. Among these, the Auth-Mode field is defined as the authentication mode header field, used to explicitly identify the authentication mode type that the current request should use, such as session_auth, simple_token_auth, sign_auth, or oauth2_auth_code. This field is configured by the client or upstream system according to the expected authentication process, aiming to inform the gateway to prioritize the specified authentication mode for the authentication process and avoid unnecessary mode probing and judgment.

[0035] Upon receiving an application access request, the gateway first performs field-level analysis on the request message, parsing out all authentication-related header fields. If the analysis result contains an Auth-Mode field, it is parsed as a candidate authentication mode identifier. The system then retrieves the list of supported modes configured for the target business system from the authentication adapter descriptor previously obtained through the configuration center, i.e., the set of all allowed authentication modes. The list of supported modes is usually predefined in the form of an array or set, such as ["session_auth","simple_token_auth","sign_auth"], used to limit the authentication paths accepted by the system and prevent unauthorized modes from being forcibly injected. As an important component of multimodal authentication, this application also fully supports the access and conversion of the OAuth 2.0 standard protocol. Specifically, this includes: Authorization Code Mode: suitable for third-party web applications, where the gateway is responsible for handling the exchange of code and token; Client Mode: suitable for server-to-server communication, where the gateway directly verifies ClientID and Secret; Password Mode: in highly trusted scenarios, the gateway proxies the verification of username and password; Hidden Mode: suitable for pure front-end applications, where the gateway supports directly issuing short-lived tokens. The gateway uses a unified configuration center to specify specific OAuth2 sub-modes for different access applications and uniformly converts the tokens generated by them into client credentials for the internal system.

[0036] The system matches the authentication mode indicated in the Auth-Mode field with the list of supported modes. If the match is successful, meaning the authentication mode specified in the current request is explicitly supported by the target system, that authentication mode is directly used as the conversion logic definition. All subsequent operations such as credential processing, identity context construction, and JWT generation are then performed based on this mode. This approach enables explicit control of the authentication path, improving the certainty and efficiency of authentication decisions and avoiding security risks or authentication failures caused by mode ambiguity or misidentification. The list of supported modes defined by the authentication adaptation descriptor originates from the unified authentication configuration in the configuration center. This configuration center, as the policy management core of the multimodal gateway, pre-configures the set of supported authentication modes for each connected target business system. During system deployment or initial access, system administrators define the allowed authentication mode types for each business system through a visual console or YAML / JSON configuration file and synchronously store this configuration in the configuration center. The list of supported modes is embedded in the authentication adapter descriptor in the form of structured data. It is used to guide the verification and selection of authentication modes during the request processing, ensuring that only modes that comply with the security policy of the business system are allowed to be executed, thereby realizing centralized management and dynamic control of authentication policies.

[0037] When the client is aware of the authentication modes supported by the target system, the authentication process can be specified in advance by setting Auth-Mode. The gateway can quickly lock the conversion logic definition without entering the subsequent complex condition matching logic, which optimizes performance and enhances the explicitness and auditability of policy control.

[0038] For example, when an internal operations management backend integrates with the Nacos configuration center management interface, the client request header sets Auth-Mode: sign_auth. Upon receiving this request, the gateway parses sign_auth as a candidate authentication mode and checks the authentication adaptation descriptor of the Nacos-admin system to find that supported authentication modes include sign_auth and token+session. Determining that the mode indicated by the current request is a valid supported mode, the system then uses sign_auth as the conversion logic definition for this access, providing a clear path for subsequent credential instantiation processing based on the signature policy. Through this process, the authentication logic is effectively simplified, the authentication path is highly controllable, and the stability and consistency of authentication decisions are ensured.

[0039] S1022. If the authentication mode header field does not exist, or the mode indicated by the authentication mode header field does not exist in the list of supported modes, then the request context feature of the application access request is parsed, and the request context feature is matched with the mode switching condition in the authentication adaptation descriptor to obtain the matching result. To achieve automated adaptation and intelligent switching of authentication modes, especially when the client does not explicitly indicate the authentication mode, or the indicated authentication mode is not supported by the target business system, step S1022 dynamically derives the applicable conversion logic definition by parsing the request context characteristics and executing the matching logic with the mode switching conditions defined in the authentication adaptation descriptor, ensuring the continuity and compatibility of the authentication process. This rule-driven approach enables intelligent identification of different request contexts and automatic decision-making on authentication modes, thereby improving the system's adaptability and user experience.

[0040] After the gateway completes the initial field analysis of the application access request, if it fails to extract the authentication mode header field, or if the extracted field value is not recognized as a valid mode in the target system's supported mode list, the system transitions to a context-driven pattern recognition process. Request context features refer to a set of observable attributes related to the current request behavior, typically including but not limited to device type fields (such as X-Device-Type) carried in the request header, client source IP, User-Agent string, request path structure, interface module, request method type (GET, POST, etc.), and timestamp information. The system uses a predefined feature extraction module to read and structurally model these fields, forming a standardized context feature object.

[0041] Meanwhile, the gateway has retrieved the authentication adaptation descriptor of the target business system from the configuration center. This descriptor contains a set of fields called "Mode Switching Conditions," which defines the mapping relationship between specific context conditions and authentication modes. Mode switching conditions typically exist in the form of key-value pairs, expressions, or conditional rules. For example, "simple_token_auth":"request_header.X-Device-Type=='mobile'", indicates that when the X-Device-Type field exists in the request header and its value is 'mobile', the simple_token_auth mode should be used. This mechanism allows platform operators to flexibly configure authentication policies according to system scenarios, thereby achieving differentiated control of authentication paths for different terminals, different interfaces, or different callers.

[0042] The gateway uses a pre-defined conditional matching engine to sequentially match the extracted request context features with the rules defined in the mode switching conditions, employing expression parsing or a rule engine (such as Spring Expression Language or ANTLR syntax tree) for Boolean evaluation. If the matching logic result of any mode switching condition is "true," the authentication mode associated with that condition is returned as the matching result and used as input into the current request's transformation logic definition for subsequent processes. If multiple conditions match simultaneously, the system can select the optimal authentication mode as the final result based on the configured priority strategy. Without requiring the client to explicitly specify the authentication mode, the system can intelligently identify and make mode decisions based on the request's behavioral characteristics, thereby improving the automation level and applicability of the authentication process. This makes it suitable for business environments with diverse front-end devices and complex access sources.

[0043] For example, when a mobile device initiates an access request to the log management system, the request may not carry an Auth-Mode field, but it may contain an X-Device-Type:mobile field in the request header. The system recognizes the configuration item "simple_token_auth":"request_header.X-Device-Type=='mobile'" from the log management system's authentication adaptation descriptor. The system calculates a successful match using its condition matching engine and determines that simple_token_auth is the logic definition for the current request. This logic judgment process does not rely on the client actively configuring the authentication mode, exhibiting good compatibility and policy flexibility, ensuring the system can run stably and complete the authentication process in various operating environments.

[0044] S1023. Determine the conversion logic definition based on the matching result, and determine the destination credential type corresponding to the conversion logic definition.

[0045] After completing the field analysis of the application access request and matching it with the mode switching conditions, step S1023 clarifies the conversion logic definition that the current request should adopt based on the matching results, and further determines the type of destination credential to be generated. The specific execution process of this logic judgment is detailed in the following steps: if the match is successful, the matched condition mode is determined as the conversion logic definition; if the match fails, the default authentication mode defined in the authentication adapter descriptor is determined as the conversion logic definition.

[0046] As an intermediate access control node between the client and the business system, one of the core tasks of the gateway device is to intelligently determine the appropriate authentication mode based on the characteristics of the access request and convert the original credential data into standard credential data recognizable by the target business system. To achieve this, the entire process begins with receiving an application access request from the client. An application access request refers to a request message constructed by the client based on the HTTP or HTTPS protocol, typically containing information such as the request path, request method, header fields, and request body. The header fields may carry identity credential information, authentication mode control fields, and device characteristic fields. Upon receiving the request, the gateway device first extracts the source credential data for subsequent identity recognition and credential conversion. Next, based on the target business system address information pointed to in the request message, such as domain name, path prefix, or system identifier, the system retrieves the authentication adaptation descriptor corresponding to the target business system from a pre-configured configuration center. The configuration center is a centralized policy management component that stores information such as authentication adaptation rules, supported authentication modes, credential types, and processing strategies for each business system, which the gateway dynamically loads and calls at runtime.

[0047] After obtaining the authentication adaptation descriptor corresponding to the target business system, the gateway enters the descriptor parsing process. The goal is to extract the transformation logic definition and destination credential type that match the current request. The transformation logic definition refers to the rule path required to convert source credential data into the destination credential type, determining the strategy direction for subsequent credential processing. The destination credential type refers to the identity credential format expected to be received by the target business system, such as JWT tokens, session IDs, signature strings, etc. The gateway needs to generate a credential structure that meets the requirements based on this type. During the parsing process, the system first performs field analysis on the request message, attempting to identify the presence of an authentication mode header field. The authentication mode header field is a control field used to explicitly indicate the authentication path. It can be named "Auth-Mode" or other agreed-upon names, and its value identifies the authentication mode expected for the current request, such as "simple_token_auth," "session_auth," "sign_auth," etc. If this field exists, the system further verifies whether the indicated mode is included in the supported mode list defined by the authentication adaptation descriptor. The list of supported authentication modes is preset by the system administrator for each business system in the configuration center, representing the set of authentication modes allowed for access. If an authentication mode exists and is valid, the system will use it as the conversion logic definition for the current request, skipping the mode inference process and directly entering the credential processing stage. This processing path is suitable for scenarios where the client actively specifies the authentication mode, which can significantly reduce the judgment overhead and improve system response efficiency.

[0048] If the above conditions are not met—that is, if no authentication mode header field exists or its value is not in the supported mode list—the system switches to an inference process based on request context features. Request context features refer to a set of non-credential information related to the current request, used to assist in identifying the calling environment, source identity, or interface attributes. This feature set typically includes a device type field (such as "X-Device-Type"), client IP address, User-Agent, request path, interface module tag, request method (GET / POST), and call time period. The gateway parses and structures these fields through a feature extraction module, forming standardized context feature objects. Subsequently, the system matches these extracted context features sequentially with the mode switching conditions defined in the authentication adaptation descriptor. Mode switching conditions are a set of predefined rule mappings in the descriptor, used to indicate the authentication mode to be used in a specific context scenario. For example, if the rule is defined as "simple_token_auth: request_header.X-Device-Type=='mobile'", it means that the simple_token_auth mode should be used when the device type in the request header is mobile. The system uses a rule engine to perform Boolean matching between context features and each switching condition. If a match is successful, the authentication mode associated with that condition is extracted as the conversion logic definition for this request.

[0049] When a match is successful, the gateway determines the matched conditional pattern as the transformation logic definition and further searches for the corresponding destination credential type based on this authentication mode. The definition of the destination credential type is also embedded in the authentication adaptation descriptor, typically corresponding one-to-one with each authentication mode. For example, the destination credential type corresponding to the simple_token_auth mode might be a JWT token, the type corresponding to the session_auth mode might be a session ID, and the type corresponding to the sign_auth mode might be a signature string. The system confirms the target credential format through the mapping relationship, providing a format basis for subsequent credential instantiation. If all switching conditions fail to match, it indicates that a clear mode cannot be determined based on the request context characteristics. To avoid authentication failure, the system falls back to the default authentication mode defined in the descriptor. The default authentication mode is set by the system during the configuration phase to handle unrecognized requests, ensuring the system has a certain degree of fault tolerance and authentication continuity through the fallback strategy. Subsequently, the default mode is used as the transformation logic definition, and its corresponding destination credential type is searched, completing the final output of the pattern recognition phase.

[0050] For example, when an API request does not explicitly carry the Auth-Mode field, but the device type in the request header is "mobile," the system extracts contextual features and matches them with mode switching conditions to identify that the current request should use the simple_token_auth authentication mode. It then retrieves the corresponding destination credential type from the descriptor, which is the JWT-structured access_token, thus defining the conversion logic as "source_credential_to_jwt," providing the execution basis for the subsequent credential instantiation stage. Conversely, if all conditions are not met, the system uses the default authentication mode session_auth in the configuration, thereby locating the destination credential type as session_id, ensuring that the authentication process is not interrupted. Through this process, the system achieves intelligent identification of authentication modes and adaptation of conversion paths in complex request scenarios, significantly improving the gateway's adaptability, security, and controllability.

[0051] S103. Perform a legality check on the source credential data. After passing the legality check, construct a unified identity context based on the source credential data. The unified identity context is a standard user data structure that eliminates differences in the source protocol. After defining the conversion logic, the gateway needs to verify the legitimacy of the source credential data and construct a unified identity context based on successful verification. The goal is to ensure that data entering the subsequent credential conversion process is authentic, reliable, and untampered, while simultaneously using standardized abstraction to shield differences between different protocols and credential formats, enabling identity data to have a unified cross-system representation capability. Because credential data from different source systems differs significantly in encryption algorithms, structural formats, signature mechanisms, and timeliness controls, directly using it for conversion may lead to parsing failures, security vulnerabilities, or data inconsistencies. Therefore, a comprehensive verification of credential legitimacy is essential. The specific verification logic involves parsing the encryption algorithm identifier and key index from the source credential data, and based on this, performing digital signature verification and business rule verification to ensure that the credential data has not been tampered with, is within its valid time window, and has not been revoked or replayed. After legitimacy verification, the system further extracts core identity information such as user subject information, tenant affiliation information, and permission sets from the credential and maps them to a unified standard user data structure, forming a unified identity context to provide structured input for subsequent credential instantiation. This may include the following steps: Parse the header structure of the source credential data to extract the encryption algorithm identifier and key index; Obtain the verification key corresponding to the key index, and perform digital signature verification on the source credential data based on the algorithm logic corresponding to the encryption algorithm identifier and the verification key; If the digital signature verification is successful, the payload structure of the source credential data is parsed, and the timeliness parameter and unique identifier in the payload structure are verified by business rules. The timeliness parameter is used to verify whether the credential is within the effective time window, and the unique identifier is used to verify whether the credential has been revoked or replayed by retrieving the preset credential status cache. If the business rule verification passes, the user subject information, tenant affiliation information and permission set data in the payload structure are extracted, and the user subject information, tenant affiliation information and permission set data are mapped to a predefined standard data model to generate the unified identity context.

[0052] In the specific implementation process, after the conversion logic definition is completed, the system enters the stage of verifying the legitimacy of the source-end credential data, and constructs a unified identity context based on the successful verification. Source-end credential data refers to the identity credentials carried by the client and embedded in the application access request, which may exist in the form of tokens, signature strings, session IDs, QR code data, or other formats. Because these credential data come from diverse sources, have varying structures, and carry specific user identity and permission information, if they participate directly in the subsequent credential generation process without verification, it is highly likely to cause security risks such as unauthorized access, identity forgery, or data leakage. Therefore, introducing a legitimacy verification mechanism in the system design to ensure that credential data possesses authenticity, completeness, validity, and uniqueness is the foundation for building a trusted authentication system.

[0053] During the validity verification process, the system first parses the header structure of the source credential data. The credential header is typically encapsulated using Base64 or other structured encoding methods, and contains an encryption algorithm identifier and a key index field. The encryption algorithm identifier indicates the type of signature algorithm used by the credential, such as HMAC-SHA256, RSA-SHA512, or SM3, while the key index is used to quickly locate the key material used for signature verification. After extracting these two fields through the parser, the system accesses the key management module and loads the corresponding verification key based on the key index. The key management module typically interfaces with a key management system (KMS) or a cached key pool, supporting key version control and dynamic rotation.

[0054] After loading the verification key, the system uses the specified algorithm logic based on the encryption algorithm identifier, combined with the extracted key, to perform digital signature verification on the source credential data. Essentially, this signature verification process reconstructs the digest of the credential payload and compares it with the signature value to determine if the credential has been tampered with during transmission. If signature verification fails, the system suspends the current authentication process and returns an invalid credential error; if verification succeeds, it continues parsing the credential payload structure.

[0055] The credential payload structure is typically a structured data body containing fields such as user identity information, permission declarations, and time control parameters. After parsing this content, the system focuses on validating the timeliness parameters and unique identifiers according to business rules. Timeliness parameters include fields such as issuance time (iat), expiration time (exp), and effective time (nbf), used to determine if the credential is within the current time window. The system compares this with the local clock to ensure the credential has not expired and has already taken effect. The unique identifier is the globally unique number of the credential (such as the jti field). The system uses this identifier to access a pre-built credential status cache (such as Redis, Hazelcast clusters, etc.) to determine if the credential has been revoked or if there is a risk of replay attacks. For example, if the identifier is marked as revoked or if there are repeated access records within a short period, it indicates that the credential may have been copied and used or has been attacked, and the system will reject the request.

[0056] If all the above business rules pass verification, the system confirms that the source credential is a valid credential and enters the identity extraction and standardization stage. The system extracts user subject information (such as user_id, username), tenant affiliation information (such as tenant_code, org_id), and permission set data (such as role_list, scope_set, etc.) from the payload structure, and maps and transforms this information according to a predefined standard data model to generate a unified identity context. The unified identity context is a standardized structure used internally by the system to abstractly represent user identity. It is independent of the source protocol and credential format and has cross-platform and cross-system compatibility. Its structural design typically includes identity identifier fields, permission declaration structures, tenant affiliation tags, identity level flags, etc., to support subsequent credential generation and access control.

[0057] For example, a client submits a request header containing a JWT-formatted token. The system first parses the header, extracting the RS256 encryption algorithm and key index key-202401. The system loads the RSA public key corresponding to key-202401 from KMS and verifies the token signature to confirm it hasn't been tampered with. Then, the system parses the token's payload, finding its expiration date is 2026-01-30, within the current request's validity period. Furthermore, the JTI field doesn't show a duplicate record in the credential status cache, confirming the credential hasn't been revoked or replayed. The system continues to extract fields such as user_id, tenant_code, and role_list, mapping them to a unified identity context structure to form standardized input for subsequent steps. Through this process, the system achieves trusted verification and format standardization of source-side identity credentials, laying a solid foundation for subsequent credential instantiation and target system authentication.

[0058] S104. Determine the target execution engine corresponding to the conversion logic definition from multiple preset credential conversion engines, and input the unified identity context into the target execution engine. Perform credential instantiation processing based on the credential processing strategy to obtain the destination credential data that conforms to the data structure of the destination credential type. In this application embodiment, the standard JWT data structure definition for unified identity context strictly follows a three-layer protection system of Header, Payload, and Signature. The header contains key encrypted metadata, including the signature algorithm identifier (alg), token type (typ), and key version index (kid) to support dynamic key rotation. The payload not only integrates standard identity claim fields, such as issuer (iss), issuance time (iat), anti-replay unique identifier (jti), and anti-clock skew effective time (nbf), but also specifically extends to adapt to multimodal gateways with business fields, including composite subject identifier (sub) to distinguish between tenants and users, identifier recording the source mode of this authentication (auth_mode), and data permission scope (data_scope) and extended information (ext) for fine-grained control. The signature performs encryption operations on the first two parts based on the specified algorithm and key to ensure the non-repudiation and integrity of the certificate during transmission.

[0059] After successfully parsing the conversion logic definition and constructing the unified identity context, the system needs to accurately select the most suitable target execution engine from multiple preset credential conversion engines based on this conversion logic definition, and pass the unified identity context as structured input to the execution engine to start the credential instantiation process. The credential conversion engine, as the core carrier for executing the conversion logic, implements corresponding credential processing strategies internally, including but not limited to protocol conversion strategies, interaction exchange strategies, and algorithm synthesis strategies. Each strategy corresponds to different types of authentication systems and destination credential generation requirements. The target execution engine accordingly calls its internal strategy module to process the unified identity context data, transforming it from an intermediate abstract identity state into a specific credential structure acceptable to the target business system, i.e., the destination credential data. Credential instantiation is not only a format conversion process but also includes comprehensive operations such as protocol adaptation, algorithm application, and state interaction. Its execution effect directly determines the final authentication success rate and system compatibility. Therefore, to ensure the accuracy and efficiency of credential processing, the system needs to select the correct execution path according to the strategy instructions in the conversion logic definition and strictly follow the structural requirements of the destination credential type for credential generation. Specifically, this may include the following steps: If the credential processing strategy is the interactive exchange strategy, then the user's unique identifier in the unified identity context is used as an index to retrieve the first session identifier associated with the target business system in the cache unit. If the first session identifier does not exist in the cache unit, then the login interface of the target business system is called based on the preset proxy login parameters to obtain the second session identifier. The mapping relationship between the user's unique identifier and the second session identifier is constructed and stored in the cache unit, and the second session identifier is determined as the destination credential data. If the credential processing strategy is the protocol conversion strategy, then user attribute information and permission scope data are extracted from the unified identity context, and according to the serialization rules defined by the destination credential type, the user attribute information and permission scope data are re-encapsulated into a standard token string, and the standard token string is determined as the destination credential data. If the credential processing strategy is the algorithm synthesis strategy, then the signature key bound to the target business system is obtained, and based on the hash algorithm corresponding to the destination credential type, a digital signature operation is performed on the unified identity context and the timestamp parameter of the current request to generate signature data. The signature data and the unified identity context are then assembled according to a preset format to obtain the target credential string, and the target credential string is determined as the destination credential data.

[0060] After constructing the unified identity context, the gateway system enters the credential instantiation phase. The core objective of this phase is to generate destination credential data from the unified identity context, conforming to the data structure requirements of the target business system, based on the previously parsed conversion logic definition and corresponding credential processing strategy. Because different business systems differ significantly in authentication mechanisms, credential formats, and interface protocols, the system needs to dynamically select credential processing strategies and combine multiple credential conversion methods to complete the conversion from abstract identity information to specific credential formats. To support this process, the system pre-configures multiple types of credential conversion strategies, including interactive exchange strategies, protocol conversion strategies, and algorithm synthesis strategies. Each strategy adapts to different authentication systems and target system access requirements.

[0061] When the credential processing strategy associated with the conversion logic definition is an interactive exchange strategy, the system uses the user's unique identifier in the unified identity context as an index to attempt to retrieve the first session identifier bound to the target business system in the cache unit. This user's unique identifier is usually a user ID, a global UUID, or other non-repeatable identity tag value, used to quickly locate user status information in a multi-tenant environment. The cache unit is generally composed of high-performance key-value storage components, such as a Redis or Hazelcast cluster, used to store the established session mapping relationship between the user and the target business system. If a valid first session identifier exists in the cache, the system directly returns it as the destination credential data, thereby achieving fast invocation without login. If the session identifier does not exist in the cache, it means that the user has not yet completed the authentication binding with the target business system. The system calls the login interface opened by the target system according to the configured preset proxy login parameters (such as username, password, authentication ticket, etc.) to complete the one-time login authentication and obtain the second session identifier. Subsequently, the system maps the second session identifier to the current user identifier and writes it to the local cache to support reuse in subsequent requests, and finally returns the second session identifier as the destination credential data. This strategy is suitable for scenarios where the target system uses a session mechanism or does not have an open token interface, enabling automatic login without exposing user passwords. For example, when a user accesses the ERP system's API interface for the first time, the gateway system can obtain the session_id through proxy login, avoiding requiring the user to manually enter their username and password, thereby improving the access experience.

[0062] In the process of generating destination credentials (such as signature strings or JWTs), this application provides a configurable algorithm selection strategy to adapt to the security requirements and performance indicators of different business systems. To balance the performance and security of gateway authentication, there are typically three dynamic selection options for algorithm types: In high-frequency call scenarios between internal systems (such as Session mode / simple Token mode), symmetric encryption algorithms (such as HS256 / HS512) are preferred, using shared keys to achieve efficient encryption and decryption, and a minimum key length of 256 bits is mandatory to avoid the risk of weak passwords; In open scenarios involving third-party API access or OAuth2, asymmetric encryption algorithms (such as RS256 / RS512) are mandatory, using the gateway to sign with a private key and the external system to verify the signature with a public key, thus completely eliminating the risk of credential forgery caused by key leakage; In scenarios involving the transmission of highly sensitive business data (such as Data Scope containing core permission data), a hybrid encryption strategy is further supported, that is, combining AES symmetric encryption and RSA asymmetric encryption. First, AES encryption is applied to the payload sensitive fields, and then RSA is used to protect the AES key, thereby building a dual security protection system. By employing differentiated algorithm configuration strategies, gateways can maximize the overall authentication throughput of the system while ensuring the security of core data.

[0063] When the credential processing strategy associated with the conversion logic definition is a protocol conversion strategy, the system extracts user attribute information and permission scope data from the unified identity context. User attribute information includes user ID, name, role, organization information, etc., while permission scope data includes resource access scope, operation type constraints, etc. Based on the definition of the destination credential type, the system calls the corresponding serialization rules to structurally encapsulate the above information, generating a standard token string that the target business system can parse. The serialization rules may be field organization specifications in JWT, SAML, or OAuth structure definitions, or they may be custom Base64 encoded structures. This encapsulation process not only completes the data format conversion but also ensures the accurate transmission of identity attributes and permission boundaries. The final generated standard token string is the destination credential data, which the system uses for subsequent request message reassembly and injection. This strategy is suitable for scenarios where the target system supports a standard token authentication mechanism, offering strong flexibility and scalability. For example, when the target system is a microservice cluster and requires the use of JWT as the authentication token, the gateway can directly encapsulate the unified identity context into an access_token conforming to the JWT structure and embed it in the request header for seamless integration.

[0064] When the credential processing strategy is an algorithm synthesis strategy, the system needs to complete a digital signature process based on the unified identity context to generate a target credential string with a timestamp and encrypted signature. This strategy is suitable for scenarios where the target business system uses a signature string for interface call verification, and is commonly found in high-security systems such as finance and the Internet of Things. The system first loads the signature key bound to the target business system from the configuration center. This key may be a symmetric key or an asymmetric private key, used for subsequent signature calculations. Then, the system extracts the core fields from the unified identity context and, combined with the timestamp parameter of the current request, generates a data digest according to the hash algorithm specified by the destination credential type (such as SHA256, SM3, MD5, etc.), and then performs a signature operation to form signature data. The system assembles the signature data with the original identity fields according to a preset format, finally constructing a complete target credential string, and returns it as the destination credential data. The core advantage of this strategy is that the verification process relies on signature calculation rather than state storage, providing anti-tampering, anti-replay, and zero-state dependency capabilities. For example, when calling the interface of a payment system, the system can generate a signature string based on the user's identity, request time, and key, and call it with parameters to achieve one-time authentication verification.

[0065] Furthermore, to ensure the security of the authentication process, this application provides a key lifecycle management scheme. The key management may include: Automatic key rotation mechanism: Configure key rotation period (e.g., 90 days) and automatically generate new key pairs before expiration; old keys are marked as "pending expiration" but retain verification permissions for a period of time, while new keys are marked as "in effect" for issuing new credentials, realizing parallel transition of dual keys and avoiding service interruption.

[0066] Key revocation and blacklist: When a key is at risk of being leaked, the corresponding kid is added to the gateway key blacklist. If the gateway finds that the kid in the credential header is in the blacklist during verification, it will directly reject the request; at the same time, all JWTs signed by this key will also be considered invalid.

[0067] In summary, during the credential instantiation process, the system dynamically selects the interaction exchange strategy, protocol conversion strategy, or algorithm synthesis strategy by parsing the conversion logic definition, and combines it with the unified identity context to complete credential generation. This ensures that the generated destination credential data fully complies with the authentication requirements of the target business system, thereby guaranteeing the adaptability, compatibility, and security of the entire gateway authentication process.

[0068] The above embodiments describe in detail the process by which the gateway converts source-end credentials into destination-end credentials. To further illustrate how the client maintains a long-term, valid connection with the gateway, this application also provides a credential management process based on a dual-token mechanism.

[0069] Figure 3 This is a schematic diagram of the gateway authentication and token update process in an embodiment of this application. Figure 3 As shown, this process details the entire lifecycle of user interactions, from logging in to obtain credentials, accessing services based on credentials, to credential expiration and refresh: First, during the login initialization phase, the user initiates a login request to the gateway. In order to build a complete identity context, the gateway sends a request to internal services or systems to "obtain user, role, and permission information". After successful acquisition, the gateway internally "builds a JWT" and generates an "access-token" for short-term access and a "refresh-token" for long-term renewal, while "saving the associated state to Redis". Finally, the gateway returns these two tokens to the user.

[0070] Secondly, during the business request authentication phase, the user "initiates a request" and carries the access-token; the gateway extracts the token and sends it to the authentication service for verification. After successful verification, the authentication service responds with "authentication successful, obtain JWT"; the gateway performs the operation of "setting JWT to request header" (i.e., token pass-through) and forwards the "request with JWT" to the internal service or system; the internal system executes the internal logic of "parse JWT to obtain authorization information" to process the business, and returns "response data" after processing; the gateway receives the response and "sets key information in the response header" before feeding back the final result to the user.

[0071] Finally, during the token update phase, when the access token expires, the user directly sends a request carrying a "refresh token" to the gateway. The gateway forwards the request parameters to the authentication service to perform "renewal login information" verification. After successful verification and processing, a "response success" is returned. Based on this, the gateway generates and "updates" the access token, returning the new access token to the user, thus maintaining the login status without the user's awareness. By introducing the Refresh-Token mechanism, the security and timeliness of JWT can be effectively balanced with user experience, avoiding repeated logins due to frequent access token expiration.

[0072] During the credential instantiation process, to ensure that the generated destination credential data meets the format and semantic integrity requirements of the target business system, the system must not only strictly implement the credential processing strategy but also perform real-time verification of the integrity of fields in the unified identity context. Specifically, this may include the following steps: If a required field defined by the destination credential type is missing in the unified identity context, a fault-tolerant filling rule associated with the target business system is obtained. This fault-tolerant filling rule defines a default placeholder for the missing field or a hash derivation algorithm based on known fields. The required field is filled with a virtual value generated by the default placeholder or the hash derivation algorithm, and the permission set data in the unified identity context is reset to a preset minimum permission set. The credential instantiation process is performed based on the filled required field and the reset unified identity context to obtain the destination credential data containing the minimum permission set.

[0073] Some business systems have set "required" constraints for certain fields in their destination credential type definitions. This means that if these fields are missing, the generated credential will fail the authentication parsing logic of the target system. Due to differences in the format and granularity of source credential data, the unified identity context may have some fields missing after standardized mapping, especially common when integrating across systems, protocols, or in weakly bound modes. To avoid authentication failures due to missing critical fields, the system introduces a fault-tolerant filling mechanism. This mechanism handles missing fields before credential instantiation to improve the overall robustness and compatibility of the system.

[0074] When the system detects that a required field in the destination credential type definition is missing or null in the current unified identity context, it immediately triggers fault-tolerant filling logic. Based on the identifier of the target business system, the system retrieves the fault-tolerant filling rules bound to that system from the configuration center. Fault-tolerant filling rules are a set of structured configurations describing the default processing strategy to be adopted in specific field missing scenarios. These rules fall into two categories: one is default placeholders, such as the strings "unknown_user", "000000", or "NULL", used to fill missing fields but without actual business semantics; the other is hash derivation algorithms based on existing fields, such as hashing existing fields like user_id and tenant_code to generate pseudo-field values, used to maintain uniqueness while meeting field specification requirements. The system selects an appropriate filling method based on the field type and business system requirements, and writes the generated virtual value into the corresponding field position in the unified identity context.

[0075] Meanwhile, to avoid the risk of permission expansion caused by field population, the system synchronously resets the permission set data in the unified identity context to the minimum permission set after performing the field population operation. The minimum permission set is a set of permissions selected from the system's preset permission base model that only contains basic access or read-only operations. Its design aims to minimize the possibility of unauthorized access caused by virtual identities while ensuring the integrity of credentials. This permission reset operation ensures that even if some fields are automatically populated, the access capabilities granted by the system are strictly limited to a controllable range, in accordance with the principle of least privilege.

[0076] After completing the above field population and permission reset, the system passes the updated unified identity context as input to the target execution engine to continue the credential instantiation process. During this instantiation process, although the generated destination credential data contains some populated values, its structure is complete and its format is compliant, meeting the target system's authentication requirements. Furthermore, since the permission scope is limited to a minimal set, it does not pose any actual business risk. For example, if a user accesses an industrial equipment management system and their source credential does not contain the complete `device_group` field, while the target system requires this field to be mandatory, the system generates a virtual `device_group` based on the `user_id` hash according to the fault-tolerant population rules and resets the permission set to a minimal set containing only the "read_device_info" permission. The resulting credential can still pass the authentication process, but will not perform any operations on the device. This mechanism effectively improves the system's tolerance for abnormal credentials, ensuring uninterrupted business processes while strengthening boundary permission control capabilities.

[0077] Furthermore, in order to more clearly illustrate the specific implementation of different credential processing strategies in this application, the following provides a detailed description of the interactive exchange strategy (i.e., the Session authentication mode). Figure 4 This is a schematic diagram of the user session authentication process based on a gateway in an embodiment of this application.

[0078] like Figure 4 As shown, the process is divided into two phases in terms of time: user login session establishment and business request access. In the user login session establishment phase: the user first initiates a login request to the gateway; after receiving the request, the gateway forwards the authentication command to the authentication service to verify the user information; the authentication service executes its internal login processing logic and further sends a request to the internal system to obtain user information to verify user ownership and permission details; the internal system responds to the request and sends the user information back to the authentication service; the authentication service combines the generated session identifier and returns the sessionId + user information to the gateway, which finally sends this combined data back to the user, completing the initialization of the session state. In the business request access phase: the user initiates a request action with session credentials; the gateway intercepts the request, extracts the sessionId, and sends it to the authentication service; the authentication service performs internal session verification operations (such as verifying expiration time, blacklist status, etc.); after verification, it sends a verification pass signal to the internal system (or the gateway routes the request to the internal system based on the verification result); the internal system processes the business logic, generates business data, and returns it to the user along the link, thus completing a system call protected by authentication.

[0079] In addition to the single authentication mode mentioned above, this application also provides an authentication adaptation strategy that combines Token and Session for scenarios where there are heterogeneous middleware systems (such as Nacos and RocketMQ consoles) and their source code cannot be modified.

[0080] Figure 5 This is a schematic diagram of the gateway authentication process based on token verification and session construction in an embodiment of this application. Figure 5 As shown, this process demonstrates how a gateway bridges authentication with an internal middleware system's session using a token, specifically comprising three stages: The first stage is the initial login and credential acquisition phase. The user initiates a "login" request to the gateway, and the gateway forwards the login information to the authentication service. After the authentication service executes the "verify login" logic, it returns an authentication result containing "user information + token information", which the user then obtains a token for subsequent identity verification.

[0081] The second stage is token verification and session construction, which is the core of the hybrid mode. The user initiates a request carrying a "Token", the gateway extracts the "access-token" and requests the authentication service to "verify the token"; after receiving a "verification successful" response, the gateway internally performs the "construct session" operation (such as login via proxy or mapping lookup), obtains or generates a "sessionId" adapted to the internal middleware system, and establishes a session context with the middleware system.

[0082] Finally, in the business request forwarding phase, the user initiates a "request for business," and the gateway, upon receiving the request, requests the authentication service to "verify the session" (e.g., verify the mapping relationship and validity between the token and the session). After receiving a "response result" indicating successful verification, the gateway performs protocol conversion on the request and "forwards the request" to the internal middleware system (at this point, the request has been adapted to a session format recognizable by the middleware). The internal middleware system processes the request and returns a "response," and the gateway ultimately returns the result to the user. Through this process, the gateway achieves transparent conversion between the stateless token on the front end and the stateful session on the back end, enabling users to seamlessly access various traditional middleware management backends using a unified token credential.

[0083] In addition to interactive login authentication for end users, this application also supports key signature-based authentication for programmatic access by third-party systems or organizations via API interfaces.

[0084] Figure 6 This is a flowchart illustrating the process of a third-party user signature authentication access system in an embodiment of this application. For example... Figure 6 As shown, this process mainly describes the signature authentication and request forwarding process for third-party users (API callers): First, the third-party user initiates a "signature request" to the gateway, carrying signature parameters (such as appId, timestamp, signature, and nonce). After receiving the request, the gateway forwards it to the authentication service (or calls the internal authentication module). The authentication service performs the operation of "verifying the signing authority and the legality of the request," including but not limited to verifying the validity of the application ID, the timeliness of the timestamp, the uniqueness of the random number, and recalculating and comparing the signature based on the pre-shared key (AppSecret). After verification, it returns a verification "response" to the gateway. After confirming that the verification is successful, the gateway strips the signature header from the request or adjusts its format and forwards the user request to the internal system. The internal system receives the request and executes the "processing business" logic, and returns "response data" to the gateway after completion. After receiving the data, the gateway performs the "constructing a signed response" operation (such as signing the response data to prevent tampering), and finally feeds back the secure response data to the third-party user.

[0085] S105. Based on the destination credential type and the destination credential data, the application access request is reassembled, and the reassembled application access request is forwarded to the target business system.

[0086] After generating the destination credential data, the system needs to restructure the original application access request based on this data and its corresponding credential type. This involves performing message reassembly to ensure the reassembled request meets the interface specifications and authentication requirements of the target business system. Due to differences in authentication mechanisms across different target business systems, there are significant differences in credential reception methods, field locations, and parameter structures. Therefore, the system needs to adopt a differentiated reassembly strategy based on the specific classification of the destination credential type. This reassembly operation includes not only clearing the source credential data from the original request but also injecting the destination credential data into the header fields, session state fields, or URL parameter structures of the target access request according to the format specifications of token type, session identifier type, or signature type, thereby replacing and adapting the authentication credential. Correct execution of this step is crucial for ensuring the target system successfully identifies and verifies the credential. The specific message reassembly method will be further detailed in the following steps, covering the injection location selection and format construction strategies for different types of destination credentials to achieve seamless support for the interface layers of various business systems. Specifically, it includes the following steps: Remove the source credential data carried in the application access request to obtain the target application access request; If the destination credential type is a token type, then an extended authentication field is constructed in the header of the target application access request, and the destination credential data is written into the extended authentication field; If the destination credential type is a session identifier type, then a session status string conforming to the target business system specification is constructed based on the destination credential data, and the session status string is written into the session status management field of the target application access request; If the destination credential type is a signature type, then the destination credential data is added to the Uniform Resource Locator parameter in the target application access request, or written to the signature verification header field of the target application access request.

[0087] After generating the destination credential data, the system needs to perform structured processing on the original application access request, i.e., perform message reassembly. The first step in this operation is to remove the source credential data already carried in the original request. Source credential data typically includes identity tokens, session identifiers, or signature fields generated during the client's initial authentication. Its format, content, and encryption methods are protocol-dependent and platform-specific, making it impossible for the target business system to directly recognize. To prevent conflicts between source and destination credentials, the system must explicitly remove credential fields from the original request, including but not limited to the Authorization field in the HTTP Header, the access_token field attached to the URL parameters, or the session_id item in cookies. Essentially, this operation removes the request from the original authentication chain, retaining only the business payload, thus freeing up space for injecting destination credential data and avoiding authentication interference. After processing, the resulting request structure is called the target application access request, serving as the carrier for subsequent credential injection.

[0088] After receiving the cleaned target application access request, the system injects the host credential data into the request structure in a format conforming to the target business system's interface specifications, based on the specific classification of the host credential type. When the host credential type is a token, the system first refers to the token insertion specification defined in the authentication adapter descriptor and constructs an extended authentication field in the request header. This field is usually an extended header under Authorization or a custom namespace, such as X-Custom-Auth, and its function is to provide the target system with an entry point for parsing credentials. The system writes the host credential data as a string into this field, generally using the Bearer prefix or Base64 encoding format. For example, if the host credential is {"token":"abc123"}, the constructed header field is Authorization:Bearerabc123. Upon receiving this header field, the target system can trigger its local token verification logic, achieving authentication closure. This method is suitable for most business systems based on OAuth, JWT, or custom token mechanisms.

[0089] When the destination credential type is a session identifier, the system needs to construct a session state string that conforms to the target business system's session management specifications based on the destination credential data. The session state string is a data structure with a specific format, typically including fields such as session_id, user context digest, and signature verification value, and may be represented as a JSON or URL-encoded string. When constructing this string, the system combines the field names, format requirements, and encryption rules defined in the authentication adapter descriptor of the target system to structurally encapsulate the destination credential data, generating a compliant session state expression. Subsequently, the system writes this expression into the session state management fields in the target application's access request, such as JSESSIONID in the Cookie field, or X-Session-Token in the request header. This approach is suitable for systems employing server-side state management or centralized session control mechanisms, such as those based on traditional JavaEE session models or unified session management architectures based on Redis.

[0090] When the destination credential type is a signature type, the system needs to embed the destination credential data into the target application's access request as a signature field. Signature-type credentials are typically used for integrity protection and authentication of API calls. Their principle is to generate a digest by hashing the core request parameters and the signature key, and the target system verifies the received request using the same algorithm. Based on the target system's signature field specifications, the system chooses to inject the signature value into the URL parameters (e.g., ?signature=xxx) or a specified field in the HTTP Header (e.g., X-Signature). The injection process must ensure that the signature field remains consistent with the original request parameters and that the parameter order and encoding match the target system's expectations. If the system uses a timestamp + signature combination, the timestamp field usually also needs to be written into the request path or header simultaneously so that the target system can perform time window verification and replay attack prevention controls.

[0091] For example, a target business system requires a signature field to be included in API calls for tamper-proof verification. The signature field needs to be appended to the request URL, and the signature algorithm is SHA256(user_id+timestamp+secret_key). After the system instantiates the credential and obtains the signature value, it appends it to the end of the target application's access request URL, forming an actual request path such as https: / / api.example.com / data?user_id=alice×tamp=1700000000&signature=5e88489..., which the target system can use to complete the signature verification process.

[0092] By combining the above-mentioned injection strategies, the system achieves protocol adaptation and structural reorganization for different types of client credentials, enabling multimodal credentials to be successfully converted into an authentication format that the target business system can parse on the basis of a unified identity context. This ensures that access requests can pass authentication and verification smoothly in cross-system and cross-protocol environments, thereby improving the system's compatibility, scalability, and security.

[0093] Furthermore, considering the high availability requirements of the gateway as a traffic entry point, this application also designs an authentication degradation strategy. When the gateway detects that the backend authentication service is unavailable (e.g., consecutive request timeouts or 5xx errors), the system automatically switches to local caching mode. The gateway attempts to read short-term cached permission data or public key information from a cache unit (such as LocalCache) for offline verification. If local verification passes, the request is allowed; if there is no local cache, circuit breaking is executed, returning a specific error code, thereby ensuring that core business operations can maintain basic access capabilities even when the authentication service is unstable.

[0094] Specifically, by passing through the `data_scope` field in the unified identity context, this application achieves permission linkage between the gateway layer and the business layer. The gateway layer is responsible for identity verification at the main entrance, while data access restrictions within the room (such as only allowing access to data within this department) are losslessly passed to the target business system through the extended fields of JWT. The target business system does not need to repeatedly query the database to obtain user permissions; it only needs to parse the header credentials to complete data filtering based on AOP aspects (such as `@DataScope`). In a multimodal environment, this mechanism ensures that the data permission context obtained by the backend system remains consistent regardless of whether the user accesses the system via Session or Token.

[0095] The multimodal gateway authentication method of this application has been described in detail above. To better implement this method, this application also provides an authentication process engine based on modular design.

[0096] Figure 7 This is a schematic diagram of the modular processing flow of the authentication process engine in this application embodiment. For example... Figure 7 As shown, the engine adopts a layered and decoupled modular design to support the dynamic execution of multimodal authentication: the process begins with the standardized encapsulation of raw traffic at the request access layer; the authentication decision engine, as the central brain, drives the pattern matcher to perform feature recognition on the request based on the policy configuration pulled in real time from the configuration center (such as Nacos); the matcher calls the specific pattern implementation class (covering Session / Token / signature / OAuth2, etc.) from the authentication pattern registry center according to the recognition result, and completes the authentication logic through the external dependency interaction layer (such as Redis); subsequently, the JWT engine, together with the key management module, is responsible for the instantiation generation and parsing of credentials, the permission verification module performs fine-grained access control, and finally the routing and forwarding module sends the compliant request to the backend, and the log auditing module completes the security recording of the entire link.

[0097] Please see Figure 8 This is a schematic diagram of the structure of a multimodal gateway authentication system in an embodiment of this application.

[0098] It should be noted that, Figure 8 The structure of the multimodal gateway authentication system shown is merely an example and should not impose any limitations on the functionality and scope of use of the embodiments of the present invention.

[0099] like Figure 8 As shown, a multimodal gateway authentication system includes a central processing unit 301, which can perform various appropriate actions and processes according to a program stored in a read-only memory 302 or a program loaded from a storage section 308 into a random access memory 303, such as executing the methods described in the above embodiments. The random access memory 303 also stores various programs and data required for system operation. The central processing unit 301, the read-only memory 302, and the random access memory 303 are interconnected via a bus 304. An input / output interface 305 is also connected to the bus 304.

[0100] The following components are connected to the input / output interface 305: an input section 306 including audio input devices, push-button switches, etc.; an output section 307 including an LCD display, audio output devices, indicator lights, etc.; a storage section 308 including a hard disk, etc.; and a communication section 309 including a network interface card such as a LAN (Local Area Network) card, modem, etc. The communication section 309 performs communication processing via a network such as the Internet. A drive 310 is also connected to the input / output interface 305 as needed. A removable medium 311, such as a disk, optical disk, magneto-optical disk, semiconductor memory, etc., is installed on the drive 310 as needed so that computer programs read from it can be installed into the storage section 308 as needed.

[0101] In particular, according to embodiments of the present invention, the processes described above with reference to the flowcharts can be implemented as computer software programs. For example, embodiments of the present invention include a computer program product comprising a computer program carried on a computer-readable medium, the computer program containing computer programs for performing the methods shown in the flowcharts. In such embodiments, the computer program can be downloaded and installed from a network via communication section 309, and / or installed from removable medium 311. When the computer program is executed by central processing unit 301, it performs the various functions defined in the present invention.

[0102] It should be noted that specific examples of computer-readable storage media may include, but are not limited to: electrical connections having one or more wires, portable computer disks, hard disks, random access memory, read-only memory, erasable programmable read-only memory, flash memory, optical fiber, portable compact disk read-only memory, optical storage devices, magnetic storage devices, or any suitable combination thereof. In this invention, a computer-readable storage medium can be any tangible medium containing or storing a program that can be used by or in conjunction with an instruction execution system, apparatus, or device.

[0103] The flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of the present invention. Each block in a flowchart or block diagram may represent a module, segment, or portion of code, which contains one or more executable instructions for implementing a specified logical function. It should also be noted that in some alternative implementations, the functions indicated in the blocks may occur in a different order than those shown in the drawings.

[0104] Specifically, a multimodal gateway authentication system according to this embodiment includes a processor and a memory. The memory stores a computer program. When the computer program is executed by the processor, it implements a multimodal gateway authentication method provided in the above embodiment.

[0105] In another aspect, the present invention also provides a computer-readable storage medium, which may be included in a multimodal gateway authentication system described in the above embodiments; or it may exist independently and not assembled into the multimodal gateway authentication system. The storage medium carries one or more computer programs, which, when executed by a processor of the multimodal gateway authentication system, cause the multimodal gateway authentication system to implement the multimodal gateway authentication method provided in the above embodiments.< / jwt>

Claims

1. A multimodal gateway authentication method, characterized in that, Applied to a gateway device, the method includes: Receive application access request sent by client, extract source credential data from application access request, and retrieve authentication adaptation descriptor corresponding to target business system from preset configuration center based on target business system pointed to by application access request; Parse the authentication adaptation descriptor to determine the conversion logic definition and destination credential type of the target business system. The conversion logic definition is the conversion logic from the source credential data to the destination credential type. The conversion logic definition is used to associate credential processing strategy. The credential processing strategy is at least one of protocol conversion strategy, interactive exchange strategy and algorithm synthesis strategy. The source credential data is validated for legality. After the validity is validated, a unified identity context is constructed based on the source credential data. The unified identity context is a standard user data structure that eliminates differences in the source protocol. The target execution engine corresponding to the conversion logic definition is determined from multiple preset credential conversion engines, and the unified identity context is input to the target execution engine. Based on the credential processing strategy, credential instantiation is performed to obtain the destination credential data that conforms to the data structure of the destination credential type. Based on the destination credential type and the destination credential data, the application access request is reassembled, and the reassembled application access request is forwarded to the target business system.

2. The method according to claim 1, characterized in that, The process of parsing the authentication adapter descriptor to determine the conversion logic definition of the target business system and the destination credential type specifically includes: The application access request is analyzed by field analysis. If the application access request contains an authentication mode header field, it is determined whether the mode indicated by the authentication mode header field is in the list of supported modes defined by the authentication adaptation descriptor. If so, the mode indicated by the authentication mode header field is determined as the conversion logic definition. If the authentication mode header field does not exist, or if the mode indicated by the authentication mode header field does not exist in the list of supported modes, then the request context features of the application access request are parsed, and the mode switching conditions in the authentication adaptation descriptor are matched based on the request context features to obtain the matching result. Based on the matching results, the conversion logic definition is determined, and the destination credential type corresponding to the conversion logic definition is determined.

3. The method according to claim 2, characterized in that, The step of determining the transformation logic definition based on the matching result specifically includes: If a match is successful, the matched conditional pattern will be determined as the transformation logic definition. If a match fails, the default authentication mode defined in the authentication adapter descriptor will be determined as the conversion logic definition.

4. The method according to claim 1, characterized in that, The step of verifying the legitimacy of the source-end credential data, and constructing a unified identity context based on the source-end credential data after passing the legitimacy verification, specifically includes: Parse the header structure of the source credential data to extract the encryption algorithm identifier and key index; Obtain the verification key corresponding to the key index, and perform digital signature verification on the source credential data based on the algorithm logic corresponding to the encryption algorithm identifier and the verification key; If the digital signature verification is successful, the payload structure of the source credential data is parsed, and the timeliness parameter and unique identifier in the payload structure are verified by business rules. The timeliness parameter is used to verify whether the credential is within the effective time window, and the unique identifier is used to verify whether the credential has been revoked or replayed by retrieving the preset credential status cache. If the business rule verification passes, the user subject information, tenant affiliation information and permission set data in the payload structure are extracted, and the user subject information, tenant affiliation information and permission set data are mapped to a predefined standard data model to generate the unified identity context.

5. The method according to claim 1, characterized in that, The process of instantiating vouchers based on the voucher processing strategy to obtain terminal voucher data conforming to the data structure of the terminal voucher type specifically includes: If the credential processing strategy is the interactive exchange strategy, then the user's unique identifier in the unified identity context is used as an index to retrieve the first session identifier associated with the target business system in the cache unit. If the first session identifier does not exist in the cache unit, then the login interface of the target business system is called based on the preset proxy login parameters to obtain the second session identifier. The mapping relationship between the user's unique identifier and the second session identifier is constructed and stored in the cache unit, and the second session identifier is determined as the destination credential data. If the credential processing strategy is the protocol conversion strategy, then user attribute information and permission scope data are extracted from the unified identity context, and according to the serialization rules defined by the destination credential type, the user attribute information and permission scope data are re-encapsulated into a standard token string, and the standard token string is determined as the destination credential data. If the credential processing strategy is the algorithm synthesis strategy, then the signature key bound to the target business system is obtained, and based on the hash algorithm corresponding to the destination credential type, a digital signature operation is performed on the unified identity context and the timestamp parameter of the current request to generate signature data. The signature data and the unified identity context are then assembled according to a preset format to obtain the target credential string, and the target credential string is determined as the destination credential data.

6. The method according to claim 5, characterized in that, The method further includes: If the required fields defined by the destination credential type are missing in the unified identity context, then the fault-tolerant filling rules associated with the target business system are obtained. The fault-tolerant filling rules are used to define the default placeholders for the missing fields or the hash derivation algorithm based on the known fields. The required fields are filled with virtual values ​​generated by the default placeholder or the hash derivation algorithm, and the permission set data in the unified identity context is reset to the preset minimum permission set. The credential instantiation process is performed based on the filled-in required fields and the reset unified identity context to obtain the client credential data containing the minimum permission set.

7. The method according to claim 1, characterized in that, The process of reassembling the application access request based on the host credential type and the host credential data specifically includes: Remove the source credential data carried in the application access request to obtain the target application access request; If the destination credential type is a token type, then an extended authentication field is constructed in the header of the target application access request, and the destination credential data is written into the extended authentication field; If the destination credential type is a session identifier type, then a session status string conforming to the target business system specification is constructed based on the destination credential data, and the session status string is written into the session status management field of the target application access request; If the destination credential type is a signature type, then the destination credential data is added to the Uniform Resource Locator parameter in the target application access request, or written to the signature verification header field of the target application access request.

8. A multimodal gateway authentication system, characterized in that, The multimodal gateway authentication system includes: one or more processors and a memory; the memory is coupled to the one or more processors, the memory is used to store computer program code, the computer program code including computer instructions, and the one or more processors call the computer instructions to cause the multimodal gateway authentication system to perform the method as described in any one of claims 1-7.

9. A computer-readable storage medium comprising instructions, characterized in that, When the instruction is executed on the multimodal gateway authentication system, the multimodal gateway authentication system performs the method as described in any one of claims 1-7.

10. A computer program product, characterized in that, When the computer program product is run on the multimodal gateway authentication system, the multimodal gateway authentication system performs the method as described in any one of claims 1-7.

Images