Unified scheduling method, device and equipment of multi-source identity authentication service and medium

Abstract

This application relates to the field of information security technology, and in particular to a unified scheduling method, apparatus, device, and medium for multi-source identity authentication services. Upon receiving a user's identity authentication request, the method first encapsulates it into a standardized internal request object. It then determines whether the request contains mandatory specified parameters. If mandatory specified parameters are present, the optimal target channel and backup channel are selected. Parameter conversion, data encryption, and signature generation are completed through a corresponding protocol adapter. An upstream call request is then generated, prioritizing the invocation of the optimal target channel. If the call succeeds, a standardized authentication response is returned. If the primary channel call fails, the method automatically switches to the backup channel to retry the call and return the corresponding authentication response. This application achieves intelligent scheduling of identity authentication channels and automatic fault recovery and retry, avoiding business interruptions caused by single-channel failures and effectively improving the continuity, stability, and resilience of identity authentication services.

Description

Technical Field

[0001] This application relates to the field of information security technology, and in particular to a unified scheduling method, apparatus, device and medium for multi-source identity authentication services. Background Technology

[0002] As digital transformation deepens and online businesses in key sectors such as finance, e-commerce, and government affairs are implemented on a large scale, various high-frequency, high-concurrency, and high-demand identity authentication business scenarios continue to expand. The industry as a whole has stringent requirements for the continuity of business operations, service stability, and resilience to sudden failures in identity authentication services. Once the identity authentication process is interrupted, it will directly lead to user business failures, transaction terminations, and government service delays, seriously affecting user experience and the normal operation of platform business.

[0003] The current mainstream identity authentication scheduling and invocation architecture adopts a traditional single-channel fixed invocation mode. The overall architecture design is simple and crude, lacking any intelligent disaster recovery mechanism for fault identification, automatic switching, and channel retry. During daily business operations, all authentication requests rely solely on a single fixed identity authentication channel, without alternative redundant channels for backup, automatic fault detection and switching logic, or abnormal retry scheduling strategies. When the sole primary authentication channel experiences network fluctuations, service provider outages, API call anomalies, link timeouts, server failures, or other unforeseen problems, it cannot promptly avoid faulty nodes or quickly switch to available authentication links. All identity authentication-related business requests will fail directly, causing instantaneous interruptions to all related services, processing delays, and transaction failures. The traditional fixed single-channel operation mode has extremely poor risk resistance and is completely unsuitable for the high-availability, uninterrupted, and stable operation requirements of core industries such as finance and government, fundamentally failing to guarantee the overall business continuity of identity authentication services. Summary of the Invention

[0004] To overcome the shortcomings of existing technologies, this invention provides a unified scheduling method, apparatus, equipment, and medium for multi-source identity authentication services, enabling intelligent scheduling of identity authentication channels and automatic fault recovery and retry, avoiding business interruption caused by single-channel failures, and effectively improving the continuity, stability, and risk resistance of identity authentication services.

[0005] The first aspect of this application provides a unified scheduling method for multi-source identity authentication services, the method comprising: Upon receiving a user's authentication request, the authentication request is encapsulated into a standardized internal request object; Determine whether the internal request object contains a parameter that must be specified. When it is determined that the internal request object does not have the mandatory specified parameter, the optimal target channel and backup channel among multiple authentication channels are determined. Obtain the corresponding protocol adapter instance based on the target channel identifier of the optimal target channel, and perform parameter conversion, data encryption and signature generation based on the protocol adapter instance to obtain the adapted upstream call request; Based on the upstream call request, a call is initiated to the upstream identity authentication service corresponding to the target channel identifier. If the optimal target channel call is successful, a first standardized authentication response is obtained and returned to the user. If the optimal target channel call fails, the system switches to the backup channel for retry. If the backup channel call succeeds, a second standardized authentication response is obtained and returned to the user.

[0006] In an optional implementation, determining the optimal target channel and backup channel when it is determined that the internal request object does not have the mandatory specified parameter includes: The initial candidate channel set is determined based on a preset channel priority list; The initial candidate channel set is filtered to generate a usable candidate channel set; Calculate the candidate channel score for each candidate channel in the available candidate channel set, and sort the candidate channels in descending order based on the candidate channel scores; The first sorted channel is determined as the optimal target channel, and the second sorted channel is determined as the backup channel.

[0007] In an optional implementation, the filtering process of the initial candidate channel set to generate a usable candidate channel set includes: Filter the non-compliant channels in the initial candidate channel set according to the data sensitivity level to obtain a compliant candidate channel set; the non-compliant channels are identity authentication service channels that do not meet the current business data compliance requirements. Obtain the health status, circuit breaker status, and quota balance of each compliance candidate channel in the set of compliance candidate channels; Based on the health status, channels corresponding to unhealthy states are excluded; based on the circuit breaker status, channels that have been circuit breaker-broken are excluded; based on the quota balance, channels corresponding to excess quota balance are excluded, thereby obtaining the set of available candidate channels.

[0008] In an optional implementation, when it is determined that the internal request object contains the forced specified parameter, the method further includes: Verify the availability of the specified channel corresponding to the forced specified parameters; When it is determined that the specified channel is available, the specified channel is designated as the optimal target channel; When it is determined that the specified channel is unavailable, an error message is returned and the operation of switching to the backup channel is not performed.

[0009] In an optional implementation, obtaining the first standardized authentication response if the optimal target channel call is successful includes: Obtain the original upstream response returned by the upstream identity authentication service; The upstream raw response is parsed according to the channel protocol of the optimal target channel to obtain the internal structured response data; The internal structured response data is mapped to a standard authentication status, and the internal structured response data is de-identified. The standard authentication status and the de-identified internal structured response data are encapsulated to generate the first standardized authentication response.

[0010] In an optional implementation, the method includes: Determine whether the backup channel failed to be invoked within a preset number of retries; When the backup channel fails to be invoked within the preset number of retries, the upstream identity authentication service call is terminated and a preset downgraded authentication result is returned. The downgraded authentication result is used to indicate the adoption of a downgraded authentication method and trigger manual review.

[0011] In an optional implementation, after returning the first standardized authentication response or the second standardized authentication response, the method further includes: Based on the channel identifier and corresponding authentication result of the actual call channel, update the sliding window statistics of the actual call channel; the actual call channel is the optimal target channel or the backup channel. When the optimal target channel is successfully called, the actual call channel is the optimal target channel. When the optimal target channel fails to be called and the backup channel is successfully called, the actual call channel is the backup channel. Based on the sliding window statistics, the circuit breaker status of the actual calling channel is determined and updated.

[0012] A second aspect of this application provides a unified scheduling device for multi-source identity authentication services, the device comprising: The request encapsulation module is used to encapsulate the user's authentication request into a standardized internal request object when it receives the authentication request. The parameter determination module is used to determine whether the internal request object has any mandatory specified parameters; The channel selection module is used to determine the optimal target channel and backup channel among multiple identity authentication channels when it is determined that the internal request object does not have the mandatory specified parameter; The protocol adaptation module is used to obtain the corresponding protocol adapter instance based on the target channel identifier of the optimal target channel, and perform parameter conversion, data encryption and signature generation based on the protocol adapter instance to obtain the adapted upstream call request. The main channel call processing module is used to initiate a call to the upstream identity authentication service corresponding to the target channel identifier based on the upstream call request. If the optimal target channel call is successful, a first standardized authentication response is obtained and returned to the user. The backup channel disaster recovery and retry module is used to switch to the backup channel for retry if the optimal target channel call fails, and to obtain a second standardized authentication response if the backup channel call succeeds, and return the second standardized authentication response to the user.

[0013] A third aspect of this application provides an electronic device, including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the computer program to implement the steps of the unified scheduling method for the multi-source authentication service.

[0014] A fourth aspect of this application provides a computer-readable storage medium having a computer program stored thereon, wherein the computer program, when executed by a processor, implements the steps of the above-described unified scheduling method for multi-source authentication services.

[0015] In summary, the unified scheduling method, apparatus, device, and medium for multi-source identity authentication services provided in this application encapsulate the user's identity authentication request into a standardized internal request object upon receipt, achieving unified data organization and laying the data foundation for multi-channel adaptive scheduling. By identifying whether the request contains mandatory specified parameters, it distinguishes differentiated calling scenarios, ensuring flexible adaptation to special authentication requirements. In conventional scenarios without mandatory specified parameters, it automatically selects and determines the optimal target channel and backup channel from multiple identity authentication channels, breaking the operational limitations of traditional single channels and building a multi-redundant channel fallback architecture. Then, relying on the protocol adapter instances corresponding to each channel, it completes parameter conversion, data encryption, and signature generation, achieving interface protocol and data format adaptation for different upstream identity authentication services and ensuring normal cross-channel call interaction. During business operations, the system prioritizes calling the optimal target channel to complete identity authentication request processing. Upon successful call, a standardized authentication response is quickly provided, ensuring the efficient operation of routine authentication services. When the optimal target channel encounters network fluctuations, service outages, interface anomalies, link timeouts, or other failures that cause call failures, the system can automatically trigger channel switching logic, seamlessly switching to a preset backup channel for retrying the call. With the help of a multi-channel linkage retry intelligent scheduling strategy, the system can promptly avoid faulty service nodes and bypass abnormal links to complete identity authentication interactions. Ultimately, even in the event of a primary channel failure, the system can still obtain a standardized authentication response and provide feedback to the user. This effectively avoids problems such as batch failures of authentication requests, interruptions of related services, transaction terminations, and service delays caused by a single channel failure. The system significantly improves the fault identification, automatic switching, and abnormal retry capabilities of the identity authentication service, strengthens the overall stability of the identity authentication service, and enhances its ability to withstand sudden failures. It fully meets the stringent business requirements of multiple fields for high continuity, high availability, and uninterrupted operation of identity authentication services, fundamentally ensuring the smooth and orderly operation of the identity authentication process and related online services. Attached Figure Description

[0016] Figure 1 This is a flowchart illustrating a unified scheduling method for multi-source identity authentication services, as shown in an embodiment of this application. Figure 2 This is a schematic diagram of the system architecture of a unified scheduling platform for multi-source identity authentication services, as shown in an embodiment of this application. Figure 3 This is a schematic diagram illustrating the working principle of a protocol adaptation layer according to an embodiment of this application; Figure 4 This is a functional block diagram of a unified scheduling device for multi-source identity authentication services, as shown in an embodiment of this application. Figure 5 This is a schematic diagram of the structure of an electronic device shown in an embodiment of this application. Detailed Implementation

[0017] The present invention will be further described below with reference to the accompanying drawings and embodiments.

[0018] The following will clearly and completely describe the concept, specific structure, and technical effects of the present invention in conjunction with embodiments and accompanying drawings, so as to fully understand the purpose, features, and effects of the present invention. Obviously, the described embodiments are only a part of the embodiments of the present invention, not all of them. Other embodiments obtained by those skilled in the art based on the embodiments of the present invention without creative effort are all within the scope of protection of the present invention. Furthermore, all connections / linkages involved in the patent do not simply refer to direct contact between components, but rather to the ability to form a better connection structure by adding or reducing connecting accessories according to specific implementation conditions. The various technical features in this invention can be combined interactively without contradicting each other.

[0019] In addition, existing identity authentication access and scheduling solutions have the following problems: First, the interface protocols, encryption methods, and data formats of various service providers differ greatly, requiring business systems to be connected and adapted one by one, resulting in high access costs and serious duplication of development. When adding a new authentication channel, the business side needs to make a complete transformation. Second, scheduling relies on hard-coded or simple configuration files to specify channels, lacking dynamic decision-making and strategy optimization capabilities, and unable to flexibly select routes based on factors such as success rate, cost, timeliness, and compliance. Third, each authentication channel is deployed independently and managed in a decentralized manner, lacking a unified monitoring and operation and maintenance view, resulting in a large number of monitoring blind spots, low operation and maintenance efficiency, and slow fault location.

[0020] The unified scheduling platform for multi-source identity authentication services (hereinafter referred to as the platform) is integrated into electronic devices. In order to facilitate understanding of the inventive concept of this application, the unified scheduling method of multi-source identity authentication services will be described below using the unified scheduling platform for multi-source identity authentication services.

[0021] Reference Figure 1 The diagram shown is a flowchart illustrating a unified scheduling method for multi-source identity authentication services according to an embodiment of this application. The unified scheduling method for multi-source identity authentication services includes the following steps.

[0022] S11, When a user's authentication request is received, the authentication request is encapsulated into a standardized internal request object.

[0023] Refer to together Figure 2In some embodiments, when the platform receives an HTTP or HTTPS request (i.e., an authentication request containing relevant information for authentication) from a business party in the application layer, it performs pre-processing. Identity authentication is performed, verifying the legitimacy of access based on the caller's AppKey and request signature, blocking illegal and forged requests, and implementing traffic control through a token bucket rate limiting mechanism to ensure a stable and controllable overall call frequency. Next, schema parameter validation is performed on the request message, eliminating invalid requests with missing fields or abnormal formats, and assigning unique business tags such as business scenario and data sensitivity level to legitimate requests that pass validation, completing end-to-end tagging.

[0024] After pre-processing, the platform can parse the authentication type from the HTTP or HTTPS request. Authentication types include, but are not limited to: two-factor authentication (name and ID number), three-factor authentication (name, ID number, and mobile phone number or bank card number), and liveness detection (face recognition). Simultaneously, it extracts possible routing parameters from the HTTP or HTTPS request. These routing parameters guide subsequent channel selection and scheduling strategies. These routing parameters include, but are not limited to: Provider (mandatory designated authentication service channel), such as third-party platforms, including Tencent, Aliyun, Mobile, Baidu, Turui, Tutang, etc.; that is, multiple identity authentication channels can include Tencent, Aliyun, Mobile, Baidu, Turui, and Tutang, etc.

[0025] Strategy, such as quality, cost, balance, compliance, etc.

[0026] Priority (request priority), such as urgent, normal, low, etc.

[0027] Next, the platform performs validity checks on the extracted routing parameters to ensure their integrity and correctness, including but not limited to: ID card number format verification (checking whether the ID card number conforms to the national standard format) and encrypted storage of sensitive information (encrypting sensitive information such as ID card numbers and mobile phone numbers to ensure the security of data transmission and storage). The parsed authentication type, routing parameters (after verification), and any other necessary information (such as request timestamps and business identifiers) are then encapsulated into a standardized internal request object to ensure the consistency and standardization of request information flow within the system.

[0028] S12, determine whether the internal request object has a mandatory specified parameter.

[0029] Once the standardized internal request object is obtained, the electronic device first checks whether the standardized internal request object contains the mandatory specified channel parameter (i.e., provider) to determine the specified channel corresponding to the provider.

[0030] S13, when it is determined that the internal request object does not have the mandatory specified parameter, determine the optimal target channel and backup channel among multiple identity authentication channels.

[0031] If no parameters are explicitly specified, the platform retrieves the default channel priority list for that business line from the configuration center. This channel priority list is pre-set for different business lines and authentication types, for example, the channel priority list is tencent→aliyun→baidu→....... The platform reads the business line and authentication type of the current request, loads the matching default channel priority list from the configuration center, and adds all channels in the list to the initial candidate channel set, completing the initialization of the candidate pool.

[0032] Next, the initial candidate channel set is filtered to generate a set of available candidate channels. The first step involves filtering non-compliant channels from the initial candidate channel set based on data sensitivity levels to obtain a set of compliant candidate channels. Non-compliant channels refer to identity authentication service channels that do not meet the current business data compliance requirements. Electronic devices perform matching and verification based on the data sensitivity level of the business scenario to which the request belongs. For example, highly sensitive data in government affairs or finance is forcibly restricted to designated channels such as those provided by operators. Channels that do not comply with data location, storage specifications, transmission requirements, and regulatory provisions are removed from the initial candidate channel set, retaining only those that meet compliance requirements to form the compliant candidate channel set. The second step involves performing three judgments in sequence: channel health judgment, non-circuit breaker judgment, and quota sufficiency judgment. Channel health refers to the ability of the identity authentication channel to normally receive, process, and respond to identity authentication requests at the current moment. For example, electronic devices periodically send probe requests to a channel. If a valid response is returned within a preset timeout, it is considered probe healthy. The system counts the actual business requests for the channel within the last N seconds. If the availability rate is ≥ a preset health threshold (e.g., ≥ 95%), it is considered statistically healthy. If both probe and statistical health are met, the channel is marked as healthy; otherwise, it is marked as unhealthy. Electronic devices can count the total number of calls, failures, and timeouts for the channel within a window (e.g., 10 seconds / 30 seconds); calculate the error rate as (failures + timeouts) / total calls; if the error rate is < the circuit breaker threshold (e.g., < 30%) and no manual circuit breaker is triggered, it is considered unbroken; if the error rate is ≥ the circuit breaker threshold, the circuit breaker opens, and the channel is marked as broken; after breaking, it enters a half-open probe cycle. If the probe is successful, it automatically returns to unbroken status. Simultaneously, electronic devices can also read the channel's daily / hourly / account total quota from the platform's cache / configuration center; read the used quota (accumulated in real time); and calculate the remaining quota = total quota. Quota already used; if the remaining quota is greater than or equal to the quota required for a single call (usually 1), it is considered that the quota is sufficient; if the remaining quota is less than the quota required for a single call, it is considered that the quota is insufficient. Electronic devices verify each channel in the initial candidate channel set one by one. Only channels that simultaneously meet the conditions of being healthy, not having been circuit-broken, and having sufficient quota are retained. Channels that do not meet any of the conditions are directly eliminated, and finally, a set of available candidate channels is formed.

[0033] Furthermore, the candidate channel score for each candidate channel in the available candidate channel set is calculated and sorted in descending order of candidate channel score. The platform uses a multi-factor weighted decision algorithm for scoring, comprehensively considering four dimensions: success rate, call cost, response time, and compliance. Weights are dynamically allocated based on the current scheduling strategy (quality priority, cost priority, balance priority, compliance priority). The real-time metrics of each channel are substituted into the weighted formula success rate × w1 + cost × w2 + response time × w3 + compliance × w4 to calculate the candidate channel score, where w1, w2, w3, and w4 are the weights corresponding to success rate, cost, response time, and compliance, respectively. The quality-first strategy increases the weight of success rate and timeliness, for example, w1=0.5, w2=0.1, w3=0.3, w4=0.1; the cost-first strategy increases the weight of cost, w1=0.3, w2=0.5, w3=0.1, w4=0.1; the compliance-first strategy prioritizes meeting the high compliance requirements of government affairs, finance, etc., w1=0.2, w2=0.1, w3=0.2, w4=0.5. After calculation, all available candidate channels are sorted from highest to lowest score.

[0034] Finally, the first ranked channel is determined as the optimal target channel, and the second ranked channel is determined as the backup channel. Both the target channel identifier (e.g., tencent) and the backup channel identifier (e.g., aliyun) are returned. The first ranked channel is the best performing channel under the current real-time conditions and serves as the primary call channel for this request; the second ranked channel serves as an emergency redundancy channel for seamless switching in case of primary call channel failure. Through these steps, the platform achieves dynamic, intelligent, and stable channel selection. Without relying on hard-coding or fixed configurations, it automatically outputs the optimal target channel and backup channel, providing reliable support for subsequent upstream calls and fault recovery, ensuring high availability, high efficiency, and high stability of the identity authentication service.

[0035] In an optional implementation, when it is determined that the internal request object contains the forced specified parameter, the method further includes: Verify the availability of the specified channel corresponding to the forced specified parameters; When it is determined that the specified channel is available, the pointed channel is determined as the optimal target channel; When it is determined that the specified channel is unavailable, an error message is returned and the operation of switching to the backup channel is not performed.

[0036] In some embodiments, if a mandatory provider parameter is specified, meaning the business explicitly specifies the use of a particular service provider's channel, the platform queries the status manager to obtain the health status (e.g., response time, error rate), circuit breaker status (whether a circuit breaker has been triggered), and current quota balance of the mandatory specified channel to verify its availability. If the channel is healthy, not under circuit breaker, and has sufficient quota balance, the specified channel is directly selected as the target channel. If the channel is unavailable (e.g., under circuit breaker, exceeding quota, or abnormal), an error message is returned, and the channel is not automatically switched (respecting the business's mandatory requirement).

[0037] S14. Obtain the corresponding protocol adapter instance based on the target channel identifier of the optimal target channel, and perform parameter conversion, data encryption and signature generation based on the protocol adapter instance to obtain the adapted upstream call request.

[0038] Refer to together Figure 3In some embodiments, after obtaining the target channel identifier of the optimal target channel, the corresponding protocol adapter instance can be obtained based on the target channel identifier. The platform can pre-construct a protocol adapter factory using the adapter pattern and the factory pattern. This adapter factory encapsulates adapter instances that correspond one-to-one with each authentication channel, including Tencent Cloud adapters, Alibaba Cloud adapters, mobile operator adapters, Baidu Cloud adapters, Tui Rui adapters, and Tu Teng adapters. Different adapters adapt to the specific transmission and encryption protocols of their respective upstream service providers. For example, the Tencent Cloud adapter uses the JSON+RSA protocol, the Alibaba Cloud adapter uses the JSON+AES protocol, the mobile adapter uses the TCP+SM2 national cryptographic protocol, and other third-party adapters adapt to their respective private proprietary protocols, achieving unified compatibility encapsulation of heterogeneous upstream interfaces. Each adapter corresponds to a unique channel identifier, perfectly matching the interface specifications, encryption methods, signature rules, and message structure of a specific upstream authentication service. Based on the target channel identifier, the platform matches and obtains the protocol adapter instance uniquely corresponding to that channel from the adapter factory, ensuring the accuracy and specificity of the adaptation logic. The adapter factory can accurately route and instantiate corresponding dedicated adapters according to different target channel types, achieving a one-to-one precise binding between channel identifiers and adapter instances. After obtaining the protocol adapter instance, the platform takes a standardized internal request object as input. This standardized internal request is uniformly pre-configured with a general field structure of {name, idCard, phone, type}, eliminating differences in input parameters on the business side. The adapter then performs three core processes. First, parameter conversion (also known as parameter mapping) maps and reconstructs the platform's unified field names, data structures, and authentication elements according to the field names, parameter order, and message format required by the corresponding upstream channel, ensuring that the parameter format conforms to the upstream interface requirements. Second, data encryption encrypts sensitive identity information such as ID card numbers, names, mobile phone numbers, and bank card numbers according to the encryption algorithms specified by the upstream channel, including but not limited to JSON+RSA, JSON+AES, TCP+SM2, and domestic cryptographic algorithms, ensuring secure data transmission. Third, signature generation calculates the signature of the request message and adds a signature field according to the signature rules, key, and participating signature fields specified by the upstream interface, completing the interface authentication preparation. The above three steps constitute the standard execution logic for all adapters. Only the underlying encryption algorithm and field mapping rules are adaptively adjusted according to differences in upstream channels. After processing, a legitimate call message that can directly connect to various upstream API Endpoints is generated. After parameter conversion, data encryption, and signature generation, the adapter outputs a complete call message that conforms to the upstream identity authentication service interface specification, i.e., the adapted upstream call request. This request can be directly received, parsed, and processed by the upstream service, providing a legitimate, valid, and executable request carrier for subsequent real calls.

[0039] S15, based on the upstream call request, initiate a call to the upstream identity authentication service corresponding to the target channel identifier. If the optimal target channel call is successful, obtain the first standardized authentication response and return the first standardized authentication response to the user.

[0040] After receiving the adapted upstream call request, the platform dynamically sets the corresponding timeout policy based on the authentication type to ensure call efficiency and system stability. For example, for two-factor authentication, a connection timeout of 3 seconds and a read timeout of 5 seconds are set; for three-factor authentication, a connection timeout of 3 seconds and a read timeout of 8 seconds are set; and for liveness detection, a connection timeout of 5 seconds and a read timeout of 15 seconds are set. After the timeout policy is loaded, the platform sends the adapted upstream call request to the upstream identity authentication service interface corresponding to the target channel identifier via HTTP or TCP, according to the transmission protocol supported by the upstream channel, and waits to receive the return result. If the upstream identity authentication service returns a valid response message within the timeout period, and the message does not contain errors such as system anomalies or service unavailability, the optimal target channel call is considered successful. The platform then performs standardized processing on the original upstream response message to generate a first standardized authentication response, which is subsequently returned to the business party.

[0041] In an optional implementation, obtaining the first standardized authentication response if the optimal target channel call is successful includes: Obtain the original upstream response returned by the upstream identity authentication service; The upstream raw response is parsed according to the channel protocol of the optimal target channel to obtain the internal structured response data; The internal structured response data is mapped to a standard authentication status, and the internal structured response data is de-identified. The standard authentication status and the de-identified internal structured response data are encapsulated to generate the first standardized authentication response.

[0042] In some embodiments, the platform obtains the original upstream response returned by the upstream identity authentication service. This response is the original message returned by the third-party identity authentication service provider according to its own interface specifications. The original upstream responses corresponding to different channels differ in message format, field names, and encoding methods. The returned messages from upstream services such as Tencent Cloud, Alibaba Cloud, mobile operators, Baidu Cloud, Tuorui, and Tuteng all maintain their original formats and have not been processed by the platform. The platform parses the original upstream response according to the protocol rules corresponding to the target channel. The platform parses the original upstream response according to the channel protocol corresponding to the optimal target channel to obtain internal structured response data. Since the protocols of each upstream identity authentication service are different, the platform decomposes, verifies, and reconstructs the unstructured, multi-format original response message according to the parsing rules matching the optimal target channel. This converts the scattered and heterogeneous return information into unified key-value pair structured data within the platform, giving the response information a unified data format and access method, and providing a unified data foundation for subsequent standardized processing.

[0043] Next, the platform maps the internal structured response data to standard authentication statuses and performs anonymization processing on the internal structured response data. The standard authentication status is a unified authentication result identifier predefined by the platform, used to mask the differences in return codes from various upstream service providers and achieve a unified representation of multi-source responses. The anonymization processing targets sensitive user identity information contained in the internal structured response data, masking sensitive fields according to data security specifications to prevent privacy leaks while retaining necessary business-usable information. For example, upstream returns of "match" or "consistent" are uniformly mapped to authentication passed; "inconsistent" or "verification failed" are mapped to authentication failed; "requires manual review" or "questionable" are mapped to suspected risk; "no information" or "not in the database" are mapped to no record in the database; and "service abnormal" or "system error" are mapped to system abnormalities, ensuring that business users do not need to adapt to multiple sets of return rules. Furthermore, the platform anonymizes sensitive information in the responses. For ID card numbers, it retains the first 3 and last 4 digits, hiding the middle portion; for names, it retains only the surname, replacing the given name with asterisks; for mobile phone numbers, it retains the first 3 and last 4 digits, hiding the middle numbers. This satisfies both business verification needs and data security and privacy protection requirements. For example, ID card number 110***********1234 (retaining the first 3 and last 4 digits), name Zhang* (retaining the surname), mobile phone number 138****8888.

[0044] Finally, the platform encapsulates the standard authentication status and the anonymized internal structured response data according to a preset unified format to generate a first standardized authentication response. This response has a fixed structure, unified fields, and standardized encoding, and can be directly recognized and parsed by various business systems without the need for adaptation or modification for different upstream service providers. The platform returns this first standardized authentication response as the final authentication result to the business party, completing the entire process of this identity authentication.

[0045] S16, if the optimal target channel call fails, switch to the backup channel for retry; if the backup channel call succeeds, obtain the second standardized authentication response and return the second standardized authentication response to the user.

[0046] When the platform initiates an upstream identity authentication service call based on the optimal target channel, if a call fails due to connection timeout, read timeout, network transmission anomalies, upstream service error codes, or service unavailability, the optimal target channel call is deemed a failure. In this case, the platform immediately executes a failover and retry mechanism. Based on the backup channel identifier determined during the previous routing decision phase, the call chain is switched from the optimal target channel to the corresponding backup channel, and protocol adaptation, request encapsulation, and upstream call processes are re-executed based on the backup channel. The platform retrieves a matching protocol adapter instance from the adapter factory based on the backup channel identifier, performs parameter conversion, data encryption, and signature generation on the standardized internal request object, obtaining an upstream call request adapted to the backup channel protocol specification, and completes the call parameter configuration according to the timeout policy corresponding to the current authentication type. Subsequently, a retry call is initiated to the upstream identity authentication service interface corresponding to the backup channel via HTTP or TCP protocol. If the backup channel call succeeds within the limited number of attempts, the platform obtains the original upstream response returned by the backup channel and generates a second standardized authentication response according to the same standardized processing procedure as the first standardized authentication response. This involves parsing the original upstream response according to the backup channel's protocol to obtain internal structured response data, mapping this internal structured response data to a unified standard authentication status, de-identifying sensitive information within the internal structured response data, and then encapsulating the standard authentication status and the de-identified internal structured response data in a unified format to obtain the final second standardized authentication response. The platform has a preset retry count of 2. Within this retry count, if the backup channel successfully returns a valid response message, the retry is considered successful. The platform returns the generated second standardized authentication response to the user as a valid authentication result, achieving seamless disaster recovery switching in the event of a primary channel failure. This ensures that identity authentication requests can be executed normally and return a unified format response result without interrupting business processes or changing the business interface, effectively improving the overall system availability and business continuity.

[0047] Alternatively, if, after the platform switches the call chain to a backup channel and completes the retries, the backup channel still experiences call failures such as connection timeouts, read timeouts, network anomalies, upstream service errors, or service unavailability, and the number of retries has reached the preset maximum (i.e., 2 times), the platform determines that both the optimal target channel and the backup channel for this authentication have failed, and the overall authentication call process has failed. At this point, the platform immediately triggers a preset degradation mechanism, a pre-configured business fallback strategy. For example, it might downgrade the original three-factor or liveness authentication to two-factor authentication and simultaneously initiate a manual review process to ensure uninterrupted and unblocked business operations. After triggering the degradation mechanism, the platform generates a preset degradation authentication result according to a unified standard. This result includes a clear degradation identifier, failure reason, unique request identifier, and fallback handling prompts, enabling the business party to clearly identify the current state and perform subsequent processing. The platform returns the preset downgraded authentication result to the business side through a unified interface. Even in extreme scenarios where multiple channels are abnormal, it can still provide a clear, stable, and predictable response to the business system, avoiding the collapse of the front-end business due to the complete failure of the third-party authentication service, and maximizing the availability of identity authentication services and business continuity.

[0048] By prioritizing the main channel and automatically retrying the backup channel, the platform effectively avoids the interruption of authentication services due to single-channel failures, improves the availability, stability and continuity of identity authentication services, and ensures that the authentication process can still be reliably completed in complex network environments and scenarios with fluctuating third-party services.

[0049] In an optional implementation, after returning the first standardized authentication response or the second standardized authentication response, the method further includes: Based on the channel identifier and corresponding authentication result of the actual call channel, update the sliding window statistics of the actual call channel; the actual call channel is the optimal target channel or the backup channel. When the optimal target channel is successfully called, the actual call channel is the optimal target channel. When the optimal target channel fails to be called and the backup channel is successfully called, the actual call channel is the backup channel. Based on the sliding window statistics, the circuit breaker status of the actual calling channel is determined and updated.

[0050] In some embodiments, after returning the standardized authentication response to the business party, the platform asynchronously executes a post-processing flow. This process is independent of the main call chain, does not increase the time consumption of the main authentication process, and ensures business response efficiency. First, the platform records a complete call log based on relevant information (after anonymization), such as the request parameters, target channel identifier, actual call channel, response time, authentication result status (e.g., SUCCESS / FAIL), and cost consumption (e.g., upstream API fees), forming a traceable and auditable end-to-end call record. The log data is written to ELK (Elasticsearch + Logstash + Kibana) or a database (e.g., MySQL), and the call data for the most recent 5 minutes (configurable) is maintained using Redis ZSET or a time-series database (e.g., InfluxDB). Subsequently, based on the success / failure status and time consumption data in the call log, the statistical indicators of the actual call channel are updated in real time through a sliding window statistical method, including channel success rate (number of successful calls / total number of calls), average response time (total time / number of successful calls), real-time QPS (queries per second (total number of calls / time window seconds)), etc. The calculation results are stored in Redis for use in circuit breaker checks and routing decisions.

[0051] Next, the platform performs circuit breaker checks based on the updated channel statistics. It determines whether to isolate the actual calling channel from the circuit breaker state or restore it based on a preset error rate threshold, achieving automatic detection and self-healing control of channel faults. Simultaneously, the platform reports billing data in real time based on the authentication call information, accumulating the current channel call volume and generating standardized billing data for reconciliation and settlement. For example, the circuit breaker trigger condition can be set to the number of consecutive failures exceeding a threshold (e.g., 5 times) and / or the success rate being lower than a threshold (e.g., 80%) for 1 minute. The circuit breaker recovery condition can be set to check every minute after the circuit breaker is triggered; if the number of consecutive successes exceeds a threshold (e.g., 3 times), the channel is restored. When the circuit breaker is triggered, the channel status is updated to "under circuit breaker" and written to the configuration center (e.g., Nacos). When the circuit breaker is restored, the status is updated to "healthy" and the routing decision module is notified. Finally, the platform monitors the channel statistics and circuit breaker status in real time. When a sudden drop in channel success rate, a sudden increase in response time, a call cost exceeding the budget threshold, or an abnormal status occurs, an anomaly alarm is immediately triggered to allow maintenance personnel to handle the situation promptly and ensure the overall stable operation of the multi-source identity authentication service. For example, when the success rate drops sharply (e.g., from 95% to 70%), and / or the average response time increases sharply (e.g., exceeding 2 seconds), and / or the cost exceeds the budget (e.g., daily cost exceeds 1000 yuan), an alarm is triggered via Prometheus+Alertmanager on WeChat / email. The alarm content includes: metric name, current value, threshold, and channel identifier.

[0052] Meanwhile, the platform can count the daily number of calls by channels and business lines to obtain the cumulative call volume, store it in the database (such as MySQL table and database partitioning), and generate a reconciliation file in CSV or JSON format based on the summarized call volume and cost consumption, which can then be uploaded to object storage (such as OSS) or pushed to the financial system.

[0053] Reference Figure 4 The diagram shown is a functional block diagram of a unified scheduling device for multi-source identity authentication services, as illustrated in an embodiment of this application.

[0054] In some embodiments, the unified scheduling device 40 for the multi-source authentication service may include multiple functional modules composed of computer program segments. The computer programs for each program segment of the unified scheduling device 40 for the multi-source authentication service may be stored in the memory of an electronic device and executed by at least one processor to perform (see details). Figure 1 (Description) This application describes the unified scheduling function of a multi-source identity authentication service. Based on its functions, it can be divided into multiple functional modules. These modules may include: a request encapsulation module 401, a parameter judgment module 402, a channel selection module 403, a protocol adaptation module 404, a main channel call processing module 405, and a backup channel disaster recovery and retry module 406. The term "module" in this application refers to a series of computer program segments that can be executed by at least one processor and perform a fixed function, stored in memory. In this embodiment, the functions of each module will be detailed in subsequent embodiments.

[0055] The request encapsulation module 401 is used to encapsulate the user's authentication request into a standardized internal request object when it receives the user's authentication request.

[0056] The parameter determination module 402 is used to determine whether the internal request object has a mandatory specified parameter.

[0057] The channel selection module 403 is used to determine the optimal target channel and backup channel among multiple identity authentication channels when it is determined that the internal request object does not have the mandatory specified parameter.

[0058] The protocol adaptation module 404 is used to obtain the corresponding protocol adapter instance based on the target channel identifier of the optimal target channel, and perform parameter conversion, data encryption and signature generation based on the protocol adapter instance to obtain the adapted upstream call request.

[0059] The main channel call processing module 405 is used to initiate a call to the upstream identity authentication service corresponding to the target channel identifier based on the upstream call request. If the optimal target channel call is successful, a first standardized authentication response is obtained and the first standardized authentication response is returned to the user.

[0060] The backup channel disaster recovery retry module 406 is used to switch to the backup channel for retry if the optimal target channel call fails, and to obtain a second standardized authentication response if the backup channel call succeeds, and return the second standardized authentication response to the user.

[0061] It should be understood that the various variations and specific embodiments of the unified scheduling method for multi-source identity authentication services provided in the above embodiments are also applicable to the unified scheduling device for multi-source identity authentication services in this embodiment. Through the foregoing detailed description of the unified scheduling method for multi-source identity authentication services, those skilled in the art can clearly understand the implementation method of the unified scheduling device for multi-source identity authentication services in this embodiment. For the sake of brevity, it will not be described in detail here.

[0062] See Figure 5 The diagram shown is a schematic representation of the structure of an electronic device according to an embodiment of this application. In a preferred embodiment of this application, the electronic device 5 includes a memory 51, at least one processor 52, and at least one communication bus 53.

[0063] Those skilled in the art should understand that Figure 5 The structure of the electronic device shown does not constitute a limitation of the embodiments of this application. It can be a bus structure or a star structure. The electronic device 5 may also include more or fewer other hardware or software than shown, or different component arrangements.

[0064] In some embodiments, the electronic device 5 is a device capable of automatically performing numerical calculations and / or information processing according to pre-set or stored instructions. Its hardware includes, but is not limited to, microprocessors, application-specific integrated circuits (ASICs), programmable gate arrays (FPGAs), digital processors, and embedded devices. The electronic device 5 may also include user equipment, which includes, but is not limited to, any electronic product capable of human-computer interaction with a user via a keyboard, mouse, remote control, touchpad, or voice control device, such as a personal computer, tablet computer, smartphone, or digital camera.

[0065] In the embodiments provided in this application, it should be understood that the disclosed methods, apparatuses, computer-readable storage media, and electronic devices can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative. For instance, the division of modules is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple components or modules may be combined or integrated into another device, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be through some interfaces; the indirect coupling or communication connection between devices, components, or modules may be electrical, mechanical, or other forms.

[0066] The components described as separate parts may or may not be physically separate. The components shown as components may or may not be physical modules; that is, they may be located in one place or distributed across multiple network modules. Some or all of the components can be selected to achieve the purpose of this embodiment according to actual needs.

[0067] Furthermore, the functional modules in the various embodiments of the present invention can be integrated into one processing module, or each component can exist physically separately, or two or more modules can be integrated into one module. The integrated modules described above can be implemented in hardware or as software functional modules.

[0068] If the integrated module is implemented as a software functional module and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of the present invention, in essence, or the part that contributes to the prior art, or all or part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of the present invention. The aforementioned storage medium includes: USB flash drive, portable hard drive, read-only memory (ROM). Various media that can store program code, such as only memory, random access memory (RAM), magnetic disks or optical disks.

[0069] It should be noted that, for the sake of simplicity, the foregoing method embodiments are all described as a series of actions. However, those skilled in the art should understand that the present invention is not limited to the described order of actions, because according to the present invention, some steps can be performed in other orders or simultaneously. Furthermore, those skilled in the art should also understand that the embodiments described in the specification are preferred embodiments, and the actions and modules involved are not necessarily essential to the present invention.

[0070] In the above embodiments, the descriptions of each embodiment have different focuses. For parts not described in detail in a certain embodiment, please refer to the relevant descriptions in other embodiments.

[0071] The above is a detailed description of the preferred embodiments of the present invention. However, the present invention is not limited to the embodiments described. Those skilled in the art can make various equivalent modifications or substitutions without departing from the spirit of the present invention. All such equivalent modifications or substitutions are included within the scope defined by the claims of this application.

Claims

1. A unified scheduling method for multi-source identity authentication services, characterized in that, The method includes: Upon receiving a user's authentication request, the authentication request is encapsulated into a standardized internal request object; Determine whether the internal request object contains a parameter that must be specified. When it is determined that the internal request object does not have the mandatory specified parameter, the optimal target channel and backup channel among multiple authentication channels are determined. Obtain the corresponding protocol adapter instance based on the target channel identifier of the optimal target channel, and perform parameter conversion, data encryption and signature generation based on the protocol adapter instance to obtain the adapted upstream call request; Based on the upstream call request, a call is initiated to the upstream identity authentication service corresponding to the target channel identifier. If the optimal target channel call is successful, a first standardized authentication response is obtained and returned to the user. If the optimal target channel call fails, the system switches to the backup channel for retry. If the backup channel call succeeds, a second standardized authentication response is obtained and returned to the user.

2. The unified scheduling method for multi-source identity authentication services according to claim 1, characterized in that, When it is determined that the internal request object does not have the mandatory specified parameter, determining the optimal target channel and the backup channel includes: The initial candidate channel set is determined based on a preset channel priority list; The initial candidate channel set is filtered to generate a usable candidate channel set; Calculate the candidate channel score for each candidate channel in the available candidate channel set, and sort the candidate channels in descending order based on the candidate channel scores; The first sorted channel is determined as the optimal target channel, and the second sorted channel is determined as the backup channel.

3. The unified scheduling method for multi-source identity authentication services according to claim 2, characterized in that, The step of filtering the initial candidate channel set to generate a usable candidate channel set includes: Filter the non-compliant channels in the initial candidate channel set according to the data sensitivity level to obtain a compliant candidate channel set; the non-compliant channels are identity authentication service channels that do not meet the current business data compliance requirements. Obtain the health status, circuit breaker status, and quota balance of each compliance candidate channel in the set of compliance candidate channels; Based on the health status, channels corresponding to unhealthy states are excluded; based on the circuit breaker status, channels that have been circuit breaker-broken are excluded; based on the quota balance, channels corresponding to excess quota balance are excluded, thereby obtaining the set of available candidate channels.

4. The unified scheduling method for multi-source identity authentication services according to claim 1, characterized in that, When it is determined that the internal request object contains the forced specified parameter, the method further includes: Verify the availability of the specified channel corresponding to the forced specified parameters; When it is determined that the specified channel is available, the specified channel is designated as the optimal target channel; When it is determined that the specified channel is unavailable, an error message is returned and the operation of switching to the backup channel is not performed.

5. The unified scheduling method for multi-source identity authentication services according to claim 1, characterized in that, If the optimal target channel call is successful, the first standardized authentication response will be obtained, including: Obtain the original upstream response returned by the upstream identity authentication service; The upstream raw response is parsed according to the channel protocol of the optimal target channel to obtain the internal structured response data; The internal structured response data is mapped to a standard authentication status, and the internal structured response data is de-identified. The standard authentication status and the de-identified internal structured response data are encapsulated to generate the first standardized authentication response.

6. The unified scheduling method for multi-source identity authentication services according to claim 1, characterized in that, The method includes: Determine whether the backup channel failed to be invoked within a preset number of retries; When the backup channel fails to be invoked within the preset number of retries, the upstream identity authentication service call is terminated and a preset downgraded authentication result is returned. The downgraded authentication result is used to indicate the adoption of a downgraded authentication method and trigger manual review.

7. The unified scheduling method for multi-source identity authentication services according to any one of claims 1 to 6, characterized in that, After returning the first standardized authentication response or the second standardized authentication response, the method further includes: Based on the channel identifier and corresponding authentication result of the actual call channel, update the sliding window statistics of the actual call channel; the actual call channel is the optimal target channel or the backup channel. When the optimal target channel is successfully called, the actual call channel is the optimal target channel. When the optimal target channel fails to be called and the backup channel is successfully called, the actual call channel is the backup channel. Based on the sliding window statistics, the circuit breaker status of the actual calling channel is determined and updated.

8. A unified scheduling device for multi-source identity authentication services, characterized in that, The device includes: The request encapsulation module is used to encapsulate the user's authentication request into a standardized internal request object when it receives the authentication request. The parameter determination module is used to determine whether the internal request object has any mandatory specified parameters; The channel selection module is used to determine the optimal target channel and backup channel among multiple identity authentication channels when it is determined that the internal request object does not have the mandatory specified parameter; The protocol adaptation module is used to obtain the corresponding protocol adapter instance based on the target channel identifier of the optimal target channel, and perform parameter conversion, data encryption and signature generation based on the protocol adapter instance to obtain the adapted upstream call request. The main channel call processing module is used to initiate a call to the upstream identity authentication service corresponding to the target channel identifier based on the upstream call request. If the optimal target channel call is successful, a first standardized authentication response is obtained and returned to the user. The backup channel disaster recovery and retry module is used to switch to the backup channel for retry if the optimal target channel call fails, and to obtain a second standardized authentication response if the backup channel call succeeds, and return the second standardized authentication response to the user.

9. An electronic device, characterized in that, The method includes a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the computer program to implement the steps of the unified scheduling method for the multi-source authentication service as described in any one of claims 1 to 7.

10. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by a processor, it implements the steps of the unified scheduling method for multi-source identity authentication services as described in any one of claims 1 to 7.

Images