A cloud customer real-name authentication control method, electronic equipment and storage medium

Abstract

The application relates to the technical field of cloud services, and discloses a cloud customer real-name authentication control method, an electronic device and a storage medium. The method comprises the following steps: querying an authentication log of a state in a last authentication, and executing an interruption sub-process for system authentication; rejecting the current authentication request for work order authentication; routing the current authentication request to a corresponding authentication strategy according to a customer type and a certificate type, and generating a code scanning link carrying a request identifier and a timestamp; receiving a code scanning callback request and performing verification; if the verification is passed, performing authentication arrangement under the protection of a distributed lock with customer identification as the granularity; receiving a callback of a third-party face recognition service, updating the authentication state in a customer table and an authentication log table, and performing idempotent control on work order creation based on a persisted work order identifier. In a single main account authentication entrance, the system authentication channel and the work order authentication channel on the same customer are subjected to differential mutual exclusion and interruption control arrangement, so that the state disorder problem caused by multi-channel concurrent conflict is solved.

Description

Technical Field

[0001] The embodiments of the present invention relate to the field of cloud service technology, and in particular to a control method, electronic device and storage medium for real-name authentication of cloud customers. Background Technology

[0002] In the cloud operator's customer center scenario, the main account user initiates real-name authentication or authentication change through the unified console entry. Unlike the general "single-time identity verification," this scenario has three significant characteristics: 1. At the same time, the same customer may have two parallel authentication processes: "system authentication" which is initiated directly by the system and redirects to a third-party facial recognition system, and "work order authentication" which requires the intervention and review of operations personnel; the interruptibility and mutual exclusion requirements of the two channels are different.

[0003] 2. Authenticated customers can initiate authentication changes. When making a change, facial recognition verification of the "original holder" is required. The verification subject of the original holder changes dynamically according to the original customer type and the owner of the certificate (individual, corporate legal person or agent).

[0004] 3. Authentication status is recorded in the customer master data table, authentication log table, and face callback table, and the closed loop is completed through multiple external interactions such as scanning QR codes to jump to third-party face recognition vendors and asynchronous message triggering work orders; QR code callbacks and vendor asynchronous callbacks may arrive concurrently.

[0005] One related technology employs adaptive authentication based on the target user's risk level information. Among various authentication methods such as real-name authentication, biometrics, temporary keys, and SMS verification, it selects an appropriate number of authentication methods according to risk level (Level 1 / 2 / 3), addressing the problem of determining authentication strength (the number of authentication methods used) based on risk level. Another related technology determines a matching identity verification strategy based on user type, addressing the issue of deciding which authentication method to use based on user type. Both of these schemes assume a single, linear authentication process for each authentication request, resulting in drawbacks such as indiscriminate handling of channel conflicts, static verification entities, potential mismatches between multiple table states, and independent replay protection and orchestration mechanisms for QR code redirects.

[0006] Therefore, the state disorder caused by multi-channel concurrent conflicts is a problem that urgently needs to be solved in this field. Summary of the Invention

[0007] The purpose of this invention is to provide at least one control method, electronic device and storage medium for cloud customer real-name authentication, which can at least solve the technical problem of state disorder caused by multi-channel concurrent conflicts in existing methods.

[0008] To address the aforementioned technical problems, at least one embodiment of this application provides a control method for cloud customer real-name authentication, including: Extract the main account identifier and login account identifier from the request header of the obtained authentication request; If the main account identifier is the same as the currently logged-in account identifier, load and decrypt the customer master data according to the main account identifier to obtain the customer identifier, customer type and authentication status; Query the authentication log of the current customer's most recent authentication process and determine the authentication channel type to which the authentication log belongs: if the channel type is system authentication, execute the interruption sub-process; if the channel type is work order authentication, reject the current authentication request; the interruption sub-process includes: updating the status of the authentication log to interrupted and pausing the face callback recording associated with the authentication log; The authentication request is routed to the corresponding authentication policy based on customer type and document type, a QR code link carrying request identifier and timestamp is generated, the mapping relationship between request identifier and timestamp is written to the cache and an expiration time is set; Upon receiving a QR code callback request, verify that the request identifier exists, the timestamp is consistent, and the expiration time has been exceeded: if the verification fails, return an invalid page; if the verification passes, perform authentication orchestration under the protection of a distributed lock with the customer identifier as the granularity. It receives callbacks from third-party face recognition services, updates the authentication status in the customer table and authentication log table, and performs idempotent control on work order creation based on the persistent work order identifier, so that the status of the customer table, authentication log table and face callback table are consistent.

[0009] At least one embodiment of this application also provides an electronic device, including: at least one processor; and a memory communicatively connected to the at least one processor; wherein the memory stores instructions executable by the at least one processor, the instructions being executed by the at least one processor to enable the at least one processor to perform the cloud customer real-name authentication control method described above.

[0010] At least one embodiment of this application also provides a computer-readable storage medium storing a computer program that, when executed by a processor, implements the above-described control method for cloud customer real-name authentication.

[0011] The method provided in the embodiments of this application, within a single main account authentication entry point, performs differentiated mutual exclusion and interruption control orchestration of the system authentication channel and work order authentication channel on the same customer, thereby solving the problem of state disorder caused by multi-channel concurrent conflicts.

[0012] In some optional embodiments, the idempotent control of work order creation based on the persistent work order identifier includes: Before triggering work order creation, check if a valid work order identifier already exists and is bound to the current customer identifier or user identifier. If it exists, skip the current work order creation. If it does not exist, call the work order creation interface to create the work order. After the work order is successfully created, persist the returned work order identifier and bind it to the current customer identifier or user identifier. If work order creation is triggered again due to message re-delivery or callback concurrency in the message queue, determine it as a duplicate trigger based on the work order identifier and skip the re-triggered work order creation.

[0013] In some alternative embodiments, when a new round of authentication requests is initiated, the persistent work order identifier is cleared before the authentication request is enqueued.

[0014] In some optional embodiments, when the work order creation interface returns failure but a valid work order identifier has already been returned, the authentication request is processed as a successful work order creation, and the work order identifier is persisted.

[0015] In some optional embodiments, before routing the authentication request to the appropriate authentication policy, the method further includes: For non-first-time authentication requests, the original holder verification process is arranged as follows: If the current customer is an individual customer and the previous authentication was not based on an ID card, the mobile verification code channel is used instead, and the original face verification is skipped; otherwise, the original holder verification subject is dynamically selected based on the original customer type and the owner of the document, including the original holder verification subject being the individual customer's name and document number, and the original holder verification subject being the legal representative or the person in charge of the enterprise customer; and the current authentication request is rejected if the number of failed attempts of the original face verification reaches a threshold within a preset time period.

[0016] In some optional embodiments, the above-mentioned cloud customer real-name authentication control method further includes: for an already authenticated customer, if the time elapsed since the most recent successful authentication record is less than a preset time, rejecting the change request; when the already authenticated customer is an enterprise customer and the customer type of this authentication request is an individual customer, determining it as an illegal change path and rejecting it.

[0017] In some optional embodiments, authentication orchestration is performed under the protection of a distributed lock, and includes the following steps in a fixed order: first, judging and processing the original face authentication redirection branch; when the current callback is not the original face branch, reading the encrypted stored authentication parameters to restore it, interrupting the remaining system authentication process, and then calling the real-name sub-process according to the personal or enterprise path to obtain the third-party face URL and redirecting it.

[0018] In some optional embodiments, the request identifier written to the cache is generated as a UUID, the cache key contains a request identifier prefix, and the authentication orchestration under the protection of the distributed lock is only entered during the QR code scan callback if the request identifier, timestamp and validity period are consistent. Attached Figure Description

[0019] One or more embodiments are illustrated by way of example with reference to the accompanying drawings, and these illustrative descriptions do not constitute a limitation on the embodiments.

[0020] Figure 1 This is a flowchart of a cloud customer real-name authentication control method provided in an embodiment of this application; Figure 2 This is a schematic diagram of a cloud customer real-name authentication control system provided in an embodiment of this application; Figure 3 This is a schematic diagram illustrating the specific steps of cloud customer real-name authentication control provided in an embodiment of this application; Figure 4 This is one of the application scenarios provided by the embodiments of this application; Figure 5 This is application scenario two provided by the embodiments of this application; Figure 6 This is application scenario three provided by the embodiments of this application. Detailed Implementation

[0021] To make the objectives, technical solutions, and advantages of the embodiments of this application clearer, the various embodiments of this application will be described in detail below with reference to the accompanying drawings. However, those skilled in the art will understand that many technical details have been provided in the various embodiments of this application to help readers better understand this application. However, the technical solutions claimed in this application can be implemented even without these technical details and various changes and modifications based on the following embodiments. The division of the various embodiments below is for the convenience of description and should not constitute any limitation on the specific implementation of this application. The various embodiments can be combined with and referenced by each other without contradiction.

[0022] To facilitate understanding of the embodiments of this application, relevant content on related technologies will be introduced first.

[0023] One related technology uses adaptive authentication based on the target user's risk level information. Among various authentication methods such as real-name authentication, biometrics, temporary keys, and SMS verification, it selects an appropriate number of authentication methods according to risk level (Level 1 / 2 / 3), solving the problem of determining authentication strength (the number of authentication methods used) based on risk level. Another related technology determines the matching identity verification strategy based on user type, addressing the issue of deciding which authentication method to use based on user type. Both of these solutions assume that a single authentication request corresponds to a single, linear authentication process. Neither addresses mutual exclusion and interruption control when multiple concurrent authentication channels exist on the same entity, nor the dynamic orchestration of the original holder's verification entity when authentication changes, nor does it solve the problems of state consistency and asynchronous duplicate order creation across customer tables, authentication log tables, and face callback tables.

[0024] The existing technology has the following drawbacks: 1. Indiscriminate handling of channel conflicts: The existing solution does not distinguish between the two parallel processes of "system authentication in progress" and "work order authentication in progress". It cannot ensure that the former can be safely interrupted and the latter must be mutually exclusive and rejected. This can easily lead to the old process being incorrectly overwritten or the authentication status being disordered due to the parallel operation of the old and new processes.

[0025] 2. Static verification subject change: The existing solution selects the authentication method based on fixed user type or risk level, which cannot dynamically select the original holder for verification based on the original customer type and document owner (person / legal person / agent) in the event of an authentication change.

[0026] 3. Mismatch between multiple table states: The authentication status is scattered across multiple tables and multiple external callbacks, lacking a unified closed-loop control of the status; when the QR code callback and the vendor's asynchronous callback arrive concurrently, or when asynchronous messages are resubmitted, duplicate order creation, status rollback, or residual "authentication in progress" records are likely to occur.

[0027] 4. The anti-replay mechanism and the orchestration of QR code redirection are independent of each other: QR codes may be reused after being intercepted, and the existing solution does not bind the anti-replay parameters to the orchestration process of the specific authentication channel.

[0028] To address the technical problems of the existing methods, this invention proposes a control method, electronic device, and storage medium for cloud customer real-name authentication. The control method, electronic device, and storage medium for cloud customer real-name authentication of this invention are described in detail below. The following content is only for ease of understanding and is not necessary for implementing this solution.

[0029] Example 1: The cloud customer real-name authentication control method of this embodiment can be applied to electronic devices with communication, computing, and data storage capabilities. Its specific process can be as follows: Figure 1 As shown, it includes: Step 101: Extract the main account identifier and login account identifier from the request header of the obtained authentication request.

[0030] In the specific implementation, the main account identifier mainUserId and the current login account identifier loginUserId are extracted from the API gateway request header. If the two match, the subsequent steps are allowed to continue; otherwise, the real-name authentication request is rejected. Step 102: If the main account identifier is consistent with the currently logged-in account identifier, load and decrypt the customer master data according to the main account identifier to obtain the customer identifier, customer type and authentication status.

[0031] Step 103: Query the authentication log of the current customer's most recent authentication process and determine the authentication channel type to which the authentication log belongs: if the channel type is system authentication, execute the interrupt sub-process; if the channel type is work order authentication, reject the current authentication request.

[0032] Specifically, the interruption sub-process includes: deleting the "authenticating in progress" authentication log, updating the status of the original authentication log to interrupted, and pausing the face callback recording associated with the authentication log.

[0033] In some cases, before determining the authentication channel type, basic risk control verification is also included, which specifically includes: querying the user blacklist table, and comparing the customer's ID number, legal person's ID number, and authorized person's ID number with the ID blacklist table after being encrypted with the national cryptographic standard SM4. If any match is found, the authentication is rejected; and querying the number of times the customer has failed authentication in 24 hours. If the number reaches the threshold, the authentication is rejected.

[0034] In specific implementations, channel conflict arbitration can be determined inline by the orchestration service or abstracted into an independent channel state arbitration service, which drives interruptible / mutually exclusive rules through a state machine configuration table. This embodiment does not limit the specific implementation form.

[0035] Step 104: Route the authentication request to the corresponding authentication policy according to customer type and document type, generate a QR code link carrying request identifier and timestamp, write the mapping relationship between request identifier and timestamp into the cache and set the expiration time.

[0036] In the specific implementation, the request is routed to the corresponding authentication policy according to the customer type and document type, a QR code link carrying the request identifier reqId and timestamp ts is generated, and the mapping relationship between reqId and ts is written into the cache and an expiration time is set.

[0037] Routing is based on customer type and document type, including: for individual customers with 18-digit ID cards, routing is to the individual face authentication policy, and the authentication parameters are encrypted in JSON and written to the customer's authParam field; for individual customers with non-ID cards, routing is to the individual work order authentication policy; for enterprise customers, routing is to the enterprise work order authentication policy; when the policy returns an HTTP(S) link, the reqId and ts anti-replay parameters are appended before returning.

[0038] In practical applications, replay protection can utilize Redis to store reqId / ts, or it can be replaced with a signed and timed JWT (JSON Web Token). This embodiment does not limit this to a single method.

[0039] Step 105: Receive the QR code callback request, verify whether the request identifier exists, whether the timestamp is consistent, and whether the expiration time has been exceeded: if the verification fails, return the invalid page; if the verification passes, perform authentication orchestration under the protection of a distributed lock with the customer identifier as the granularity.

[0040] In the specific implementation, upon receiving a QR code scanning callback request, the system verifies whether the reqId exists, whether the ts matches, and whether the expiration time has expired. If at least one of the three conditions—reqId exists, ts matches, and the expiration time has not expired—is not met, the verification fails, and an invalidation page is returned. If all three conditions—reqId exists, ts matches, and the expiration time has not expired—are met, the verification passes, and authentication orchestration is performed under the protection of a distributed lock with the customer identifier as the granularity.

[0041] In practical applications, distributed locks can be implemented using Redis or alternatives such as Zookeeper; this embodiment does not limit them to this specific method.

[0042] Step 106: Receive the callback from the third-party face recognition service, update the authentication status in the customer table and authentication log table, and perform idempotent control on the creation of work orders based on the persistent work order identifier to ensure that the status of the customer table, authentication log table and face callback table are consistent.

[0043] The method in this embodiment, within a single main account authentication entry point, performs differentiated mutual exclusion and interruption control orchestration for the system authentication channel and work order authentication channel on the same customer, thus solving the problem of state disorder caused by multi-channel concurrent conflicts.

[0044] In some embodiments, idempotent control of work order creation based on a persistent work order identifier includes: Before triggering work order creation, check if a valid work order identifier already exists and is bound to the current customer identifier or user identifier. If it exists, skip the current work order creation. If it does not exist, call the work order creation interface to create the work order. After the work order is successfully created, persist the returned work order identifier and bind it to the current customer identifier or user identifier. If work order creation is triggered again due to message re-delivery in the message queue or callback concurrency, determine it as a duplicate trigger based on the work order identifier and skip the re-triggered work order creation.

[0045] In the specific implementation, before triggering the creation of a work order, it is checked whether a valid work order identifier already exists and is bound to the customer identifier or user identifier. Only if no valid work order identifier exists and is bound to the customer identifier or user identifier, the work order creation is called, and after successful creation, the returned work order identifier is persisted and bound to the customer identifier or user identifier. When the work order creation is triggered again due to message re-delivery in the message queue or concurrent callbacks, it can be determined as a duplicate trigger based on the work order identifier and skipped, thereby avoiding duplicate work order creation.

[0046] In practical applications, the idempotency identifier of a work order can be stored in a relational database or a document database (such as storing workorderId with userId / customerId as the key). The "re-authentication can create a work order, and message re-delivery will not create a duplicate work order" can be achieved by clearing the work order before it is enqueued and writing it back after success. This embodiment does not limit this to a single method.

[0047] In some embodiments, when a new round of authentication requests is initiated, the persistent work order identifier is cleared before the authentication request is enqueued.

[0048] In the specific implementation, when a new round of authentication is initiated, the persistent work order identifier is cleared before the authentication request is enqueued, so that the new round of authentication can create a work order normally, while the resubmission of messages in the same round of authentication is skipped because the work order identifier still exists.

[0049] In some embodiments, when the work order creation interface returns failure but a valid work order identifier has already been returned, the authentication request is processed as a successful work order creation, and the work order identifier is persisted.

[0050] In practice, when the work order creation interface returns a failure but a valid work order identifier has been returned, the request is treated as a success and the work order identifier is persisted, which can prevent subsequent resubmissions and duplicate work order creation.

[0051] In some embodiments, before routing the authentication request to the appropriate authentication policy, the method further includes: For non-first-time authentication requests, the original holder verification process is arranged as follows: If the current customer is an individual customer and the previous authentication was not based on an ID card, the mobile verification code channel is used instead, and the original face verification is skipped; otherwise, the original holder verification subject is dynamically selected based on the original customer type and the owner of the document, including the original holder verification subject being the individual customer's name and document number, and the original holder verification subject being the legal representative or the person in charge of the enterprise customer; and the current authentication request is rejected if the number of failed attempts of the original face verification reaches a threshold within a preset time period.

[0052] In practice, the preset duration can be 24 hours. Before routing, requests that are not initial authentications are orchestrated for original holder verification: when the customer is an individual and the previous authentication was not ID card authentication, the mobile verification code channel is used instead, and the original face verification is skipped; otherwise, the original holder verification subject is dynamically selected based on the original customer type and document holder—for individual customers, the name and document number are used, and for corporate customers, the name and document number are used according to the legal representative or authorized person role; and the current request is rejected if the number of failed attempts of the original face verification reaches a threshold within 24 hours.

[0053] In practical applications, the selection rules for the original holder's verification subject can be implemented through code branches or driven by the "document owner - verification subject" mapping configuration table, facilitating the expansion to more customer types. This embodiment does not impose a unique limitation on the specific implementation form of the selection rules for the original holder's verification subject.

[0054] In some embodiments, the above-described control method for cloud customer real-name authentication further includes: for an already authenticated customer, rejecting a change request when the time elapsed since the most recent successful authentication record is less than a preset time; and when the already authenticated customer is an enterprise customer and the customer type of this authentication request is an individual customer, determining it as an illegal change path and rejecting it.

[0055] The authentication change constraint provided in this embodiment dynamically determines the original holder's face verification subject based on the original customer type and document owner in the authentication change scenario, and constrains the change frequency, solving the problems of static change verification subject and easy bypassing of original holder verification.

[0056] In some embodiments, authentication orchestration is performed under the protection of a distributed lock, and includes the following steps in a fixed order: first, judging and processing the original face authentication redirection branch; when the current callback is not the original face branch, reading the encrypted stored authentication parameters to restore it, interrupting the remaining system authentication process, and then calling the real-name sub-process according to the personal or enterprise path to obtain the third-party face URL and redirecting it.

[0057] In the specific implementation, authentication orchestration is performed under the protection of a distributed lock, and in a fixed order, it includes: first, judging and processing the original face authentication jump branch; when the current callback is not the original face branch, reading the encrypted authentication parameter authParam to restore it, interrupting the remaining system authentication process, and then calling the real-name sub-process according to the personal or enterprise path to obtain the third-party face URL and redirecting.

[0058] In some embodiments, the request identifier written to the cache is generated as a UUID, the cache key contains a request identifier prefix, and the authentication orchestration under the protection of the distributed lock is only entered during the QR code scan callback if the request identifier, timestamp and validity period are consistent.

[0059] By implementing a closed-loop control system of "encrypting and storing authentication parameters in the database, preventing replay during QR code scanning, restoring callbacks, routing channels, and handling asynchronous work orders / vendor callbacks," the system ensures consistency among the customer table, authentication log table, and face callback table, and avoids duplicate order creation in asynchronous callback and message re-delivery scenarios.

[0060] Example 2: Based on the above embodiments, this embodiment provides an application example of a control method for cloud customer real-name authentication. It adds a channel conflict arbitration submodule, an original holder verification and orchestration submodule, and a state consistency control submodule to the unified real-name authentication entry point. The control system for cloud customer real-name authentication, such as... Figure 2 As shown, it includes: API Gateway Module: Pass login user data (including main account identifier mainUserId and current login account loginUserId) in the request header.

[0061] The authentication controller module provides three types of entry points: real-name authentication initiation, QR code callback, and third-party vendor callback.

[0062] Authentication orchestration service module: The core orchestration layer, which calls each verification submodule in a fixed pipeline in sequence, adopts a "short-circuit return" mode, and terminates when any node fails.

[0063] Policy registration and routing module: Maintains the mapping between authentication types and policy implementation classes, including personal face authentication policy, personal work order authentication policy and enterprise work order authentication policy.

[0064] Channel conflict arbitration submodule: Distinguish between "System authentication in progress" and "Work order authentication in progress". The former can be interrupted, while the latter is mutually exclusive and rejected.

[0065] Original holder verification and arrangement sub-module: Dynamically select the original face verification subject according to the original customer type and document owner.

[0066] The state consistency control submodule coordinates the state transitions of the customer table, authentication log table, and face callback table, and performs idempotent control on asynchronous work order creation.

[0067] The caching module (Redis) stores the mapping between the reqId of the QR code anti-replay function and the timestamp ts, as well as the binding relationship between the face recognition link and the user.

[0068] Distributed lock module: Locks are applied based on the customer identifier during QR code scanning callback processing to prevent state confusion caused by concurrent QR code scanning.

[0069] It also includes: authentication log module, face callback module, third-party face recognition service module, asynchronous work order (message queue) module, etc.

[0070] like Figure 3 As shown, the specific steps for the system to perform cloud customer real-name authentication control in this embodiment are as follows: Step 1: Main Account Identity Extraction and Constraints. The authentication orchestration service module parses the login data from the gateway request header, extracting mainUserId, loginUserId, and the login username; if login data is missing, a login failure is returned. The mainUserId and loginUserId are compared; if they match, the process is allowed to continue, and sub-accounts are rejected from initiating real-name authentication.

[0071] Step 2: Load Customer Master Data. Query and decrypt the customer master data based on mainUserId to obtain the customer ID (customerId), customer type, authentication status, document type, document number, legal representative and authorized person's document information, etc.; terminate if the customer does not exist.

[0072] Step 3: Basic Risk Control Verification (Dual Blacklist and Failure Frequency). Query the user blacklist table; iterate through the customer's ID number, legal representative's ID number, and authorized person's ID number, encrypting them using the national cryptographic standard SM4 and comparing them with the ID blacklist table. If any match is found, the application is rejected; query the authentication log table for the number of failed records for that customer within 24 hours. If the number reaches the threshold, the application is rejected. This step serves as the basic security verification.

[0073] Step 4: Multi-channel conflict arbitration. Query the customer's most recent "Authentication in Progress" log and differentiate the channels: (a) If "System Authentication in Progress," invoke the interrupted real-name authentication sub-process—delete the authentication in progress log, update the original log to "Interrupted," and suspend its associated face callback records, thus allowing new requests to continue safely; (b) If "Work Order Authentication in Progress," directly reject the request and indicate that a work order authentication is in progress, avoiding state conflicts caused by parallel work order authentication and system authentication. That is, a differentiated arbitration strategy of "interruptible vs. non-parallel" is adopted for the two types of channels.

[0074] Step 5: Authentication Change Constraints. For already certified customers, check the time of the most recent successful authentication. If it is less than 30 days ago, the change will be rejected to control the frequency of changes. If the current customer is an already certified enterprise customer and the current request is from an individual customer, it will be considered an illegal "enterprise to individual" change path and rejected.

[0075] Step Six: Original Holder Verification Arrangement. For non-first-time authentication scenarios, the original face verification subject is dynamically selected according to the following rules: First-time authentication skips verification; for individual customers whose history is not ID card authentication, the mobile verification code channel is used instead, and the original face verification is skipped; in other cases, the verification object is dynamically determined according to the original customer type and document holder—for individual customers, the name and document number are used; for corporate customers, the name and document number are used according to the "legal person" or "person in charge" role. The number of failed attempts for the original face verification in 24 hours is queried, and if the threshold is reached, the verification is rejected. When verification is required, a reqId and a timestamp ts are generated and written to Redis (expiring in 30 minutes), and the original face scan callback URL with customerId, customerType, reqId, and ts parameters is returned; otherwise, proceed to the next step.

[0076] Step 7: Parameter Integrity and Document Quota Verification. Verify the integrity of authentication parameters according to customer type (verify required fields and attachments separately for individual / enterprise / authorized personnel scenarios), and perform quota verification on the newly submitted document numbers to prevent the same document from being bound to multiple cloud accounts in excess.

[0077] Step 8: Channel routing and encrypted authentication parameter storage. Routing is done via the policy registry: Individual customers with 18-digit ID cards → Individual face authentication policy, encrypting the authentication parameters (JSON) and writing them into the customer's `authParam` field, then returning the scan address; Individual customers without ID cards → Individual work order authentication policy; Enterprise customers → Enterprise work order authentication policy. If the policy returns an HTTP(S) link, the `reqId` and `ts` anti-replay parameters are appended before returning to the front end.

[0078] Step Nine: QR Code Callback, Replay Prevention, and Orchestration Recovery. When a user scans the QR code to access the callback interface, the controller reads the ts corresponding to the reqId from Redis, verifies that the reqId exists, the ts is consistent, and the time has not exceeded 30 minutes. If it fails, it returns a QR code expiration page. After successful verification, under the protection of a client-level distributed lock, it executes in a fixed order: first, it processes the original face authentication redirection branch; if it is not the original face branch, it reads authParam to restore authentication parameters, interrupts the remaining "System Authentication in Progress" process, and then calls the realName sub-process according to the personal / enterprise path to obtain the third-party face URL (Uniform Resource Locator) and redirects.

[0079] Step 10: Vendor Callback and Multi-Table State Closure. After the third-party face service callback `notifyResult`, the state consistency control submodule updates the authentication status of the customer table and authentication log table under a unified state machine; for asynchronous work order creation triggered after successful authentication and IAM (Identity and Access Management) synchronization, idempotent control is performed based on the already persisted work order identifier: if the customer / user already has a valid work order identifier, duplicate creation is skipped; after successful work order creation, the work order identifier is immediately written back. Thus, in the case of concurrent arrival of QR code scanning callback and vendor callback, or asynchronous message re-delivery, the state of the customer table, authentication log table, and face callback table is kept consistent and duplicate work orders are not generated.

[0080] The core judgment logic of the orchestration service is as follows: the verification chain adopts a "short-circuit return"; the channel conflict adopts a branching strategy of "interruptible in system authentication, but not parallel in work order authentication"; the original face verification adopts dynamic orchestration of "skip on the first time / skip with verification code for individuals without ID cards / otherwise select the certificate according to role and limit the frequency"; the policy routing adopts the mapping of "individual + ID card → face, individual + non-ID card → individual work order, enterprise → enterprise work order"; the QR code anti-replay adopts "UUID as reqId, millisecond timestamp as ts, Redis key with reqId prefix, 30 minutes expired, and callback consistent before allowing"; the multi-table status closure adopts "work order identifier persistence idempotency" to avoid asynchronous duplicate order creation.

[0081] As a specific implementation of the aforementioned state consistency control submodule in the authentication work order creation process, the work order creation idempotency control is as follows: (I) System Composition and Storage: After updating the authentication status of a client or user, the authentication orchestration service submits a work order creation message to the authentication work order message queue (e.g., ops-customer-cert-workorder-queue). The work order consumer then asynchronously creates the work order. If message consumption fails, it is written to a failure log table (e.g., rabbitmq_error_log, with the status set to unsuccessful). A scheduled task (approximately every 5 minutes) scans and resubmits the message to ensure eventual consistency—in the absence of idempotency control, this resubmission can lead to duplicate work orders for the same authentication. The persistence of the work order identifier (workorderId): On the client side, the workorderId is merged and written to the real-name snapshot authParam (document repository Mongo) using customerId as the key. On the user side, userId is used as the key to store the binding between userId and workorderId in the document repository collection (e.g., ucs_user_cert_workorder). No authentication result field is stored; it is only used for idempotency determination.

[0082] (ii) Idempotency determination before order creation: After receiving the order creation message, the consumer first determines whether the order creation interface is valid. The client reads authParam and if it contains a valid workorderId, it records "the certified work order already exists (snapshot workorderId)" and returns success directly. The user queries the workorderId corresponding to userId. If it exists, it skips the query and returns success. The work order creation interface is only called if the workorderId does not exist.

[0083] (iii) Write-back after order creation: After the work order creation interface returns the workorderId, it is immediately written back to the persistence (merged into authParam on the client side and written into userId-workorderId binding on the user side), and the authentication log is updated to "work order under review"; thereafter, any resubmission message will be skipped if the workorderId is hit in the judgment stage before order creation.

[0084] (iv) Message resubmission: If the order is successfully created for the first time but the message confirmation fails, or the failure log is resubmitted by the scheduled task, the order will be skipped because the workorderId has been written back and the order was determined to be hit before creation, thus avoiding repeated order creation within the approximately 5-minute resubmission cycle.

[0085] (v) New round of authentication: When the same customer or user initiates a new round of authentication (including authentication changes), the orchestration service clears the persistent workorderId before delivering the order creation message (removed from authParam on the customer side and deleted from the binding record on the user side); thus, the new round of authentication can be completed normally, while the message re-delivery for the same round of authentication is skipped because the new workorderId has been written back, realizing "re-authentication can be completed, and re-delivery in the same round will not result in duplicate order creation".

[0086] (vi) Interface exception tolerance: When the work order creation interface returns a failure status code but the response already carries a valid workorderId (indicating that the work order has actually been created successfully), the result will be processed as a success, the workorderId will be persisted and the authentication log will be updated to avoid being judged as a failure due to the interface returning an exception, which would trigger a resubmission and cause duplicate work order creation.

[0087] (vii) Sequence Example: T0 User completes face authentication → Orchestration service updates authentication status and clears old workorderId before submitting order creation message; T1 Consumer determines no workorderId before creating order → creates work order → returns workorderId=W → writes back authParam / binding → authentication log is set to "work order under review"; T2 Message confirmation timeout, failure log is resubmitted after about 5 minutes; T3 Consumer receives resubmission message → determines workorderId=W before creating order → skips (does not create order again); T4 The customer initiates authentication change again → clears workorderId=W before submission → determines no workorderId → creates new work order W′ → writes back.

[0088] In a specific application scenario, the above solution is applied to, for example... Figures 4 to 6 The console entry for real-name authentication shown covers individuals / enterprises (such as...) Figure 4 As shown), system authentication / work order authentication (such as...) Figure 5 As shown), complex combined scenarios such as initial authentication / change authentication (e.g.) Figure 6 (As shown).

[0089] Applicable user roles: (1) Cloud platform main account user (sub-accounts are prohibited from initiating); (2) Enterprise authorized person, legal person / handler, complete the original holder's face verification according to the certificate owner rules; (3) Operation review personnel, receive the pending records transferred from the work order authentication channel.

[0090] Typical business scenarios: (1) When an individual registers their ID card for the first time, the orchestration service completes basic risk control and routes the data to the face scanning channel, returning a QR code with reqId / ts anti-replay parameters; (2) When a certified enterprise customer changes their document information, the original holder is first verified by face verification according to the legal person / handler role, and the 30-day change window is verified; (3) When a new request arrives while the system is in the "system authentication in progress" process, the old process is automatically interrupted and its face callback is suspended; when the work order is in the "work order authentication in progress" process, mutual exclusion is rejected; (4) After the vendor's face callback arrives, the customer table and authentication log are updated uniformly, and subsequent work orders / IAM synchronization is triggered based on the work order identifier idempotently to avoid message re-delivery leading to duplicate order creation.

[0091] Deployment environment: API gateway for transmitting login status + customer center microservice cluster + Redis distributed lock / anti-replay cache + MySQL + message queue + third-party face recognition real-name service, suitable for centralized real-name compliance management of users across multiple products and channels on cloud platforms.

[0092] This embodiment employs differentiated arbitration orchestration for concurrent "system authentication channels" and "work order authentication channels" on the same customer. It interrupts the "system authentication in progress" process (deleting authentication logs, setting interruption, and pausing associated face callbacks) and mutually excludes the "work order authentication in progress" process. Dynamic orchestration of the original holder's verification subject in authentication change scenarios: Based on the original customer type and document holder (individual / corporate legal person / handler), the original face verification object is dynamically selected, combined with the judgment logic of "skipping the first time, skipping the verification code for individuals without ID cards, and limiting the frequency of the original face verification for 24 hours." A closed-loop orchestration of "encrypted authentication parameters in the database—anti-replay scanning—callback recovery—channel routing": Under a distributed lock, the scan callback is executed in a fixed order: "prioritizing the original face branch, then restoring authParam and interrupting the remaining system authentication process, and finally calling realName for redirection," and the reqId / ts anti-replay mechanism is bound to this orchestration process. Multi-table state consistency and work order idempotency: In scenarios involving concurrent vendor callbacks and asynchronous messages, idempotent control is applied to work order creation / IAM synchronization based on persistent work order identifiers to ensure that the customer table, authentication log table, and face callback table are consistent in state and that duplicate work orders are not generated.

[0093] Example 3: Another embodiment of this application relates to a control device for cloud customer real-name authentication. The implementation details of the control device for cloud customer real-name authentication in this embodiment are described in detail below. The following implementation details are provided for ease of understanding only and are not necessary for implementing this solution.

[0094] The extraction module is used to extract the main account identifier and login account identifier from the request header of the obtained authentication request.

[0095] The acquisition module is used to load and decrypt customer master data based on the main account identifier when the main account identifier is consistent with the currently logged-in account identifier, and obtain customer identifier, customer type and authentication status.

[0096] The discrimination module is used to query the authentication log of the current customer's most recent authentication process and determine the authentication channel type to which the authentication log belongs: when the channel type is system authentication, the interrupt sub-process is executed; when the channel type is work order authentication, the authentication request is rejected.

[0097] The generation module is used to route the authentication request to the corresponding authentication policy according to the customer type and document type, generate a QR code link carrying the request identifier and timestamp, write the mapping relationship between the request identifier and the timestamp into the cache and set the expiration time.

[0098] The orchestration module receives QR code callback requests and verifies whether the request identifier exists, whether the timestamp is consistent, and whether the expiration time has been exceeded. If the verification fails, an invalid page is returned; if the verification passes, authentication orchestration is performed under the protection of a distributed lock with the customer identifier as the granularity.

[0099] The update module is used to receive callbacks from third-party face recognition services, update the authentication status in the customer table and authentication log table, and perform idempotent control on work order creation based on the persistent work order identifier, so that the status of the customer table, authentication log table and face callback table are consistent.

[0100] The device in this embodiment arranges differentiated mutual exclusion and interruption control for the system authentication channel and work order authentication channel on the same customer within a single main account authentication entry point, thus solving the problem of state disorder caused by multi-channel concurrent conflicts.

[0101] The specific implementation methods of the above modules are described in the aforementioned embodiments, and will not be repeated here.

[0102] It is worth mentioning that all modules involved in this embodiment are logical modules. In practical applications, a logical unit can be a physical unit, a part of a physical unit, or a combination of multiple physical units. Furthermore, to highlight the innovative aspects of this application, this embodiment does not introduce units that are not closely related to solving the technical problems proposed in this application; however, this does not mean that other units are absent in this embodiment.

[0103] In some optional embodiments, the control device for cloud customer real-name authentication can implement the control method for cloud customer real-name authentication in any of the above embodiments.

[0104] Example 4: Another embodiment of this application relates to an electronic device, including: at least one processor; and a memory communicatively connected to the at least one processor; wherein the memory stores instructions executable by the at least one processor, the instructions being executed by the at least one processor to enable the at least one processor to perform the cloud customer real-name authentication control method in the above embodiments.

[0105] In this embodiment, the memory and processor are connected via a bus, which can include any number of interconnected buses and bridges, connecting various circuits of one or more processors and the memory together. The bus can also connect various other circuits, such as peripheral devices, voltage regulators, and power management circuits, which are well known in the art and therefore will not be further described in this embodiment. A bus interface provides an interface between the bus and the transceiver. The transceiver can be a single element or multiple elements, such as multiple receivers and transmitters, providing a unit for communicating with various other devices over a transmission medium. Data processed by the processor is transmitted over the wireless medium via an antenna, which further receives data and transmits it to the processor.

[0106] The processor manages the bus and general processing, and also provides various functions, including timing, peripheral interfaces, voltage regulation, power management, and other control functions. Memory is used to store data used by the processor during operation.

[0107] Example 5: Another embodiment of this application relates to a computer-readable storage medium storing a computer program. When executed by a processor, the computer program implements the aforementioned control method embodiment for cloud customer real-name authentication.

[0108] That is, those skilled in the art will understand that all or part of the steps in the methods of the above embodiments can be implemented by a program instructing related hardware. This program is stored in a storage medium and includes several instructions to cause a device (which may be a microcontroller, chip, etc.) or processor to execute all or part of the steps of the methods described in the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0109] Those skilled in the art will understand that the above embodiments are specific embodiments for implementing this application, and in practical applications, various changes can be made to them in form and detail without departing from the spirit and scope of this application.

Claims

1. A control method for real-name authentication of cloud customers, characterized in that, include: Extract the main account identifier and login account identifier from the request header of the obtained authentication request; If the main account identifier is the same as the currently logged-in account identifier, load and decrypt the customer master data according to the main account identifier to obtain the customer identifier, customer type and authentication status; Query the authentication log of the current customer's most recent authentication process and determine the authentication channel type to which the authentication log belongs: if the channel type is system authentication, execute the interrupt sub-process; When the channel type is work order authentication, the authentication request is rejected; the interruption sub-process includes: updating the status of the authentication log to interruption and pausing the face callback recording associated with the authentication log. The authentication request is routed to the corresponding authentication policy based on customer type and document type, a QR code link carrying a request identifier and timestamp is generated, the mapping relationship between the request identifier and timestamp is written to the cache and an expiration time is set; Upon receiving a QR code callback request, verify that the request identifier exists, the timestamp is consistent, and the expiration time has been exceeded: if the verification fails, return an invalid page; if the verification passes, perform authentication orchestration under the protection of a distributed lock with the customer identifier as the granularity. It receives callbacks from third-party face recognition services, updates the authentication status in the customer table and authentication log table, and performs idempotent control on work order creation based on the persistent work order identifier, so that the status of the customer table, authentication log table and face callback table are consistent.

2. The cloud customer real-name authentication control method according to claim 1, characterized in that, The idempotent control of work order creation based on the persistent work order identifier includes: Before triggering work order creation, check if a valid work order identifier already exists and is bound to the current customer identifier or user identifier. If it exists, skip the current work order creation. If it does not exist, call the work order creation interface to create the work order. After the work order is successfully created, persist the returned work order identifier and bind it to the current customer identifier or user identifier. If work order creation is triggered again due to message re-delivery or callback concurrency in the message queue, determine it as a duplicate trigger based on the work order identifier and skip the re-triggered work order creation.

3. The cloud customer real-name authentication control method according to claim 2, characterized in that, When a new round of authentication requests is initiated, the persistent work order identifier is cleared before the authentication request is enqueued.

4. The cloud customer real-name authentication control method according to claim 2, characterized in that, When the work order creation interface returns a failure but a valid work order identifier has already been returned, the authentication request will be processed as a successful work order creation, and the work order identifier will be persisted.

5. The cloud customer real-name authentication control method according to claim 1, characterized in that, Before routing this authentication request to the appropriate authentication policy, the following steps are also included: For non-first-time authentication requests, the original holder verification process is arranged as follows: If the current customer is an individual customer and the previous authentication was not based on an ID card, the mobile verification code channel is used instead, and the original face verification is skipped; otherwise, the original holder verification subject is dynamically selected based on the original customer type and the owner of the document, including the original holder verification subject being the individual customer's name and document number, and the original holder verification subject being the legal representative or the person in charge of the enterprise customer; and the current authentication request is rejected if the number of failed attempts of the original face verification reaches a threshold within a preset time period.

6. The cloud customer real-name authentication control method according to claim 1, characterized in that, Also includes: For already certified customers, change requests will be rejected if the time elapsed since the most recent successful certification is less than the preset time. If the already authenticated customer is an enterprise customer and the customer type of this authentication request is an individual customer, it is determined to be an illegal path change and rejected.

7. The cloud customer real-name authentication control method according to claim 1, characterized in that, The authentication orchestration is performed under the protection of a distributed lock, and follows a fixed order: first, the original face authentication redirection branch is judged and processed; when the current callback is not the original face branch, the encrypted authentication parameters are read and restored, the remaining system authentication process is interrupted, and then the real-name sub-process is called according to the personal or enterprise path to obtain the third-party face URL and redirect.

8. The cloud customer real-name authentication control method according to claim 1, characterized in that, The request identifier written to the cache is generated using a UUID, and the cache key contains a prefix of the request identifier. During the QR code scan callback, authentication orchestration under the protection of a distributed lock is only entered if the request identifier, timestamp, and validity period are consistent.

9. An electronic device, characterized in that, include: At least one processor; as well as, A memory communicatively connected to the at least one processor; wherein, The memory stores instructions that can be executed by the at least one processor, which, when executed by the at least one processor, enables the at least one processor to perform the cloud customer real-name authentication control method as described in any one of claims 1 to 8.

10. A computer-readable storage medium storing a computer program, characterized in that, When the computer program is executed by the processor, it implements the control method for cloud customer real-name authentication as described in any one of claims 1 to 8.

Images