Information authentication method and device, storage medium and program product

Abstract

The embodiment of the invention provides an information authentication method and device, a storage medium and a program product. In the scheme, a low-efficiency mode that each operator needs to register independently and authenticate repeatedly in a traditional cross-domain scene is abandoned, an authentication link carrying a security identifier is generated on the basis of a target merchant completing encryption authentication innovatively, and the authentication link is used as a legal authentication credential; the remote operating personnel can submit the real-name information locally encrypted by the front end only by accessing the authentication link without an account number and login. And directly affirming the operation legality and security based on the security identifier embedded in the link, and completing subsequent operator reporting. Therefore, normal form transformation from'respective authentication of multiple subjects' to'single subject authorization and multi-terminal credible collaboration 'is realized, and on the premise of ensuring safety compliance, the authentication efficiency and user experience of cross-regional multi-number management are remarkably improved.

Description

Technical Field

[0001] This application relates to the field of data security technology, and in particular to an information authentication method, device, storage medium and program product. Background Technology

[0002] With the rapid development of information technology, privacy protection has become an indispensable part of internet services. Especially in e-commerce and lifestyle services, users' demand for communication security is growing. Privacy number services, as an effective means of privacy protection, ensure user communication security by hiding the user's real number, and have become one of the core tools in these industries. According to the relevant management requirements for the security management of intermediate numbers, privacy numbers must complete the real-name registration and filing of the actual user's information before use, and ensure the security of sensitive data throughout the entire filing process.

[0003] In the local services sector, online service platforms bring together numerous merchants, who often face the need for cross-city operations. For example, in industries such as housekeeping or moving services, a single merchant account may need to cover business activities in multiple cities, with each city's specific business typically handled by different order takers. Since different phone numbers are used for different business operations in different regions, this results in a complex management model involving multiple cities, multiple personnel, and multiple phone numbers under a single merchant account. Traditionally, to accommodate this model, each order taker in different regions needs to register their own platform account and undergo a multi-step privacy verification process through their independent account.

[0004] However, in the traditional approach, each person taking orders needs to register and manage their own account separately. Each authentication process requires searching for the authentication entry point on multiple pages and navigating between them to complete the necessary steps. This method is not only time-consuming but also significantly reduces overall work efficiency. Summary of the Invention

[0005] The embodiments of this application provide an information authentication method, device, storage medium, and program product to solve the technical problems of time consumption and low authentication efficiency in traditional authentication schemes. They realize a paradigm shift from "multiple entities authenticating individually" to "single entity authorization and trusted collaboration of multiple terminals". Under the premise of ensuring security and compliance, they significantly improve the authentication efficiency and user experience of cross-regional multi-number management.

[0006] This application provides an information authentication method, including: in response to receiving a login operation from a target merchant based on a target account, performing encrypted authentication on the target account; wherein the target account is bound to the phone numbers of multiple operators; after the target account passes encrypted authentication, in response to an authentication sharing operation from the target merchant, generating and sharing an authentication link for at least one target phone number; wherein the authentication link carries a security identifier and encryption context information assigned to the corresponding target phone number based on the target account; receiving encrypted authentication data submitted by a terminal accessing the authentication link; wherein the encrypted authentication data is generated by the terminal obtaining real-name authentication information entered by the operator on the displayed authentication page, and using the encryption context information parsed from the authentication link to perform front-end local encryption on the real-name authentication information, and the encrypted authentication data includes a security identifier; decrypting the encrypted authentication data to obtain real-name authentication information and a security identifier; determining an encryption channel corresponding to the target account based on the security identifier, and encrypting the real-name authentication information into operator ciphertext using the key of the encryption channel; and sending the operator ciphertext to the operator server.

[0007] This application also provides an electronic device, including: a memory and a processor; the memory is used to store a computer program; the processor is coupled to the memory and is used to execute the computer program to implement the steps in the above method.

[0008] This application also provides a computer-readable storage medium storing a computer program, which, when executed by a processor of an electronic device, causes the processor to perform the steps in the above-described method.

[0009] This application also provides a computer program product, including: a computer program that, when executed by a processor of an electronic device, causes the processor to perform the steps in the above-described method.

[0010] In this embodiment, after the target merchant completes identity authentication, it actively triggers the generation of an authentication link carrying a security identifier. This link serves as the legitimate entry point for real-name authentication of cross-regional workers, fundamentally eliminating the redundant mechanism in traditional solutions where each remote worker must independently register an account and repeatedly execute multiple login and authentication processes. This solution uses "authentication equals authorization" as its core logic, embedding the merchant's completed identity trust status into the authentication link through a security identifier for trust transfer. This allows remote workers to directly submit real-name information without a platform account or secondary login simply by accessing the authentication link, achieving a paradigm shift from "multi-subject independent authentication" to "single-subject authorization, multi-terminal collaborative authentication." This mechanism not only significantly simplifies the operation path in cross-city business scenarios (no need to search for an entry point, no need for page redirection, no need for account management), greatly improving authentication efficiency, but also ensures the legitimacy of authentication requests and the security of data transmission through the binding of security identifiers and encrypted context information. Attached Figure Description

[0011] The accompanying drawings, which are included to provide a further understanding of this application and form part of this application, illustrate exemplary embodiments and are used to explain this application, but do not constitute an undue limitation of this application. In the drawings: Figure 1 A flowchart illustrating an information authentication method provided for an exemplary embodiment of this application; Figure 2 A flowchart illustrating another information authentication method provided for another exemplary embodiment of this application; Figure 3 A schematic diagram of the structure of an electronic device provided for an exemplary embodiment of this application. Detailed Implementation

[0012] Following the background technology, to address the technical issues of time-consuming and inefficient traditional authentication schemes, this application proposes a new approach. After the target merchant completes identity authentication, they proactively trigger the generation of an authentication link carrying a security identifier. This link serves as the legitimate entry point for real-name authentication of cross-regional workers, fundamentally eliminating the redundant mechanism of traditional schemes where each remote worker must independently register an account and repeatedly execute multiple login and authentication steps. This solution uses "authentication equals authorization" as its core logic, embedding the merchant's completed identity trust status into the authentication link through a security identifier for trust transfer. This allows remote workers to directly submit real-name information without a platform account or secondary login simply by accessing the authentication link, achieving a paradigm shift from "multi-subject independent authentication" to "single-subject authorization, multi-terminal collaborative authentication." This mechanism not only significantly simplifies the operation path in cross-city business scenarios (no need to search for an entry point, no need for page redirection, no need for account management), greatly improving authentication efficiency, but also ensures the legitimacy of authentication requests and the security of data transmission through the binding of security identifiers and encrypted context information.

[0013] To make the objectives, technical solutions, and advantages of this application clearer, the above-mentioned technical solutions of this application will be clearly and completely described below with reference to specific embodiments and corresponding drawings. Obviously, the described embodiments are only a part of the embodiments of this application, and not all of them. Based on the embodiments in this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0014] It should be noted that the user information (including but not limited to user device information, user personal information, etc.) and data (including but not limited to data used for analysis, data stored, data displayed, etc.) involved in this application are all information and data authorized by the user or fully authorized by all parties. Furthermore, the collection, use and processing of the relevant data must comply with the relevant laws, regulations and standards of the relevant countries and regions, and corresponding operation entry points are provided for users to choose to authorize or refuse.

[0015] Additionally, it should be noted that when user interaction operations or triggering operations are involved in the embodiments of this application, these operations include, but are not limited to, various interaction methods such as touch operations, gesture operations, voice operations, head movement operations, and eye movement operations. Touch operations include, but are not limited to, click operations, double-click operations, long-press operations, swipe operations, pinch operations, or mouse hover operations. Swipe operations include, but are not limited to, straight-line swipes and curved-line swipes.

[0016] Furthermore, it should be noted that, in the cases where the embodiments of this application involve jumping between the first interface and the second interface, the jumping methods involved in the embodiments of this application include, but are not limited to: jumping directly from the first interface to the second interface, or jumping from the first interface to the task interface and completing the corresponding task operation on the task interface before jumping to the second interface; completing the corresponding task operation on the task interface includes, but is not limited to: completing the game operation on the game interface when the task interface is implemented as a game interface; completing identity authentication on the identity authentication interface when the task interface is implemented as an identity authentication interface; completing the recharge operation on the recharge interface when the task interface is implemented as a recharge interface; and so on.

[0017] This application provides an information authentication system. This system can be an e-commerce service system. The system architecture may include a target merchant's terminal, a server, and at least one operator's terminal. (Alternatively, it may include a server and multiple user terminals; or it may include a server, a first user terminal, and a second user terminal, etc.) In this system, the target merchant's terminal, the server, and at least one operator's terminal can establish a connection via a network. The network provides the medium for communication links between these three entities. The network can include various connection types, such as wired, wireless, or fiber optic cables. The target merchant's terminal and the terminal of at least one operator can interact with the server via the network to receive or send messages, etc.

[0018] The target application can be installed on the terminal of the target merchant and at least one operator's terminal. The target application can be a browser, an app (application), a web application such as an H5 (HyperText Markup Language 5) application, a lightweight application (also known as a mini-program), or a cloud application. Examples of target applications include human-computer interaction applications, model training applications, text processing applications, web browser applications, shopping applications, search applications, instant messaging tools, email clients, and social media platform software.

[0019] The terminal can be, for example, an electronic device with a display screen that supports information browsing, such as a personal mobile terminal like a mobile phone, tablet computer, personal computer, desktop computer, smart speaker, smartwatch, etc. Electronic devices can refer to devices used by users that have the computing, internet access, and communication functions required by the user. Electronic devices may also include basic configurations such as network card chips, I / O (input / output) buses, and audio / video components; this application does not limit this. Optionally, depending on the implementation of the electronic device, it may also include some peripheral devices, such as a keyboard, mouse, pen, printer, etc.; this application does not limit this.

[0020] The server side can include servers that provide various services, such as servers that support the models used on the terminals of target merchants or the terminals of at least one operator for background training, or servers that process interactive information sent by user terminals.

[0021] It should be noted that the server can be implemented as a distributed server cluster consisting of multiple servers, or as a single server. The server can also be a server in a distributed system, or a server combined with blockchain. The server can also be a cloud server that provides basic cloud computing services such as cloud services, cloud databases, cloud computing, cloud functions, cloud storage, network services, cloud communication, middleware services, domain name services, security services, content delivery networks (CDN), and big data and artificial intelligence platforms, or an intelligent cloud computing server or intelligent cloud host with artificial intelligence technology.

[0022] The solutions provided in the embodiments of this application will be described in detail below with reference to the accompanying drawings.

[0023] Figure 1 An information authentication method is provided for an exemplary embodiment of this application. For example... Figure 1 As shown, the method includes: 101. In response to receiving login operations from the target merchant based on the target account, perform encrypted authentication on the target account; wherein, the target account is bound to the phone numbers of multiple operators; 102. After the target account passes encrypted authentication, respond to the target merchant's authentication sharing operation, generate and share an authentication link for at least one target phone number; wherein, the authentication link carries a security identifier and encrypted context information assigned to the corresponding target phone number based on the target account; 103. Receive encrypted authentication data submitted by the terminal accessing the authentication link; wherein, the encrypted authentication data is generated by the terminal obtaining the real-name authentication information entered by the operator in the displayed authentication page, and using the encryption context information parsed from the authentication link to perform front-end local encryption on the real-name authentication information, and the encrypted authentication data includes a security identifier. 104. Decrypt the encrypted authentication data to obtain real-name authentication information and security identifier; 105. Based on the security identifier, determine the encryption channel corresponding to the target account, and use the encryption channel key to encrypt the real-name authentication information into carrier ciphertext; 106. Send the operator's encrypted message to the operator's server.

[0024] This embodiment provides an information authentication method applicable to platform-based service systems where certified merchants initiate real-name authentication for their remote workers. The core of this method lies in generating an authentication link with embedded security credentials using the target merchant's completed identity authentication status. This allows workers to submit compliant real-name information without registration or login. The entire process ensures security and efficiency through multi-layered encryption and trust transfer mechanisms.

[0025] First, upon receiving a login request from a target merchant based on a target account, the server performs encrypted authentication on the target account. Specifically, the target merchant initiates a login request on their terminal device by entering their account and password through a target application (such as a merchant management app or web console). Upon receiving this request, the server executes an authentication process: verifying whether the submitted credentials match the merchant's identity information stored in the platform's database. If the verification passes, the target account is considered to have passed encrypted authentication, and a trusted session state is established. During this process, the server typically generates a temporary session identifier (such as sessionId), binds it to the target merchant's user identifier (merchantId), stores it in the cache system, and simultaneously returns it to the merchant's terminal via a secure cookie to maintain the authentication status for subsequent operations.

[0026] It is important to note that the target account was pre-bound with the phone numbers of multiple service providers during the platform's business configuration phase. These phone numbers represent individuals actually performing offline services (such as domestic workers, delivery personnel, and repairmen), who may be located in different cities across the country, forming a typical business model of "one merchant account managing multiple remote service providers." Each phone number is unique within the system and has a clear attribution relationship with the target account.

[0027] After the target account passes encrypted authentication, the server responds to the target merchant's authentication sharing operation, generating and sharing an authentication link for at least one target phone number. Here, "authentication sharing operation" refers to the instruction triggered by the target merchant selecting one or more target phone numbers from its bound number list in the authentication management interface and clicking the "Generate Authentication Link" button. Upon receiving this operation, the server generates a unique authentication link for each selected target phone number.

[0028] The key is that the authentication link carries two core elements: one is a security identifier assigned to the corresponding target phone number based on the target account, and the other is encrypted context information.

[0029] The security identifier is a unique trust credential generated by the server specifically for the target phone number, provided the target account has passed encrypted authentication. Its generation logic strictly relies on the target account's security attributes (including merchantId, current session state, timestamp, etc.) and the target phone number itself. For example, the server can use the HMAC-SHA256 algorithm, with a platform-preset shared key as the key, to hash "merchantId + target phone number + current timestamp," outputting a 32-byte irreversible string as the security identifier. The purpose of this security identifier is to indicate that the authentication link was authorized by a legitimate merchant for the target number, allowing the server to directly recognize authentication requests from this link without requiring operators to provide identity verification again.

[0030] The encryption context information is a set of technical parameters required for operators to locally encrypt real-name authentication information on the front end. This information typically includes: a one-time encryption key identifier (kid), the encryption algorithm type (such as AES-128-GCM), the initialization vector (IV), and the key validity period. When generating the authentication link, the server embeds this encryption context information in the link (or passes it by reference) for the terminal to call before submitting data.

[0031] Subsequently, the operator accesses the authentication link on their terminal device, and the browser automatically loads the authentication page. The front-end script on the page parses the security identifier and encryption context information from the URL. The operator enters their real-name authentication information, such as name and ID number, on the page and clicks the submit button. At this point, the terminal uses the encryption context information to call the built-in front-end encryption module (such as a JavaScript encryption library based on white-box AES) to perform front-end local encryption on the real-name authentication information—that is, the entire encryption operation is completed in the user's device memory, and the original plaintext data is never transmitted to the server. After encryption, the terminal encapsulates the generated ciphertext and the aforementioned security identifier together into encrypted authentication data and submits it to the server via the HTTPS protocol.

[0032] After receiving the encrypted authentication data, the server first decrypts it using the key mechanism agreed upon with the front end, thereby restoring the original real-name authentication information and security identifier. Next, based on this security identifier, the server locates the corresponding target account in the internal mapping relationship and further determines the encrypted channel associated with that target account. The encrypted channel refers to the pre-defined secure communication path between the server and the operator's server, the core of which is a periodically rotated channel key (e.g., a monthly updated scfkey). The server uses this channel key to encrypt the real-name authentication information again, generating operator-encrypted text that conforms to the operator's interface specifications.

[0033] Finally, the server sends the ciphertext of the operator to the operator's server through a two-way TLS 1.3 secure channel, so that the operator can complete the real-name registration of the target phone number and assign it a privacy-protected number (such as an intermediate number or a virtual number).

[0034] The technical solution provided in the above embodiments of this application, after the target merchant completes identity authentication, actively triggers the generation of an authentication link carrying a security identifier, and uses this link as the legitimate entry point for real-name authentication of cross-domain workers. This fundamentally eliminates the redundant mechanism in traditional solutions where each remote worker must independently register an account and repeatedly execute multiple login and authentication processes. This solution uses "authentication equals authorization" as its core logic, embedding the merchant's completed identity trust status into the authentication link through a security identifier for trust transfer. This allows remote workers to directly submit real-name information without a platform account or secondary login simply by accessing the authentication link, achieving a paradigm shift from "multi-subject independent authentication" to "single-subject authorization, multi-terminal collaborative authentication." This mechanism not only significantly simplifies the operation path in cross-city business scenarios (no need to search for an entry point, no need for page redirection, no need for account management), greatly improving authentication efficiency, but also ensures the legitimacy of authentication requests and the security of data transmission through the binding of security identifiers and encrypted context information.

[0035] Based on the aforementioned information authentication method, this embodiment further supports target merchants to batch authenticate and share multiple operator phone numbers, and generates an independent and isolated authentication link for each number to achieve refined authorization management.

[0036] Once the target merchant accesses the authentication management page on their terminal device, the page displays a list of all operational staff phone numbers linked to their account. Merchants can interact with the interface (e.g., holding down the Ctrl key to select multiple numbers, or checking checkboxes one by one) to select multiple phone numbers. The front-end submits the internal identifiers (such as a list of phoneIds) corresponding to all selected phone numbers to the server along with the authentication sharing request. Upon receiving the request, the server parses the selected phone numbers and identifies them as the target numbers requiring authentication for this sharing operation.

[0037] Subsequently, the server executes an independent credential generation process for each target phone number. Specifically, for the first target phone number, the server generates a unique security identifier based on the security attributes of the target account that has passed encrypted authentication (including merchantId, current timestamp, etc.) and the number itself; at the same time, it assigns a globally unique sharing token (e.g., generated using the UUID algorithm) to it.

[0038] Next, the above process is repeated for the second target phone number to generate another independent set of security identifiers and sharing tokens, and so on. This ensures that each target phone number corresponds to a separate sharing token and a security identifier, with no sharing or association between them. Based on this, the server generates a corresponding authentication link for each target number requiring authentication in this sharing operation. The URL parameters of each authentication link contain the unique sharing token and security identifier for that number, in the form of: "https: / / auth.example.com / s?t=security_identifier_1&s=sharing_token_1", "https: / / auth.example.com / s?t=security_identifier_2&s=sharing_token_2", etc. These links are structurally completely independent, and even if generated by the same merchant in the same operation, they cannot be derived from or used interchangeably. After generation, the server can return multiple authentication links to the merchant's terminal in list form, allowing the merchant to send them to the corresponding operators. For example, the merchant can send link A to the operator in Beijing and link B to the operator in Shanghai, ensuring a one-to-one correspondence between region and personnel and preventing misoperation or unauthorized use.

[0039] Through the above mechanism, this embodiment achieves parallel, independent, and isolated authentication and distribution for multiple target numbers. Its technical advantages are: while maintaining high security, it significantly improves the efficiency of merchants in collaborative management across regions and multi-person teams, avoids permission confusion or authentication mismatch caused by shared links, and truly achieves refined control of "one number, one link; one person, one authorization."

[0040] To further strengthen the control mechanism for the use of authentication links and ensure that each front-end encryption operation is performed within a legitimate context, preventing link abuse or overuse, when any operator accesses an authentication link on their terminal device, their browser loads the authentication page and automatically parses the sharing token from the URL.

[0041] Subsequently, the terminal sends an initialization request to the server, carrying the sharing token. Upon receiving the request, the server reads the corresponding encryption context information from a cache unit (such as Redis) based on the sharing token. This encryption context information explicitly contains two key limiting parameters: the maximum number of uses (e.g., 10 times) and the validity period (e.g., 7 days). Before returning the encryption parameters, the server first verifies the current state: on the one hand, it checks whether the current system time is still within the validity period; on the other hand, it queries whether the number of uses recorded in the context is less than the maximum number of uses. Only when both conditions are met simultaneously will the server allow the operation to continue and return the encryption context information (such as key identifier kid, algorithm type, etc.) to the terminal.

[0042] After receiving the context, the operator enters their real-name authentication information (such as name and ID number) on the authentication page. Upon submission, the terminal invokes the front-end encryption module to perform local encryption on the real-name authentication information using the encryption context information, generating ciphertext. "Local encryption" means that the entire encryption operation is completed in the user device's memory; the original plaintext data never leaves the terminal, only the encrypted data is uploaded. The final encrypted authentication data, in addition to the ciphertext, also includes a security identifier extracted from the URL for subsequent server-side verification.

[0043] By moving the dual verification of usage count and validity period to the pre-encryption stage, this embodiment ensures that even if an attacker intercepts the link, they cannot continue to generate valid authentication data after exceeding the limit. Its technical effect is that, without relying on complex backend risk control, a lightweight context verification mechanism achieves precise control over the authentication link's lifecycle, effectively preventing replay attacks, brute-force enumeration, and resource abuse, significantly improving system robustness and compliance.

[0044] Optionally, the distribution method of the authentication link can be expanded to support efficient and reliable push of the authentication link to the target operator's terminal through multiple communication channels, adapting to the reach needs in different scenarios. After the server generates an authentication link for at least one target phone number, the system can automatically or manually trigger a sharing operation to push the authentication link to the corresponding operator's terminal device through at least one communication channel. The communication channels include, but are not limited to, the following three types: The first is SMS: The server calls the SMS platform interface to send a text message containing a short link to the target phone number, such as: "[XX Platform] Please complete real-name authentication: https: / / s.xxx / abc123 (valid for 7 days)". This method is applicable to all mobile terminals with SMS receiving capabilities and has a wide coverage. The second is instant messaging application messages: If the platform has been integrated with WeChat Work, DingTalk, or WeChat service accounts, and the target operator's mobile phone number has been bound to the corresponding account, the server can send a structured message card with an embedded authentication link button through its open API, which can be clicked to jump to the target. This method provides a better user experience and supports rich media interaction. The third method is a scannable image code: The server converts the authentication link into a QR code image (Base64 encoded or PNG format) and renders it on the merchant's terminal page. Merchants can print and post it directly or forward it through social media. Staff can then scan the code with their mobile phone camera or a QR code scanner to access the authentication page. This method is suitable for offline on-site distribution scenarios. The above communication channels can be used individually or in combination. For example, the system can send SMS messages and generate QR codes simultaneously, ensuring that staff can access the authentication portal through either channel. All content transmitted through all channels is a complete authentication link, which already contains a security identifier and sharing token, requiring no additional identity information.

[0045] By employing a multi-channel distribution mechanism, this embodiment addresses the challenge of reaching operators in complex environments such as remote locations, offline environments, and weak network conditions. Its technical advantages lie in significantly improving the delivery and completion rates of authentication tasks while ensuring the integrity of secure connections, achieving a seamless authentication experience that is "available anytime, anywhere, and across multiple devices."

[0046] Furthermore, to strengthen the server-side memory security management mechanism for sensitive real-name information and ensure that data is not persisted or leaked during processing, the server first decrypts the encrypted authentication data submitted by the operator's terminal after receiving it, restoring the original real-name authentication information (such as name and ID number) and security identifier. Subsequently, the server temporarily stores the real-name authentication information and the security identifier in memory. Here, "memory" specifically refers to a temporary buffer in the server application's heap memory (such as SecureByteBuffer in Java or a volatile char array in C++), not disk, database, or log file. This buffer is marked as a sensitive area and is prohibited from being serialized or written to swap space.

[0047] Next, the server reads the real-name authentication information from the memory and locates the corresponding target account based on the security identifier, thereby determining the encrypted channel associated with that account. The core of this encrypted channel is the channel key that is rotated monthly (e.g., scfkey_202512), which is automatically rotated monthly by the key management system to ensure long-term communication security. The server uses this channel key to encrypt the real-name authentication information again, generating carrier-encrypted text that conforms to the carrier's interface specifications.

[0048] Subsequently, the server transmits the ciphertext to the operator's server via a secure communication channel (such as an HTTPS connection established based on the bidirectional TLS 1.3 protocol). "Transmitting" means that the server does not parse or modify the ciphertext content, but only acts as a trusted relay, minimizing the risk of data exposure in intermediate stages.

[0049] Most importantly, regardless of whether the encryption or transmission operations are successful, the server initiates a separate, timed cleanup task: when a preset security period arrives, the real-name authentication information in memory is cleared. This preset security period is typically set to 500 milliseconds, a fixed value, and is independent of whether the transmission or encryption is successful. The cleanup operation is achieved by overwriting the memory area to a zero value (0x00), ensuring that the original data cannot be recovered through a memory dump.

[0050] Through the above mechanism, this embodiment achieves a "instant processing and immediate destruction" strategy for sensitive personal information. Its technical effect is that, while meeting the real-name registration requirements of operators, it fundamentally eliminates the risk of persistent storage of plaintext data on the server side, complying with the "minimum necessary, timely deletion" requirements of laws such as the Personal Information Protection Law and the Data Security Law for sensitive information.

[0051] Optionally, a two-factor authentication mechanism can be introduced, splitting real-name authentication into two stages: identity information and biometrics, to improve the reliability and anti-counterfeiting capabilities of the authentication results. The authentication page is designed to include multiple information input items, specifically two categories: first, an identity information input item, used to collect the operator's legal identity information, such as name and ID number; second, a biometric information collection item, used to collect their live biometric features, such as facial images or voiceprints. These two types of information together constitute complete real-name authentication information, where identity information is used to verify the consistency of legal identity, and biometric information is used to verify the authenticity of the operator. In the interaction process, the operator first fills in the relevant information in the identity information input item and submits it. The terminal uses the encrypted context information obtained from the authentication link to perform front-end local encryption of the identity information, generating the first encrypted authentication data, and sending it to the server. The server decrypts and performs preliminary verification of the data (such as ID card format verification). After the first encrypted authentication data passes authentication, the authentication page dynamically loads the biometric collection module (such as a face liveness detection component integrated with the Zoloz or Face++ SDK). The operator completes face capture or voice recording as prompted. The terminal also uses encrypted context information (which can be reused or newly allocated) to encrypt the collected biometric information locally at the front end, generate second encrypted authentication data, and submit it to the server.

[0052] By submitting data in stages, the system ensures that biometric data collection is triggered only after the identity information is initially deemed legitimate, avoiding unnecessary resource consumption. Simultaneously, two sets of encrypted data are generated and transmitted independently to prevent information leakage due to coupling. This dual-channel collection mechanism significantly enhances the authentication process's resistance to impersonation. Its technical effect lies in: through dual verification of "certificate + person," it effectively prevents fraudulent activities involving the use of other people's ID documents or photos for authentication, greatly improving the authenticity and legal validity of real-name authentication, and is particularly suitable for high-risk business scenarios (such as financial account opening, privacy number activation, etc.).

[0053] Optionally, based on two-factor authentication, a two-level authentication verification mechanism is further introduced to ensure that the final encrypted data is submitted to the operator only after both the identity information and biometric features have been independently verified. After receiving the first encrypted authentication data, the server first decrypts it to obtain the operator's identity information (such as name and ID number).

[0054] Subsequently, the server calls the relevant department's population database interface or a third-party real-name verification service to perform an authoritative comparison of the identity information. If the returned result is "consistent" or "matched," the identity information is deemed to have passed authentication; otherwise, the process terminates. After the identity information is successfully authenticated, the server waits to receive the second encrypted authentication data. Upon receipt, it is also decrypted to obtain biometric information (such as a facial feature vector). The server calls a facial comparison engine to calculate the similarity score between this feature and the pre-reserved photo in the ID card database. If the score is higher than a preset threshold (such as 0.95), the biometric information is deemed to have passed authentication. Only when both the identity information and the biometric information have passed authentication does the server perform subsequent operations: based on the security identifier, it finds the corresponding target account and its associated encrypted channel, and uses the currently rotated channel key to encrypt the complete real-name authentication information (including identity and biometrics) into operator ciphertext. This ciphertext is then sent to the operator's server through a secure communication channel to complete the final registration. If authentication fails at any stage (such as invalid ID card or mismatched face), the system immediately terminates the process, does not generate operator encrypted messages, and does not send any data to the operator, thereby avoiding the reporting of invalid or false information.

[0055] Through a rigorous two-factor authentication logic, this embodiment constructs a high-confidence identity verification closed loop. Its technical advantages include: while meeting operator compliance requirements, it significantly reduces the risks of false real-name registration and impersonation, providing the platform with auditable, traceable, and highly reliable real-name authentication results, supporting business operations with a higher level of security.

[0056] To facilitate understanding of the above technical solutions, the information authentication process will be explained in detail below with specific examples.

[0057] Step 1: Displaying the list of logged-in and verified target merchants The target merchant launches the target application (such as a merchant management app) on their terminal device, enters the target account (merchant_zhang) and password to initiate a login operation. Upon receiving this login operation, the server performs encrypted authentication of the target account: after successful verification, it generates a session identifier (sessionId, such as sess_abc123xyz), returns it to the merchant's terminal via the Set-Cookie command, and stores it in Redis, establishing a key-value pair session: sess_abc123xyz → userId = merchant A.

[0058] After a merchant successfully logs in, a request to display the authentication list is triggered. This request automatically carries the sessionId from the cookie. The server uses the sessionId to retrieve the userId from Redis, and then queries the database to obtain an array of phone numbers associated with the target account [13811112222, 13933334444, 13755556666]. The server uses the AES-128-CBC encryption algorithm, concatenating the currently logged-in user ID, a random UUID, and a millisecond-level timestamp into a string, and then hashing it using MD5 to generate a 16-byte one-time key. This key is used to preprocess and encrypt each real phone number before local encryption on the front end, generating an encrypted string encryptStr for each number. A masked phone number (e.g., 138****2222) is also generated based on each number. The server returns the mapping relationship between the masked phone number and the encrypted string to the front end, rendering the authentication list page and clearly distinguishing between and displaying authenticated numbers, target phone numbers awaiting authentication, and numbers that failed authentication.

[0059] Key features: In this step, the target account has been encrypted and authenticated, and is bound to the phone numbers of multiple operators, laying the foundation for generating authentication links later. The sharing token in the encrypted context information is decoupled from the target merchant's user identifier, ensuring security.

[0060] Step 2: Respond to the target merchant's authentication and sharing action, generate and share the authentication link. The target merchant performs an authentication sharing operation on the authentication list page: by repeatedly selecting the target phone numbers (13933334444, 13755556666) from Tianjin and Shanghai using Ctrl+click, and then clicking the "Generate Authentication Link" button. Upon receiving this operation, the server first confirms that the target merchant has the necessary permissions to access the target numbers: it decrypts the encryptStr string corresponding to each number, verifies that the userId contained within matches the current session's userId, and ensures the correct number attribution.

[0061] For each target number, the server independently performs the following operations to generate an authentication link: Assigning Security Identifiers and Sharing Tokens: Based on the security attributes (merchantId, current timestamp) of the target account after encrypted authentication, a unique security identifier (such as t_secure_tj_001, t_secure_sh_002) is generated for each target number using the HMAC-SHA256 algorithm; at the same time, a globally unique sharing token (such as share_uuid_tj, share_uuid_sh) is generated for each target number. The sharing token is decoupled from the user identifier of the target merchant.

[0062] Construct encryption context information: Use the share token, maximum number of uses (10 times), and validity period (7 days) as encryption context information, encrypt them with AES and store them in the cache unit Redis, with the key name share:{shareToken} and the value is the encrypted {merchantId, target number ciphertext, maxUse:10, expire:7d}.

[0063] Generate authentication link: Construct an authentication link based on the sharing token and security identifier. The URL parameters include the sharing token and security identifier, but do not contain plaintext information such as the target merchant's user identifier or target number. The generated authentication link will take the following form: https: / / auth.example.com / s?t=t_secure_tj_001&s=share_uuid_tj https: / / auth.example.com / s?t=t_secure_sh_002&s=share_uuid_sh The server pushes the authentication link to the corresponding operator's terminal through at least one communication channel: sending an SMS to 13933334444, sending a WeChat message to 13755556666, and generating a scannable graphic code for merchants to post offline. Each channel delivers the complete authentication link, embedding a security identifier and encrypted context information.

[0064] Step 3: The operator accesses the authentication link and submits the first encrypted authentication data. In Tianjin, workers clicked the authentication link in the text message on their terminals, and the browser loaded the authentication page. The page script automatically parsed the security identifier t_secure_tj_001 and the sharing token share_uuid_tj from the URL and sent an initialization request to the server.

[0065] The server reads the encryption context information from the cache unit based on the shared token. After verifying that the number of uses is less than the maximum number of uses and is still within the validity period, it returns the encryption context information (including the one-time kid and the algorithm type AES-128-GCM) to the terminal. The operator enters their name "Li Si" and ID number "120101199001011234" in the identity information field on the authentication page and clicks submit.

[0066] The terminal responds to the operator's input and generates a 16-byte random number as a one-time "kid" using Crypto.getRandomValues(). This "kid" is then used to initialize the white-box AES module to perform front-end local encryption on the real-name authentication information, generating the first encrypted authentication data. This encryption operation is completed in the operator's terminal memory; the original plaintext never leaves the terminal. The first encrypted authentication data, containing the security identifier and "kid," is submitted to the server via HTTPS.

[0067] Key features: This step enables front-end local encryption of real-name authentication information using encryption context information. The encrypted authentication data contains a security identifier, and the encryption process is subject to both maximum usage times and validity period restrictions.

[0068] Step 4: The server decrypts the first encrypted authentication data and authenticates the identity information. The server receives the first encrypted authentication data, uses the `kid` value to reconstruct the white-box AES reverse obfuscation lookup table, and decrypts it to obtain the operator's identity information (name, ID number). After decryption, `kid` and the obfuscation table context are immediately destroyed from memory.

[0069] The server temporarily stores the decrypted identity information in a SecureByteBuffer in memory and calls the relevant department's population database interface for identity authentication. After successful authentication, the server generates a dataToken (such as data_uuid_lisi) and stores it in Redis. The key-value pair is data:{dataToken} → {merchantId, target number, identity information hash}. At the same time, the server writes the dataToken to the operator's terminal's security cookie via Set-Cookie.

[0070] Key features: Plaintext information is only temporarily stored in memory and is not written to disk; the dataToken is decoupled from the user identifier of the target merchant and forms a state lock with subsequent processes.

[0071] Step 5: The operator submits the second encrypted authentication data (biometric information). The authentication page dynamically loads biometric information collection items and calls the Alipay Zoloz SDK to initiate face verification. After the operator completes the liveness detection, the terminal collects biometric information (facial feature vector), regenerates a new one-time kid (completely independent of the first-stage kid), generates second encrypted authentication data through white-box AES encryption on the front end, and sends it to the server.

[0072] Step 6: The server completes two-factor authentication and generates carrier-encrypted messages. The server decrypts the second encrypted authentication data to obtain biometric information, calls the face comparison engine to match it with the photos reserved in the ID card database, and obtains a comparison score of 0.98. After successful authentication, the server generates a faceToken (such as face_uuid_lisi), and stores the verification result (pass status, comparison score, timestamp) in Redis after AES encryption, with the key name face:{faceToken}.

[0073] Once both identity and biometric information have been authenticated, the server performs a final verification before submission: Read the dataToken and faceToken from memory, retrieve the merchantId from Redis, and verify their consistency. Retrieve the current monthly rotating scfkey (e.g., scfkey_202512) from the key management system. The scfkey is used to perform AES-128-CBC double encryption on the complete real-name authentication information (name, ID number, and facial data) in memory to generate carrier ciphertext.

[0074] Key features: Two-factor authentication mechanism ensures high-confidence identity verification; scfkey enables key rotation and forward confidentiality; consistency verification between dataToken and faceToken enables multi-stage state locking.

[0075] Step 7: Transmit carrier-encrypted data and clear memory data The server transmits the ciphertext to the operator's server via a two-way TLS 1.3 secure communication channel, acting as a trusted relay throughout the process without parsing or modifying the ciphertext content. The operator then uses the currently valid scfkey to decrypt the ciphertext and complete the real-name registration, assigning a privacy-protected intermediate number to the number 13933334444.

[0076] Regardless of whether the transmission is successful or not, the server clears the real-name authentication information in memory through a memory overwrite operation when the preset security time (500 milliseconds) is reached. The preset security time is unrelated to whether the transmission or encryption is successful. At the same time, the number of times the shareToken has been used in Redis is atomically incremented. When the number of uses reaches the limit of 10, the key-value pair is automatically deleted, and the authentication link is invalidated.

[0077] Furthermore, if the target merchant needs to authenticate newly added operators not displayed in the list, a manual number addition authentication process is executed: Click the "Add Authentication Number" button, enter the new number 13800009999, and the front end encrypts the number using white-box AES encryption and transmits it to the server. After decryption, the server sends an SMS verification code to 13800009999, and the operator enters the verification code to complete the number verification. After successful verification, the number is automatically bound to the target account and enters the authentication process described in step two above and thereafter, using the same encrypted transmission and security verification mechanism throughout.

[0078] Example scenario: Merchant A (Beijing) needs to have the verified mobile phone number 13877778888 of employee C of partner B (Tianjin) in another city.

[0079] Generate a cross-domain sharing link: After Merchant A logs in and clicks the "Share" button, the backend extracts the dataToken from the security cookie and checks Redis to verify the identity and consistency of the target number's encrypted data. Upon successful verification, a shareToken (share_uuid_cross) decoupled from the dataToken is generated. The merchant ID, the encrypted target number, the remaining 10 attempts, and the 7-day validity period are encrypted using AES and stored in the Redis key share:{shareToken}. A short link is then returned: https: / / auth.example.com / s?t=share_uuid_cross.

[0080] Remote employee access link: After employee C clicks the link in WeChat, the server extracts the shareToken to verify its validity, generates a remote session token (UUID2), and binds it to the shareToken, merchant ID, and remaining usage attempts, writing it to a security cookie in employee C's browser. During page rendering, the encrypted phone number in the shareToken is decrypted and a mask is generated for display, so employee C does not need to manually enter the number throughout the process.

[0081] Data Submission and Frequency Limiting: After employee C fills in the data and generates a encrypted kid, the server retrieves the UUID2 from the cookie, looks up the shareToken in Redis, and performs a DECR atomic operation to deduct the remaining attempts. If the attempts exceed 10, the shareToken in Redis is deleted, and the link is invalidated. After the attempts pass verification, the server decrypts the data using the kid and calls the face recognition SDK to complete the verification. After successful verification, the data is re-encrypted using the merchant A's SCFkey and directly transmitted to the operator.

[0082] Figure 2 This is a flowchart illustrating an information authentication method provided for an exemplary embodiment of this application. Figure 2 As shown, the method includes: 201. Receive the authentication link sent by the server. The authentication link carries a security identifier and encrypted context information assigned to the corresponding target phone number based on the target account. 202. In response to the operator's access to the authentication link, display the authentication page corresponding to the authentication link; 203. In response to input operations on the authentication page, obtain the real-name authentication information entered by the target operator, and parse the security identifier and encryption context information from the authentication link; 204. Encrypt the real-name authentication information using the encryption context information to obtain encrypted authentication data. Add the security identifier to the encrypted authentication data and send it to the server so that the server can provide the real-name authentication information carried in the encrypted authentication data to the operator's server based on the security identifier.

[0083] Figure 3 This is a schematic diagram of the structure of an electronic device provided as an exemplary embodiment of this application. For example... Figure 3 As shown, the electronic device includes a memory 30a and a processor 30b; wherein the memory 30a is used to store a computer program; the processor 30b is coupled to the memory 30a and is used to execute the computer program to perform the steps in the above method.

[0084] Furthermore, such as Figure 3 As shown, the server device also includes other components such as a communication component 30c, a power supply component 30d, an audio component 30e, and a display screen 30f. Figure 3 The diagram only shows some components and does not mean that the computer device includes only these components. Figure 3 The components shown.

[0085] An exemplary embodiment of this application also provides a computer-readable storage medium storing a computer program, which, when executed by a processor, causes the processor to perform the steps in the above-described method.

[0086] An exemplary embodiment of this application also provides a computer program product, including: a computer program that, when executed by a processor of an electronic device, causes the processor to perform the steps in the above-described method.

[0087] Those skilled in the art will understand that embodiments of this application can be provided as methods, systems, or computer program products. Therefore, this application can take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, this application can take the form of a computer program product embodied on one or more computer-usable storage media (including but not limited to disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0088] This application is described with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of this application. It will be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, generate instructions for implementing the flowchart... Figure 1 One or more processes and / or boxes Figure 1 A device that provides the functions specified in one or more boxes.

[0089] These computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable data processing device to function in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means, which are implemented in a process Figure 1 One or more processes and / or boxes Figure 1 The function specified in one or more boxes.

[0090] These computer program instructions may also be loaded onto a computer or other programmable data processing equipment to cause a series of operational steps to be performed on the computer or other programmable equipment to produce a computer-implemented process, thereby providing instructions that execute on the computer or other programmable equipment for implementing the process. Figure 1 One or more processes and / or boxes Figure 1 The steps of the function specified in one or more boxes.

[0091] In a typical configuration, a computing device includes one or more processors (CPU), input / output interfaces, network interfaces, and memory.

[0092] Memory may include non-persistent storage in computer-readable media, such as random access memory (RAM) and / or non-volatile memory, such as read-only memory (ROM) or flash RAM. Memory is an example of computer-readable media.

[0093] Computer-readable media includes both permanent and non-permanent, removable and non-removable media that can store information using any method or technology. Information can be computer-readable instructions, data structures, modules of programs, or other data. Examples of computer storage media include, but are not limited to, phase-change memory (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), other types of random access memory (RAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory or other memory technologies, CD-ROM, digital versatile optical disc (DVD) or other optical storage, magnetic tape, magnetic disk storage or other magnetic storage devices, or any other non-transferable medium that can be used to store information accessible by a computing device. As defined herein, computer-readable media does not include transient computer-readable media, such as modulated data signals and carrier waves.

[0094] It should also be noted that the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitation, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes said element.

[0095] The above description is merely an embodiment of this application and is not intended to limit the scope of this application. Various modifications and variations can be made to this application by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this application should be included within the scope of the claims of this application.

Claims

1. An information authentication method, characterized in that, include: In response to receiving a login operation from a target merchant based on a target account, the target account is encrypted and authenticated; wherein, the target account is bound to the phone numbers of multiple operators. After the target account passes encrypted authentication, it responds to the authentication sharing operation of the target merchant, generates and shares an authentication link for at least one target phone number; wherein, the authentication link carries a security identifier and encryption context information assigned to the corresponding target phone number based on the target account; The terminal receives encrypted authentication data submitted by the terminal accessing the authentication link; wherein the encrypted authentication data is generated by the terminal obtaining the real-name authentication information entered by the operator in the displayed authentication page, and using the encryption context information parsed from the authentication link to perform front-end local encryption on the real-name authentication information, and the encrypted authentication data includes the security identifier. Decrypt the encrypted authentication data to obtain the real-name authentication information and the security identifier; Based on the security identifier, an encryption channel corresponding to the target account is determined, and the real-name authentication information is encrypted into carrier ciphertext using the key of the encryption channel; The operator's encrypted message is sent to the operator's server.

2. The method according to claim 1, characterized in that, In response to the target merchant's authentication sharing operation, an authentication link for at least one target phone number is generated, including: In response to the authentication and sharing operation of the target merchant, determine the target number that needs to be authenticated for this sharing operation, and confirm that the target merchant has operation permissions for the target number; Based on the security attributes of the target account after encrypted authentication, a security identifier is assigned to the target number, and a sharing token is generated for the target number; The sharing token, maximum number of uses, and validity period are stored as encrypted context information in the cache unit, wherein the sharing token is decoupled from the user identifier of the target merchant; The authentication link is constructed based on the sharing token and the security identifier. The URL parameters of the authentication link include the sharing token and the security identifier, but the URL parameters of the authentication link do not include the user identifier of the target merchant or the plaintext information of the target number. The authentication link is configured to: when accessed, obtain the encryption context information from the cache unit based on the sharing token, so as to support the terminal of any operator to perform front-end local encryption of the real-name authentication information entered by any operator, and to perform authentication-free operation on the real-name authentication information based on the security identifier.

3. The method according to claim 2, characterized in that, In response to the target merchant's authentication and sharing operation, determine the target number that needs to be authenticated for this sharing operation, including: In response to the target merchant's multiple selections of phone numbers from the number list, the selected phone numbers are identified as the target numbers that need to be authenticated for this sharing operation. Constructing the authentication link based on the sharing token and the security identifier includes: generating a corresponding authentication link for each target number that needs to be authenticated in this sharing operation, and each target number corresponds to a sharing token and a security identifier.

4. The method according to claim 2, characterized in that, The encrypted authentication data is generated by the terminal responding to any operator's access to the authentication page corresponding to the authentication link and inputting real-name authentication information on the authentication page. Based on the sharing token, the terminal reads the encryption context information from the cache unit, and after determining that the number of times the encryption context information is used for encryption operations is less than the maximum number of uses and the encryption context information is still within the validity period, the terminal uses the encryption context information to perform front-end local encryption on the real-name authentication information.

5. The method according to any one of claims 1-4, characterized in that, Share an authentication link targeting at least one specific phone number, including: The authentication link is pushed to the terminal of the operator corresponding to the at least one target phone number through at least one communication channel, wherein the communication channel includes at least one of SMS, instant messaging application messages, or scannable graphic codes.

6. The method according to claim 1, characterized in that, After decrypting the encrypted authentication data to obtain the real-name authentication information and the security identifier, the method further includes: temporarily storing the real-name authentication information and the security identifier in memory; Accordingly, based on the security identifier, an encryption channel corresponding to the target account is determined, and the real-name authentication information is encrypted into carrier ciphertext using the key of the encryption channel, including: The real-name authentication information is read from the memory and encrypted into carrier ciphertext using the channel key that is rotated in. The operator's encrypted message is transmitted to the operator's server through a secure communication channel; And when a preset security time is reached, the real-name authentication information in the memory is cleared. The preset security time is unrelated to whether the transmission or encryption is successful.

7. The method according to claim 6, characterized in that, The authentication page includes multiple information input items, including identity information entry items and biometric information collection items. The real-name authentication information includes identity information and biometric information. Receive encrypted authentication data submitted by any operator's terminal, including: Receive the identity information entered by any operator through the identity information entry field as the first encrypted authentication data; as well as After the first encrypted authentication data is successfully authenticated, the biometric information collected by any operator through the biometric information collection item is received as the second encrypted authentication data.

8. The method according to claim 7, characterized in that, Before encrypting the real-name authentication information into carrier ciphertext using the key of the encrypted channel, the method further includes: The first encrypted authentication data is decrypted to obtain the identity information of any of the operators, and the identity information is then authenticated. as well as The second encrypted authentication data is decrypted to obtain the biometric information of any of the operators, and the identity information is then authenticated. When both the identity information and the biometric information are authenticated, the real-name authentication information is encrypted into operator ciphertext using the currently rotated channel key based on the security identifier.

9. An information authentication method, characterized in that, include: Receive an authentication link sent by the server, the authentication link carrying a security identifier and encryption context information assigned to the corresponding target phone number based on the target account; In response to the operator's access to the authentication link, the authentication page corresponding to the authentication link is displayed; In response to an input operation on the authentication page, the system obtains the real-name authentication information entered by the target operator and parses the security identifier and the encryption context information from the authentication link. The real-name authentication information is encrypted using the encryption context information to obtain encrypted authentication data. The security identifier is added to the encrypted authentication data and sent to the server, so that the server can provide the real-name authentication information carried in the encrypted authentication data to the operator's server based on the security identifier.

10. An electronic device, characterized in that, include: Memory and processor; The memory is used to store a computer program; the processor, coupled to the memory, is used to execute the computer program to implement the steps of any one of claims 1-8 or 9.

11. A computer-readable storage medium storing a computer program, characterized in that, When the computer program is executed by a processor, it causes the processor to perform the steps of any one of claims 1-8 or 9.

12. A computer program product, characterized in that, The computer program product includes a computer program / instruction that, when executed by a processor, causes the processor to perform the steps of any one of claims 1-8 or 9.

Images