Secure login method, system and device based on two-dimensional code and storage medium

Abstract

The invention relates to the technical field of data processing, and particularly provides a secure login method, system and device based on a two-dimensional code and a storage medium, and the method comprises the steps: generating a triple containing enterprise identity information, a scene identifier and a timestamp according to a login scene, and generating a dynamic encrypted two-dimensional code through encryption processing; a user scans the webpage two-dimensional code through a mobile device, or scans the two-dimensional code displayed by the mobile device offline through a code scanning gun; the front end analyzes the encrypted data, automatically judges the login scene according to the scene identifier, and sends the data and the scene type to the rear end; verifying the validity of the timestamp after decryption by the rear end, verifying the binding relationship between the enterprise identity and the scene, and signing and issuing a login token after verification is passed; and the back end pushes the session state and the token to each associated service system in real time through WebSocket, and each system synchronizes the user session to the Redis distributed cache. According to the method, the problems of repeated login and scattered authentication in a multi-system environment are solved through unified online and offline authentication of the dynamically encrypted two-dimensional code.

Description

Technical Field

[0001] This invention belongs to the field of data processing technology, specifically relating to a secure login method, system, device, and storage medium based on QR codes. Background Technology

[0002] In existing technologies, enterprise users often face the challenges of repeated logins and fragmented authentication in multi-system, cross-architecture (B / S and C / S hybrid) environments. Traditional username and password methods are prone to leakage, while ordinary QR code logins often lack scenario adaptability and strict security binding mechanisms, making it difficult to simultaneously meet the unified identity authentication needs of different online and offline scenarios. In addition, existing solutions typically lack efficient and real-time cross-system session synchronization methods after token issuance, resulting in a poor single sign-on experience of "login once, usable everywhere," which is particularly prominent in enterprise environments that require high security and business continuity. Summary of the Invention

[0003] In view of the above-mentioned shortcomings of the prior art, the present invention provides a secure login method, system, device and storage medium based on QR code to solve the above-mentioned technical problems.

[0004] In a first aspect, the present invention provides a secure login method based on a QR code, comprising: Based on the login scenario, a triplet containing the enterprise's unique identity information, scenario identifier, and timestamp is generated, and the triplet is encrypted to generate a dynamic encrypted QR code. Users can scan the QR code using their mobile devices, or in a C / S scenario, a barcode scanner can scan the QR code displayed on the user's mobile device. The front-end parses the encrypted data in the QR code, automatically determines the login scenario based on the scenario identifier, and sends the encrypted data and scenario type to the back-end authentication interface; The backend decrypts the encrypted data and verifies the validity of the timestamp, verifies the enterprise identity and the binding relationship with the scenario, and issues a login token after the verification is successful. The backend pushes the login status and token to the associated business systems via WebSocket, and each system synchronizes the user session to the distributed cache to achieve single sign-on.

[0005] In one optional implementation, a triplet containing the enterprise's unique identity information, a scenario identifier, and a timestamp is generated based on the login scenario. This triplet is then encrypted to generate a dynamically encrypted QR code, including: The enterprise's unified social credit code, the scenario identifier assigned according to the login scenario, and the unique timestamp generated by the system are bound together to form a triplet, and the triplet is stored in the database as a one-time login session; The triple is concatenated with the company name, industry classification code, and random number to form the plaintext data to be encrypted; The plaintext data is encrypted using the AES-256-CBC algorithm, and the encryption key is dynamically generated and rotated by the system at a configurable period. The data before encryption is processed together with the encrypted data using the HMAC-SHA256 algorithm to generate a message authentication code. The encrypted ciphertext data is encoded into a QR code image, which is time-sensitive and for one-time use only.

[0006] In one optional implementation, the user scans the QR code via a mobile device, or in a C / S scenario, a barcode scanner scans the QR code displayed on the user's mobile device, including: The dynamic encrypted QR code is displayed adaptively on different terminal interfaces according to the login scenario, including: the user page of the B / S system, the user page of the mobile official account or mini program, the C / S client interface or multimedia touch screen. In the online B / S login scenario, users use an application on their mobile devices to scan the QR code displayed on the webpage; in the offline C / S login scenario, users display their saved personal QR code on their mobile devices, which is then scanned by a barcode scanner on the on-site equipment. After the scanning device acquires the QR code image, the front-end application extracts the encrypted data by integrating a QR code parsing plugin. Based on the scene identifier and scanning device type in the data, it automatically determines whether the current scenario is an online B / S scenario or an offline C / S scenario.

[0007] In one optional implementation, the front-end parses the encrypted data in the QR code, automatically determines the login scenario based on the scenario identifier, and sends the encrypted data and scenario type to the back-end authentication interface, including: The front-end application decodes the scanned QR code image using an integrated QR code parsing component to extract the encrypted data string contained therein; The front end parses the preset scene identifier field in the encrypted data and, in conjunction with the obtained scanning device type information, automatically determines whether the current login scenario belongs to an online B / S scenario or an offline C / S scenario; wherein the device type information is obtained by parsing the User-Agent field in the HTTP request header or the barcode scanner device driver information; The front end encapsulates the encrypted data, the identified scene type, the device identification information, and the current timestamp into a structured JSON request body; The front end uses the HTTP protocol and encrypted communication to send the JSON request body to the unified microservice authentication interface of the back end for subsequent decryption and authentication.

[0008] In an optional implementation, the front end encapsulates the encrypted data, the identified scene type, device identification information, and the current timestamp into a structured JSON request body, including: Construct a structured JSON object as the request body, which must contain at least the following predefined fields: encryptedData: The field value is the encrypted data string obtained through parsing; sceneType: The field value is the identified scene type, used to identify online B / S or offline C / S login scene; deviceIdentifier: The field value is the identification information of the scanning device; clientTimestamp: The field value is the current timestamp generated by the frontend when the request was initiated; The field structure and field names of the JSON object are predefined by the front-end and back-end protocols to ensure the consistency and parsability of data transmission.

[0009] In one optional implementation, the backend decrypts the encrypted data and verifies the timestamp validity, verifies the enterprise identity and scenario binding relationship, and issues a login token upon successful verification, including: The backend microservice uses the key corresponding to the encryption to perform AES-256-CBC decryption on the received encrypted data, restoring the original triplet information containing the enterprise's unified social credit code, scenario identifier, and timestamp; The timestamp obtained from decryption is compared with the server's current time to determine if it is within a preset valid time window; if it exceeds the window, the authentication process is terminated and a timeout error is returned. The database is queried based on the decrypted unified social credit code of the enterprise to verify the existence status and legality of the corresponding enterprise user; the authorization binding relationship between the decrypted scenario identifier and the device or platform that initiated the authentication request is valid is verified based on the decrypted scenario identifier. After all verifications are successful, the token issuance service is invoked to generate a formal login token, which is then returned to the requester to establish an authentication session.

[0010] In one optional implementation, the backend pushes the login status and token to the associated business system via WebSocket, and each system synchronizes the user session to a distributed cache to achieve single sign-on, including: The backend service encapsulates the issued official login token, the corresponding user identity identifier and permission information into a unified session state object, and pushes it in real time to all related business systems that the enterprise user has the right to access through the established WebSocket long connection channel; After receiving the session state object, each related business system stores it in a shared Redis distributed cache and sets a cache expiration time for the session that corresponds to the token's validity period. When a user accesses or switches between any associated B / S or C / S business systems, the system retrieves and verifies the user's login status by querying the Redis distributed cache, thereby achieving single sign-on and session sharing across systems and architectures.

[0011] Secondly, the present invention provides a secure login system based on a QR code, comprising: The dynamic generation module is used to generate a triplet containing the enterprise's unique identity information, scenario identifier, and timestamp based on the login scenario, and to encrypt the triplet to generate a dynamic encrypted QR code. The user scanning module is used by the user to scan the QR code through a mobile device, or by a barcode scanner to scan the QR code displayed on the user's mobile device in a C / S scenario. The front-end parsing module is used to parse the encrypted data in the QR code, automatically determine the login scenario based on the scenario identifier, and send the encrypted data and scenario type to the back-end authentication interface. The backend decryption module is used by the backend to decrypt encrypted data and verify the validity of timestamps, verify the enterprise identity and the binding relationship of the scenario, and issue a login token after successful verification. The login sharing module is used by the backend to push the login status and token to the associated business system via WebSocket. Each system synchronizes the user session to the distributed cache to achieve single sign-on.

[0012] Thirdly, a device is provided, comprising: Memory for storing QR code-based secure login procedures; A processor is configured to implement the steps of the QR code-based secure login method provided in the first aspect when executing the QR code-based secure login program.

[0013] Fourthly, a computer-readable storage medium is provided, on which a QR code-based secure login program is stored, wherein when the QR code-based secure login program is executed by a processor, the steps of the QR code-based secure login method provided in the first aspect are implemented.

[0014] The beneficial effects of this invention are that the QR code-based secure login method, system, device, and storage medium provided by this invention, by dynamically encrypting QR codes to carry enterprise identity, scenario, and time information, achieve unified online and offline authentication, effectively solving the problems of repeated logins and scattered authentication in multi-system environments. It adopts a combination of front-end intelligent scenario discrimination and back-end binding verification, significantly improving the security and scenario adaptability of the login process. Simultaneously, through real-time WebSocket push and distributed cache synchronization, it ensures the consistency and immediacy of cross-system session states, truly achieving efficient and secure cross-architecture single sign-on, improving the overall user experience and system security level for enterprise users. Attached Figure Description

[0015] To more clearly illustrate the technical solutions in the embodiments of the present invention or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, for those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0016] Figure 1 This is a schematic flowchart of a method according to an embodiment of the present invention.

[0017] Figure 2 This is a schematic block diagram of a system according to an embodiment of the present invention.

[0018] Figure 3 This is a schematic diagram of the structure of a device provided in an embodiment of the present invention. Detailed Implementation

[0019] To enable those skilled in the art to better understand the technical solutions of this invention, the technical solutions of the embodiments of this invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this invention, and not all embodiments. Based on the embodiments of this invention, all other embodiments obtained by those skilled in the art without creative effort should fall within the scope of protection of this invention.

[0020] Unless otherwise defined, all technical and scientific terms used herein have the same meaning as commonly understood by one of ordinary skill in the art to which this invention pertains. The terminology used herein in the description of the invention is for the purpose of describing particular embodiments only and is not intended to be limiting of the invention.

[0021] The QR code-based secure login method provided in this embodiment of the invention is executed by a computer device, and correspondingly, the QR code-based secure login system runs on the computer device.

[0022] Figure 1 This is a schematic flowchart illustrating a method according to an embodiment of the present invention. Wherein, Figure 1 The implementing entity can be a QR code-based secure login system. Depending on different requirements, the order of the steps in this flowchart can be changed, and some can be omitted.

[0023] like Figure 1 As shown, the method includes: S1. Generate a triplet containing the enterprise's unique identity information, scenario identifier, and timestamp based on the login scenario, and encrypt the triplet to generate a dynamic encrypted QR code; S2. The user scans the QR code using a mobile device, or in a C / S scenario, a barcode scanner scans the QR code displayed on the user's mobile device; S3. The front-end parses the encrypted data in the QR code, automatically determines the login scenario based on the scenario identifier, and sends the encrypted data and scenario type to the back-end authentication interface; S4. The backend decrypts the encrypted data and verifies the validity of the timestamp, verifies the enterprise identity and the binding relationship with the scenario, and issues a login token after the verification is successful; S5. The backend pushes the login status and token to the associated business system via WebSocket, and each system synchronizes the user session to the distributed cache to achieve single sign-on.

[0024] In one embodiment of the present invention, based on step S1, the following will provide a possible embodiment and describe its specific implementation in a non-limiting manner.

[0025] The system runs on a Spring Boot-based backend framework, relying on a Cassandra database to store session state and using Redis to manage dynamic encryption keys. First, when a user initiates a login request, the system retrieves the corresponding scenario identifier (Platform_ID) from a pre-configured mapping table based on the login scenario (e.g., B / S webpage, WeChat official account, or offline terminal). The system binds the enterprise's unified social credit code, the scenario identifier, and a unique timestamp generated in ISO 8601 format to form a triple. This triple, through its generated composite primary key (formatted as "credit code_scenario identifier_timestamp"), serves as a one-time login session, stored in the Cassandra database with a time-to-live (TTL) set, and simultaneously written to a Redis cache for fast retrieval.

[0026] Subsequently, the system concatenates the triple with the company name, industry classification code, and a 16-byte random number (Nonce) generated by a secure random number generator, using specific invisible characters as field separators to form a structured plaintext data to be encrypted.

[0027] The encryption process employs a multi-layered security mechanism. The system obtains the currently valid AES-256 encryption key through a dynamic key management service. This key is automatically rotated in the background at a configurable period (e.g., 24 hours), and both the old and new keys are securely stored to support the decryption of historical data. During encryption, the plaintext data is encrypted using the AES-256-CBC algorithm, generating a random 16-byte initialization vector (IV). To ensure data integrity and prevent tampering, a message authentication code (signature) is generated from the plaintext using the same key via the HMAC-SHA256 algorithm before encryption.

[0028] Finally, the encrypted ciphertext, the key ID used, the initialization vector (IV), and the HMAC signature are serialized into a string according to a predefined format and then URL-secured using Base64 encoding. The encoded string is then used by the ZXing library to generate a QR code bitmap of a specified size and fault tolerance, with the option to embed a company logo in the center of the bitmap. The final output dynamic encrypted QR code is provided to the front end as a Base64 data URL. This QR code has strict time sensitivity and is for one-time use, thus forming the trust starting point for the secure login process.

[0029] In one embodiment of the present invention, based on step S2, the following will provide a possible embodiment and describe its specific implementation in a non-limiting manner.

[0030] 1. Multi-terminal adaptive display: The dynamically encrypted QR code generated by the system is output as Base64 format image data through a unified interface. The adaptive display logic of this data on different terminal channels is as follows: B / S system pages: In the user's personal center or login page of the enterprise web portal, the front-end application (such as one built on Vue.js) is accessed through... You can use tags or the vue-qrcode component library to directly render and display the QR code data.

[0031] Mobile page: On the user's "My" page of the company's official WeChat account or mini program, the QR code is loaded and displayed using the image component of the mini program framework (such as WeChat mini program) or corresponding H5 technology.

[0032] C / S client or offline terminal: On desktop client applications (C / S architecture) or multimedia touch screens deployed in experience centers or service outlets, QR codes are obtained and displayed by calling backend interfaces through embedded web views or native graphical interface components in the client.

[0033] 2. User scanning operation: The user adopts the appropriate scanning method according to the scene: Online B / S login scenario: Users use an application with scanning function (such as WeChat, Alipay or enterprise-specific App) that is already installed on their personal mobile device (such as a mobile phone) to launch its "scan" function and scan the QR code displayed on the webpage.

[0034] Offline C / S login scenario: Users save or instantly retrieve their personal encrypted QR code in the enterprise's mobile application (official account / mini-program). At the on-site service point, authorized staff operate a physical barcode scanner connected to the C / S client to scan the QR code on the user's mobile phone screen.

[0035] 3. Front-end parsing and intelligent scene identification: The data processing flow after the scanning behavior is triggered is as follows: QR code parsing: In online scenarios, the user's scanning app parses the image to obtain an encrypted data string; in offline scenarios, the barcode scanner transmits the read data to a connected C / S client. The client or front-end application integrates a QR code parsing library (such as jsQR or vue-qrcode-reader) to decode the data and extract the encoded encrypted data packet.

[0036] Automatic scene identification: The front-end application performs preliminary parsing of the data packet before decryption, identifying the preset "scene identifier" field. Simultaneously, it automatically determines the device type based on the context information at the time of the scan. In online B / S scenarios, the mobile browser environment is usually identified by parsing the User-Agent in the HTTP request header.

[0037] In offline C / S scenarios, the barcode scanner is clearly identified as a specific barcode scanner device through the barcode scanner driver interface or client system information.

[0038] The system logically matches the "scene identifier" with the "device type". For example, if the identifier is an online platform ID and the device is from a mobile browser, it is identified as an online B / S login scenario; if the identifier is an offline barcode scanner ID and the device is a specific barcode scanner, it is identified as an offline C / S login scenario. This identification result will be used as one of the key parameters and prepared to be sent to the backend authentication service along with encrypted data.

[0039] In one embodiment of the present invention, based on step S3, the following will provide a possible embodiment and describe its specific implementation in a non-limiting manner.

[0040] 1. Encrypted Data Extraction: The front-end application integrates a dedicated QR code parsing library (e.g., in a Vue.js-based project, the vue-qrcode-reader component is used; in a pure JavaScript environment, the jsQR library is used). When the scanning device (user's mobile phone or barcode scanner) captures the QR code image, the decode method of the parsing library is called to decode the image. The output result is the original string after Base64Url decoding. This string is the complete encrypted data packet carrying the key identifier (Key ID), initialization vector (IV), ciphertext, and HMAC signature.

[0041] 2. Intelligent Scene Identification: The front-end logic performs preliminary parsing of the data packets before decryption to extract key metadata. Specific steps include: Extracting the Platform ID: Encrypted data packets follow a predefined format (e.g., "v1.0|KeyID|IV|CipherText|HMAC|Timestamp"). The front-end parses each part by splitting the string and, according to convention, obtains the preset "Platform ID" field from specific fields or by performing preliminary decoding of the ciphertext (e.g., parsing the Base64Url header).

[0042] Device type identification: Simultaneously, the front-end application collects environmental information about the scanning process to determine the device type. In online B / S scenarios, H5 pages or mini-programs running in users' mobile browsers can obtain detailed User-Agent strings by reading the navigator.userAgent property or calling the corresponding framework API (such as wx.getSystemInfo in WeChat mini-programs).

[0043] In offline C / S scenarios, the desktop client application connected to the barcode scanner obtains the barcode scanner's unique device identifier (such as SN number) and device type information by calling the SDK or driver interface provided by the barcode scanner manufacturer.

[0044] Logical discrimination: The front-end performs rule matching between the parsed "scene identifier" and "device type". For example, if the scene identifier is prefixed with "B2B_WEB_" or "MP_OFFICIAL_" and the device type is a mobile browser, it is discriminated as an "online B / S scene"; if the scene identifier is prefixed with "SG_OFFLINE_" and the device information comes from a specific barcode scanner driver, it is discriminated as an "offline C / S scene". This discrimination result, along with the device identifier information, will be recorded.

[0045] 3. Request Data Encapsulation: The frontend encapsulates the information obtained in the above steps into a structured JSON object. This object must contain at least the following fields: encryptedData(String): The complete encrypted data string.

[0046] sceneType(String): The identified scene type, such as "WEB_BROWSER" or "SCAN_GUN".

[0047] platformId(String): The original scene identifier parsed from the data packet.

[0048] deviceInfo(Object): Contains the device identifier (such as the User-Agent hash or barcode scanner serial number) and the device type.

[0049] clientTimestamp(Number): The timestamp (in milliseconds) generated by the frontend for the current request.

[0050] Then, the object is serialized into a JSON string request body using the JSON.stringify() method.

[0051] 4. Secure transmission: The frontend initiates a POST request via the HTTP protocol using libraries such as axios or fetch. The request configuration is as follows: URL: Points to the unified microservice authentication interface on the backend, such as https: / / api.example.com / auth / v1 / qr / verify.

[0052] Headers: Set Content-Type: application / json, and can include the application identifier according to security requirements.

[0053] Body: The JSON string serialized in the previous step is used as the request body.

[0054] Secure Channel: The entire request is transmitted over an HTTPS (TLS 1.2 and above) encrypted channel to ensure secure transmission. To prevent replay attacks, a random number (Nonce) generated by the frontend can be added to the header and verified by the backend.

[0055] After the request is sent, the frontend waits for and processes the response from the backend interface, thus completing the secure submission of the authentication data.

[0056] In one embodiment of the present invention, based on step S4, the following will provide a possible embodiment and describe its specific implementation in a non-limiting manner.

[0057] 1. Receiving and Extracting Data: The backend, built on Spring Boot, uses an authentication microservice (such as QrAuthService) to receive HTTP requests from the frontend via its exposed REST interface (e.g., POST / auth / v1 / qr / verify). The service first parses the structured JSON data from the request body, extracting key fields such as encryptedData (encrypted data string), sceneType (scene type), and deviceInfo (device information).

[0058] 2. Data decryption and core information restoration: Key location: The service performs a preliminary parsing of encryptedData to extract the key identifier (keyId) used during encryption. Subsequently, it calls the dynamic key management service to retrieve the corresponding Base64-decoded raw AES-256 key byte array from the currently active key or historical key storage (such as Redis) based on the keyId.

[0059] AES Decryption: Using the obtained key and the initialization vector (IV) transmitted along with the encrypted data, the ciphertext is decrypted according to AES-256-CBC mode and PKCS5Padding scheme. Successful decryption yields the original plaintext string.

[0060] Triple parsing: The decrypted plaintext string is segmented according to a preset field separator (such as an ASCII unit separator), and the Unified Social Credit Code (Unified_Credit_Code), Platform ID (Platform_ID), and Timestamp (Timestamp) are extracted in sequence to restore the core triple of the login session.

[0061] 3. Timestamp Validity Verification: The service converts the decrypted timestamp string (ISO 8601 format) into an Instant object and compares it with the server's current time (Instant.now()). It calculates the time difference (Duration) and checks if this difference is less than or equal to the predefined QR code validity period in the configuration file (e.g., 300 seconds). If the time difference is negative or exceeds the validity period, an InvalidSessionException is immediately thrown, the process terminates, and the client is returned an error message: "QR code expired."

[0062] 4. Dual verification of identity and binding relationship: Enterprise Identity Verification: The service uses the decrypted Unified Social Credit Code of the enterprise as a query condition to call the enterprise information service or directly query the enterprise's core database to verify whether the enterprise truly exists and whether the account status is normal (e.g., not cancelled or disabled). If the query fails or the status is abnormal, an error message indicating invalid enterprise identity is returned.

[0063] Scene binding relationship verification: The service verifies the legality of the binding relationship based on the decrypted scene identifier and the device / platform information carried in the request. Specific logic includes: For online B / S scenarios, verify whether the scenario identifier (such as B2B_WEB_001) is in the system's list of allowed Web platform identifiers, and further verify whether the request source IP or domain name is in the whitelist.

[0064] For offline C / S scenarios, verify whether the barcode scanner device identifier corresponding to the scenario identifier (such as SG_OFFLINE_001) matches the barcode scanner SN number contained in the deviceInfo in the request, and whether the barcode scanner is marked as authorized and available in the system.

[0065] 5. Token Issuance and Return: After all verifications pass, the service invokes the internal or unified token issuance service.

[0066] First, a temporary access token (Token1) is generated using the JWT standard. This token contains the user's basic identity identifier, the company they belong to, and the scope of permissions they are granted. The token has a short validity period (e.g., 2 minutes).

[0067] Subsequently, the service uses this Token1 as a credential to call the interface of the central single sign-on (SSO) authentication center in exchange for a one-time authorization code.

[0068] Finally, the service carries this authorization code to call the pre-authorization interface of the User Authentication System (UAS) to request and obtain the final official login token (Token2). Token2 also uses the JWT format, but has a longer validity period that can be dynamically set according to the scenario (e.g., 8 hours online, 2 hours offline) and contains complete user session information.

[0069] The service encapsulates the generated official Token2, refresh token, and basic user information into a response body and returns it to the frontend requester via HTTPS, thereby establishing a secure authentication session. Simultaneously, the backend updates the corresponding triplet session status in the database to "login" and records the login time.

[0070] In one embodiment of the present invention, based on step S5, a possible embodiment will be given below, and its specific implementation will be described in a non-limiting manner.

[0071] 1. Session state encapsulation and real-time WebSocket push State object encapsulation: After the authentication microservice successfully issues the official login token (Token2), the backend service (such as SessionSyncService) encapsulates the Token2, the corresponding user's unique identifier (such as User ID), the core permission list, the affiliated enterprise information, and the token's validity period into a structured session state object. This object is typically defined as a JSON object containing fields such as token, userId, enterpriseCode, authorities, and expiresAt.

[0072] WebSocket Channel Push: The system maintains an established WebSocket long-lived connection pool for each associated business system (such as ERP, CRM, etc.). After encapsulation, SessionSyncService queries the list of all associated business systems authorized for access by the enterprise based on the unified social credit code obtained during the decryption and verification phase. Subsequently, the service actively pushes the aforementioned session state object as a message frame to the backend service endpoint of each business system in the list in real time through the corresponding WebSocket connection. The push process adopts a publish / subscribe (Pub / Sub) pattern to ensure reliable message delivery.

[0073] 2. Synchronization of reception and distributed cache in related business systems State reception and verification: After receiving the pushed session state object, the WebSocket client service deployed in the backend of each related business system first performs a quick verification of the signature of Token2 and checks its basic validity.

[0074] Storage to a shared Redis cache: After successful authentication, the business system uses the user's identity identifier (such as userId) and the unique identifier of this login session (such as Session ID) to generate a globally unique cache key, for example, in the format SESSION:{enterpriseCode}:{userId}:{sessionId}. Subsequently, the session state object is serialized into a string and stored in a shared Redis distributed cache cluster.

[0075] Configure a cache expiration policy: Set the expiration time (TTL) for the cache key to be strictly aligned with the expiration date of Token2, with a small buffer period (such as an additional 5 minutes). This ensures that cached data does not expire before the token itself, thereby enabling lifecycle management of session state.

[0076] 3. Cross-system state sharing and seamless access authentication Unified status query interface: When each associated B / S or C / S business system (whether it is a web front-end or a desktop client) needs to verify the user's login status, it no longer relies solely on local sessions or repeatedly calls the authentication center, but instead calls a unified session status query service.

[0077] Cache verification process: This query service uses the Token2 or user identifier carried in the current request as input, generates a cache key according to the same rules, and initiates a query to the shared Redis cluster. If a valid and unexpired session state object is found, it indicates that the user has completed authentication in one of the systems, and their login status is globally valid.

[0078] Implementing Single Sign-On (SSO): Through the above mechanism, when a user logs in to business system A, their status is synchronized to the Redis cache in real time. When the user subsequently accesses business system B, system B can immediately identify their logged-in status by querying the same Redis cache and automatically establish a local session context for them, eliminating the need for the user to repeatedly enter credentials. This solution effectively achieves a seamless user experience across different technical architectures (B / S and C / S) and different business systems, enabling a single login to work everywhere.

[0079] In some embodiments, the QR code-based secure login system may include multiple functional modules composed of computer program segments. The computer programs for each program segment in the QR code-based secure login system may be stored in the memory of a computer device and executed by at least one processor to perform (see details). Figure 1 (Description) The function of secure login based on QR code.

[0080] In this embodiment, the QR code-based secure login system can be divided into multiple functional modules according to its functions, such as... Figure 2 As shown. The module referred to in this invention is a series of computer program segments that can be executed by at least one processor and perform a fixed function, and is stored in memory. In this embodiment, the functions of each module will be described in detail in subsequent embodiments.

[0081] The dynamic generation module is used to generate a triplet containing the enterprise's unique identity information, scenario identifier, and timestamp based on the login scenario, and to encrypt the triplet to generate a dynamic encrypted QR code. The user scanning module is used by the user to scan the QR code through a mobile device, or by a barcode scanner to scan the QR code displayed on the user's mobile device in a C / S scenario. The front-end parsing module is used to parse the encrypted data in the QR code, automatically determine the login scenario based on the scenario identifier, and send the encrypted data and scenario type to the back-end authentication interface. The backend decryption module is used by the backend to decrypt encrypted data and verify the validity of timestamps, verify the enterprise identity and the binding relationship of the scenario, and issue a login token after successful verification. The login sharing module is used by the backend to push the login status and token to the associated business system via WebSocket. Each system synchronizes the user session to the distributed cache to achieve single sign-on.

[0082] Figure 3 The QR code-based secure login method provided in this application embodiment can be applied to devices. Those skilled in the art will understand that the device structure involved in the embodiments of this invention does not constitute a limitation on the device. A device may include more or fewer components than illustrated, or combine certain components, or have different component arrangements. In the embodiments of this invention, the device includes, but is not limited to, laptop computers, desktop computers, workstations, personal digital assistants, servers, blade servers, mainframe computers, and other suitable computers. The device may also represent various forms of mobile devices, such as personal digital processors, cellular phones, smartphones, wearable devices, and other similar computing devices. The components shown herein, their connections and relationships, and their functions are merely examples and are not intended to limit the implementation of the embodiments of this application described and / or claimed herein.

[0083] The device 300 may include a processor 310, a memory 320, and a communication unit 330. These components communicate via one or more buses. Those skilled in the art will understand that the server structure shown in the figure does not constitute a limitation of the present invention. It may be a bus topology or a star topology, and may include more or fewer components than shown, or combine certain components, or have different component arrangements.

[0084] The memory 320 can be used to store execution instructions of the processor 310. The memory 320 can be implemented by any type of volatile or non-volatile storage device or a combination thereof, such as static random access memory (SRAM), electrically erasable programmable read-only memory (EEPROM), erasable programmable read-only memory (EPROM), programmable read-only memory (PROM), read-only memory (ROM), magnetic storage, flash memory, magnetic disk, or optical disk. When the execution instructions in the memory 320 are executed by the processor 310, the device 300 is able to perform some or all of the steps in the above method embodiments.

[0085] The processor 310 serves as the control center of the storage device, connecting various parts of the electronic device via various interfaces and lines. It executes software programs and / or modules stored in the memory 320, and calls data stored in the memory to perform various functions of the electronic device and / or process data. The processor can be composed of integrated circuits (ICs), such as a single packaged IC or multiple packaged ICs with the same or different functions connected together. For example, the processor 310 may consist only of a central processing unit (CPU). In this embodiment of the invention, the CPU may have a single processing core or include multiple processing cores.

[0086] The communication unit 330 is used to establish a communication channel, enabling the storage device to communicate with other devices. It can receive user data sent by other devices or send user data to other devices.

[0087] The present invention also provides a computer storage medium, wherein the computer storage medium may store a program, which, when executed, may include some or all of the steps provided in the embodiments of the present invention. The storage medium may be a magnetic disk, an optical disk, read-only memory (ROM), or random access memory (RAM), etc.

[0088] Those skilled in the art will clearly understand that the techniques in the embodiments of the present invention can be implemented using software plus necessary general-purpose hardware platforms. Based on this understanding, the technical solutions in the embodiments of the present invention, or the parts that contribute to the prior art, can be embodied in the form of a software product. This computer software product is stored in a storage medium such as a USB flash drive, a portable hard drive, a read-only memory (ROM), a random access memory (RAM), a magnetic disk, or an optical disk, or any other medium capable of storing program code. It includes several instructions to cause a computer device (which may be a personal computer, a server, or a second device, network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of the present invention.

[0089] The same or similar parts between the various embodiments in this specification can be referred to mutually. In particular, the device embodiments are basically similar to the method embodiments, so the description is relatively simple, and the relevant parts can be referred to the description in the method embodiments.

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

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

[0092] In addition, the functional modules in the various embodiments of the present invention can be integrated into one processing module, or each module can exist physically separately, or two or more modules can be integrated into one module.

[0093] Although the present invention has been described in detail with reference to the accompanying drawings and preferred embodiments, the present invention is not limited thereto. Various equivalent modifications or substitutions can be made to the embodiments of the present invention by those skilled in the art without departing from the spirit and essence of the invention, and such modifications or substitutions should all be within the scope of the present invention. Any variations or substitutions that can be easily conceived by those skilled in the art within the technical scope disclosed in the present invention should also be covered within the protection scope of the present invention.

Claims

1. A secure login method based on QR codes, characterized in that, include: Based on the login scenario, a triplet containing the enterprise's unique identity information, scenario identifier, and timestamp is generated, and the triplet is encrypted to generate a dynamic encrypted QR code. Users can scan the QR code using their mobile devices, or in a C / S scenario, a barcode scanner can scan the QR code displayed on the user's mobile device. The front-end parses the encrypted data in the QR code, automatically determines the login scenario based on the scenario identifier, and sends the encrypted data and scenario type to the back-end authentication interface; The backend decrypts the encrypted data and verifies the validity of the timestamp, verifies the enterprise identity and the binding relationship with the scenario, and issues a login token after the verification is successful. The backend pushes the login status and token to the associated business systems via WebSocket, and each system synchronizes the user session to the distributed cache to achieve single sign-on.

2. The method according to claim 1, characterized in that, Based on the login scenario, a triplet containing the enterprise's unique identity information, scenario identifier, and timestamp is generated. This triplet is then encrypted to generate a dynamically encrypted QR code, including: The enterprise's unified social credit code, the scenario identifier assigned according to the login scenario, and the unique timestamp generated by the system are bound together to form a triplet, and the triplet is stored in the database as a one-time login session; The triple is concatenated with the company name, industry classification code, and random number to form the plaintext data to be encrypted; The plaintext data is encrypted using the AES-256-CBC algorithm, and the encryption key is dynamically generated and rotated by the system at a configurable period. The data before encryption is processed together with the encrypted data using the HMAC-SHA256 algorithm to generate a message authentication code. The encrypted ciphertext data is encoded into a QR code image, which is time-sensitive and for one-time use only.

3. The method according to claim 1, characterized in that, Users scan the QR code via mobile devices, or in a C / S scenario, a barcode scanner scans the QR code displayed on the user's mobile device, including: The dynamic encrypted QR code is displayed adaptively on different terminal interfaces according to the login scenario, including: the user page of the B / S system, the user page of the mobile official account or mini program, the C / S client interface or multimedia touch screen. In the online B / S login scenario, users use an application on their mobile devices to scan the QR code displayed on the webpage; in the offline C / S login scenario, users display their saved personal QR code on their mobile devices, which is then scanned by a barcode scanner on the on-site equipment. After the scanning device acquires the QR code image, the front-end application extracts the encrypted data by integrating a QR code parsing plugin. Based on the scene identifier and scanning device type in the data, it automatically determines whether the current scenario is an online B / S scenario or an offline C / S scenario.

4. The method according to claim 1, characterized in that, The front-end parses the encrypted data in the QR code, automatically determines the login scenario based on the scenario identifier, and sends the encrypted data and scenario type to the back-end authentication interface, including: The front-end application decodes the scanned QR code image using an integrated QR code parsing component to extract the encrypted data string contained therein; The front end parses the preset scene identifier field in the encrypted data and, in conjunction with the obtained scanning device type information, automatically determines whether the current login scenario belongs to an online B / S scenario or an offline C / S scenario; wherein the device type information is obtained by parsing the User-Agent field in the HTTP request header or the barcode scanner device driver information; The front end encapsulates the encrypted data, the identified scene type, the device identification information, and the current timestamp into a structured JSON request body; The front end uses the HTTP protocol and encrypted communication to send the JSON request body to the unified microservice authentication interface of the back end for subsequent decryption and authentication.

5. The method according to claim 4, characterized in that, The front-end encapsulates the encrypted data, the identified scene type, device identification information, and the current timestamp into a structured JSON request body, including: Construct a structured JSON object as the request body, which must contain at least the following predefined fields: encryptedData: The field value is the encrypted data string obtained through parsing; sceneType: The field value is the identified scene type, used to identify online B / S or offline C / S login scene; deviceIdentifier: The field value is the identification information of the scanning device; clientTimestamp: The field value is the current timestamp generated by the frontend when the request was initiated; The field structure and field names of the JSON object are predefined by the front-end and back-end protocols to ensure the consistency and parsability of data transmission.

6. The method according to claim 1, characterized in that, The backend decrypts the encrypted data and verifies the timestamp validity, confirms the enterprise identity and scenario binding relationship, and issues a login token upon successful verification, including: The backend microservice uses the key corresponding to the encryption to perform AES-256-CBC decryption on the received encrypted data, restoring the original triplet information containing the enterprise's unified social credit code, scenario identifier, and timestamp; The timestamp obtained from decryption is compared with the server's current time to determine if it is within a preset valid time window; if it exceeds the window, the authentication process is terminated and a timeout error is returned. The database is queried based on the decrypted unified social credit code of the enterprise to verify the existence status and legality of the corresponding enterprise user; the authorization binding relationship between the decrypted scenario identifier and the device or platform that initiated the authentication request is valid is verified based on the decrypted scenario identifier. After all verifications are successful, the token issuance service is invoked to generate a formal login token, which is then returned to the requester to establish an authentication session.

7. The method according to claim 1, characterized in that, The backend pushes the login status and token to related business systems via WebSocket, and each system synchronizes the user session to a distributed cache to achieve single sign-on, including: The backend service encapsulates the issued official login token, the corresponding user identity identifier and permission information into a unified session state object, and pushes it in real time to all related business systems that the enterprise user has the right to access through the established WebSocket long connection channel; After receiving the session state object, each related business system stores it in a shared Redis distributed cache and sets a cache expiration time for the session that corresponds to the token's validity period. When a user accesses or switches between any associated B / S or C / S business systems, the system retrieves and verifies the user's login status by querying the Redis distributed cache, thereby achieving single sign-on and session sharing across systems and architectures.

8. A secure login system based on QR codes, characterized in that, include: The dynamic generation module is used to generate a triplet containing the enterprise's unique identity information, scenario identifier, and timestamp based on the login scenario, and to encrypt the triplet to generate a dynamic encrypted QR code. The user scanning module is used by the user to scan the QR code through a mobile device, or by a barcode scanner to scan the QR code displayed on the user's mobile device in a C / S scenario. The front-end parsing module is used to parse the encrypted data in the QR code, automatically determine the login scenario based on the scenario identifier, and send the encrypted data and scenario type to the back-end authentication interface. The backend decryption module is used by the backend to decrypt encrypted data and verify the validity of timestamps, verify the enterprise identity and the binding relationship of the scenario, and issue a login token after successful verification. The login sharing module is used by the backend to push the login status and token to the associated business system via WebSocket. Each system synchronizes the user session to the distributed cache to achieve single sign-on.

9. A secure login device based on QR codes, characterized in that, include: Memory for storing QR code-based secure login procedures; A processor, configured to implement the steps of the QR code-based secure login method as described in any one of claims 1-7 when executing the QR code-based secure login program.

10. A computer-readable storage medium storing a computer program, characterized in that, The readable storage medium stores a QR code-based secure login program, which, when executed by a processor, implements the steps of the QR code-based secure login method as described in any one of claims 1-7.

Images