HTTP Token authentication method and device based on national secret, equipment and storage medium

Abstract

The invention provides an HTTP (Hyper Text Transport Protocol) Token authentication method, device and equipment based on national secret, and a storage medium. The method comprises the following steps: a server receives a Token verification request; performing SM4 encryption on the request identifier by using a secret key formed by a current hour time character string and a specific character string to obtain a first encrypted identifier, and performing Base64 coding to obtain a second encrypted identifier; the current hour time character string SM4 is encrypted by the same key to obtain first encryption time, and Base64 coding is carried out to obtain second encryption time; splicing the request identifier with the current hour time character string, performing MD5 hash operation to obtain a first test value, and performing Base64 coding to obtain a second test value; and finally, splicing the second encryption identifier, the second encryption time and the second check value to obtain the Token. According to the invention, the dynamic change of the Token accessed each time can be realized, the Token is prevented from being copied and counterfeited, and the security and reliability of the HTTP request are improved.

Description

Technical Field

[0001] The present invention relates to the field of information security technology, and more specifically, to a national secret-based HTTP Token authentication method, apparatus, device, and storage medium. Background Art

[0002] The existing HTTP Token authentication methods mainly include JWT Token verification, OAuth2.0 Token verification and APIKEY Token verification. JWT Token verification consists of three parts: Header, Payload and Signature. The Header describes the metadata of the JWT, the Payload stores the actual data to be transmitted, and the Signature is generated by the server using a specified algorithm through the Payload, Header and key. However, the disadvantage of JWT Token verification is that the signature will not change over a period of time, resulting in a third party being able to forge HTTP requests by copying the signature even if they do not know the signature content. OAuth2.0 Token verification relies on a third-party authentication service and requires user information on other applications, which makes it unusable on some stand-alone devices. APIKEY Token verification is that the access end first applies for a key from the service and then passes the key as a parameter. The main disadvantage of this method is that the key is easily exposed and there are security issues.

[0003] In the process of implementing the embodiments of the present invention, the inventors found that there are at least the following problems or defects in the existing technology: the existing token verification methods either have security issues, such as JWT token verification signatures are easy to copy and forge, and APIKEY token verification keys are easy to expose; or rely on third-party applications, such as OAuth2.0 token verification, which is not available on stand-alone devices and cannot meet the requirements for HTTP token authentication security, independence and applicability in different scenarios. Summary of the Invention

[0004] The present invention provides a national secret-based HTTP Token authentication method, device, equipment and storage medium.

[0005] In a first aspect of the present invention, a method for HTTP Token authentication based on national encryption is provided, comprising:

[0006] The server receives the verification token request;

[0007] The server encrypts the request identifier using the SM4 algorithm based on the national encryption algorithm, using a key consisting of the current hour time string and a specific string to obtain a first encrypted identifier.

[0008] Perform Base64 encoding on the first encryption identifier to obtain a second encryption identifier;

[0009] The server performs SM4 encryption on the current hour time string using a key composed of the current hour time string and a specific string based on the national secret SM4 algorithm to obtain the first encrypted time;

[0010] Perform Base64 encoding on the first encrypted time to obtain a second encrypted time;

[0011] Concatenate the request identifier with the current hour time string to obtain the content to be checked;

[0012] Performing an MD5 hash operation on the content to be checked to obtain a first check value;

[0013] Perform Base64 encoding on the first check value to obtain a second check value;

[0014] The second encryption identifier, the second encryption time and the second verification value are concatenated to obtain a Token.

[0015] Furthermore, the request identifier is a session name or a user name.

[0016] Furthermore, the current hour time character string format is YYYY-MM-DD HH:00, where YYYY represents year, MM represents month, DD represents day, and HH represents hour.

[0017] Further, including:

[0018] Request receiving module, used to receive verification Token request;

[0019] An identification encryption module, configured to execute the request identification encryption step described in claim 1;

[0020] A time encryption module, configured to execute the step of encrypting the current hour time character string as recited in claim 1;

[0021] A test value generating module, configured to execute the steps of generating content to be tested and calculating a test value as described in claim 1;

[0022] The Token generation module is used to execute the Token splicing step described in claim 1.

[0023] Furthermore, the request identifier is a session name or a user name.

[0024] Furthermore, the current hour time character string format is YYYY-MM-DD HH:00, where YYYY represents year, MM represents month, DD represents day, and HH represents hour.

[0025] In a second aspect of the present invention, there is provided an HTTP Token authentication device based on national encryption, comprising:

[0026] A receiving unit, configured to receive a verification Token request;

[0027] An encryption unit, configured to perform the encryption step described in claim 1;

[0028] A test unit, configured to execute the test value generating step described in claim 1;

[0029] A splicing unit, configured to execute the Token splicing step described in claim 1.

[0030] Furthermore, the request identifier is a session name or a user name, and the current hour time character string format is YYYY-MM-DD HH:00, where YYYY represents year, MM represents month, DD represents day, and HH represents hour.

[0031] In a third aspect of the present invention, an electronic device is provided, comprising: at least one processor, a memory, and an input / output unit; wherein the memory is used to store a computer program, and the processor is used to call the computer program stored in the memory to execute any one of the methods described in the first aspect.

[0032] In a fourth aspect of the present invention, a computer-readable storage medium is provided, comprising instructions, which, when executed on a computer, enable the computer to execute the method according to any one of the first aspects.

[0033] According to the above-mentioned embodiment of the present invention, there are at least the following beneficial effects: the present invention first encrypts the request identifier and the current hour time string by using the national secret SM4 algorithm in combination with a key consisting of the current hour time string and a specific string, and then performs Base64 encoding, and performs MD5 hash operation on the spliced request identifier and the current hour time string and Base64 encoding to generate a check value, and finally splices these encrypted and encoded results into a Token, which can realize the dynamic change of the Token at each access. Even in a short period of time, the Token of the same user or session will be different due to changes in time, thereby effectively preventing the Token from being copied and forged, and greatly improving the security of the HTTP request. Secondly, the method does not rely on third-party applications for identity authentication, and key information such as keys and encryption algorithms are not easily exposed. It can independently realize safe and reliable HTTP Token authentication in various scenarios, including stand-alone devices, etc. It has a wide range of applicability and can better meet the information security needs of different users and applications. BRIEF DESCRIPTION OF THE DRAWINGS

[0034] The above and other objects, features and advantages of the exemplary embodiments of the present invention will become readily apparent by reading the following detailed description with reference to the accompanying drawings, in which several embodiments of the present invention are shown by way of example and not limitation, in which:

[0035] Figure 1 A schematic diagram of the structure of an HTTP Token authentication device based on national encryption provided by an embodiment of the present invention;

[0036] Figure 2 A flowchart of a national secret-based HTTP Token authentication method provided in one embodiment of the present invention;

[0037] Figure 3 The figure schematically shows the structure of an electronic device according to an embodiment of the present invention. DETAILED DESCRIPTION

[0038] The principles and spirit of the present invention will be described below with reference to several exemplary embodiments. It should be understood that these embodiments are provided solely to enable those skilled in the art to better understand and implement the present invention, and are not intended to limit the scope of the present invention in any way. Rather, these embodiments are provided to make the present invention more thorough and complete, and to fully convey the scope of the present invention to those skilled in the art.

[0039] Those skilled in the art will appreciate that the embodiments of the present invention may be implemented as a system, apparatus, device, method, or computer program product. Therefore, the present invention may be implemented in the following forms: entirely in hardware, entirely in software (including firmware, resident software, microcode, etc.), or in a combination of hardware and software.

[0040] It should be noted that any number of elements in the drawings is for illustration only and not for limitation, and any naming is only for distinction and does not have any limiting meaning.

[0041] An HTTP Token authentication method based on national encryption includes:

[0042] The server receives the verification token request;

[0043] The server encrypts the request identifier using the SM4 algorithm based on the national encryption algorithm, using a key consisting of the current hour time string and a specific string to obtain a first encrypted identifier.

[0044] Perform Base64 encoding on the first encryption identifier to obtain a second encryption identifier;

[0045] The server performs SM4 encryption on the current hour time string using a key composed of the current hour time string and a specific string based on the national secret SM4 algorithm to obtain the first encrypted time;

[0046] Perform Base64 encoding on the first encrypted time to obtain a second encrypted time;

[0047] Concatenate the request identifier with the current hour time string to obtain the content to be checked;

[0048] Performing an MD5 hash operation on the content to be checked to obtain a first check value;

[0049] Base64-encode the first check value to obtain a second check value;

[0050] The second encryption identifier, the second encryption time and the second verification value are concatenated to obtain a Token.

[0051] Reference below Figure 1 The server receives a request for a verification token, marking the beginning of the authentication process. In HTTP communication, when a client initiates a request, it includes a token for the server to verify its legitimacy. A token is an encrypted string used to transmit authentication information between the client and the server, representing a user's identity or permissions. Upon receiving the request, the server performs a series of verification operations on the token to ensure the legitimacy of the request source and the security of the data.

[0052] like Figure 2 As shown, the server performs SM4 encryption on the request identifier using the National Encryption SM4 algorithm, using a key consisting of the current hourly time string and a specific string to generate the first encrypted identifier. The National Encryption SM4 algorithm is a block cipher with high security and efficiency, making it suitable for data encryption. The current hourly time string refers to the current time when the server receives the request, accurate to the hour, for example, 2024-10-10 12:00. This time format facilitates the generation of time-sensitive tokens.

[0053] More specifically, the specific string can be a pre-set key used to enhance encryption complexity and security. The request identifier is typically a session name or user name, which identifies the subject initiating the request. It can be a session identifier after the user logs in, or a unique name of the user.

[0054] Preferably, the first encryption identifier is Base64-encoded to obtain a second encryption identifier. Base64 encoding is an encoding method that converts binary data into an ASCII string, which can convert the encrypted data into a format suitable for transmission on the network. The advantage of doing this is that it can ensure that the Token will not cause parsing errors or transmission failures due to special characters during transmission. At the same time, the server uses the same key to perform SM4 encryption on the current hour time string based on the national secret SM4 algorithm to obtain the first encrypted time, and then performs Base64 encoding to obtain the second encrypted time. In this way, the Token contains both the encrypted request identifier and the encrypted time information, which further enhances the security and timeliness of the Token.

[0055] In some embodiments, the request identifier is a session name or a user name.

[0056] It's important to note that the request identifier is a session name or user name, which is a specific definition of the request identifier in token authentication methods. In the HTTP token authentication system, the request identifier is key information used to uniquely identify the client or user initiating the request. The session name is typically a unique identifier generated and assigned to the user by the server after the user logs in to the system. It is used to maintain the user's login status and session information. The user name is the user's registered account name in the system and is used to identify the user.

[0057] Specifically, the session name can be a random string generated by the server, such as sess_1234567890. It is created when a user logs in and remains unchanged throughout the user session. The user name, such as user123, is provided by the user during registration and serves as a unique identifier for the user within the system. Both request identifiers can serve as key input parameters in the token generation process to generate unique tokens. In actual applications, you can choose to use either the session name or the user name as the request identifier based on the system's security requirements and business scenarios.

[0058] In addition to the session name and username, other user-identity attributes can also be considered as request identifiers, such as the user's email address or mobile phone number. These attributes can also uniquely identify the user and, in some scenarios, may be more stable and secure than the session name or username. For example, in a highly secure financial system, using the user's email address as the request identifier may be more appropriate, as the email address is typically closely tied to the user's real-name identity and is difficult to tamper with.

[0059] Furthermore, in order to further enhance the security of the Token, the request identifier can be combined with some dynamic factors (such as timestamps, random numbers, etc.) when generating the Token to generate a more complex and unpredictable Token.

[0060] In some embodiments, the current hour time string format is YYYY-MM-DDHH:00, where YYYY represents year, MM represents month, DD represents day, and HH represents hour.

[0061] It should be noted that the current hourly time string format is YYYY-MM-DD HH:00, where YYYY represents the year, MM represents the month, DD represents the day, and HH represents the hour. This specifies the time string format used in token authentication methods. In HTTP token authentication, the time string is a critical parameter, ensuring the timeliness and uniqueness of the token. By ensuring the time is accurate to the hour and using a unified format, server-side token verification and management are facilitated.

[0062] Specifically, a time string in the format of YYYY-MM-DD HH:00 provides a standardized way to represent time. For example, 2024-10-10 12:00 represents 12:00 noon on October 10, 2024. The advantage of this format is that it is concise and easy to parse. The server can easily extract the time information from the token and compare it with the current time to determine whether the token is within its validity period. Furthermore, this format facilitates synchronization and exchange of time and tokens across different systems and platforms.

[0063] Preferably, to further improve the security and tamper resistance of the token, more details, such as minutes or seconds, can be added to the time string. For example, the time string format can be changed to YYYY-MM-DD HH:MM:SS. This can provide a more accurate timestamp, making each token more unique in terms of time.

[0064] Furthermore, to prevent malicious replay of the token, a random number or serial number can be added to the time string. This way, even within the same time period, different requests will generate different tokens. For example, 2024-10-10 12:00:00-123456, where 123456 is a randomly generated serial number, further enhances the security of the token.

[0065] In some embodiments, including:

[0066] Request receiving module, used to receive verification Token request;

[0067] An identification encryption module, configured to execute the request identification encryption step described in claim 1;

[0068] A time encryption module, configured to execute the step of encrypting the current hour time character string as recited in claim 1;

[0069] A test value generating module, configured to execute the steps of generating content to be tested and calculating a test value as described in claim 1;

[0070] The Token generation module is used to execute the Token splicing step described in claim 1.

[0071] It should be noted that an HTTP Token authentication system based on national security standards comprises a request reception module, an identity encryption module, a time encryption module, a check value generation module, and a token generation module. These modules work together to complete the token generation and verification process. This system is designed to provide a secure, efficient, and nationally compliant authentication mechanism to protect the security of HTTP requests. Through its modular design, the system can more flexibly address diverse security requirements and application scenarios.

[0072] Specifically, the request receiving module is responsible for receiving HTTP requests sent by the client, which contain tokens that need to be verified. The identification encryption module uses the national secret SM4 algorithm to encrypt the request identification, which can be a session name or user name. The time encryption module also uses the national secret SM4 algorithm to encrypt the current hour time string. The format of the time string is YYYY-MM-DD HH:00. The check value generation module performs MD5 hash operation on the concatenated request identification and time string, and performs Base64 encoding to generate a check value. Finally, the token generation module concatenates the encrypted identification, time and check value into the final token.

[0073] To improve system security and reliability, more encryption parameters can be introduced into the identity encryption module and the time encryption module, such as using different keys or encryption modes. Furthermore, the verification value generation module can employ more complex hash algorithms or add additional verification steps, such as digital signatures, to enhance the token's tamper resistance.

[0074] Furthermore, in the token generation module, you can consider adding an expiration time field so that the token automatically expires after a certain period of time, further improving security. For example, you can add a field called exp to the token to indicate the token's expiration time in the format of YYYY-MM-DD HH:MM:SS. This way, when the server verifies the token, it can not only check the legitimacy of the token, but also check whether it has expired.

[0075] In some embodiments, the request identifier is a session name or a user name.

[0076] It's important to note that in the HTTP Token authentication system based on national security, the request identifier is explicitly designated as the session name or user name. This setting provides a clear identity during the token generation and verification process. The session name is typically a unique identifier generated and assigned to the user by the server after logging into the system. It is used to maintain the user's login status and session information. The user name is the user's registered account name in the system and is used to identify the user. By using these two identifiers, the system can accurately identify and verify the user or session initiating the request.

[0077] Specifically, the session name can be a random string generated by the server, such as sess_1234567890, which is created when the user logs in and remains unchanged during the user session. The user name is provided by the user when registering, such as user123, which is the user's unique identifier in the system.

[0078] More specifically, in system implementation, these identifiers can be managed through configuration files or databases to ensure that each user or session has a unique identifier. For example, when a user logs in, the system can store the generated session name in the user's session storage and extract the session name from the request for verification each time a request is made.

[0079] In addition to using session names and user names as request identifiers, the system can also support other types of identity identifiers, such as API keys or device identifiers. These identifiers can be selected based on different application scenarios and security requirements. For example, in API services, API keys can be used as request identifiers to verify the identity of the caller. In IoT scenarios, device identifiers can be used as request identifiers to identify and authenticate devices connected to the network.

[0080] Furthermore, in order to improve the flexibility and scalability of the system, an identification management module can be implemented in the system, which is responsible for generating, allocating and verifying various types of request identifications, thereby supporting multiple authentication mechanisms.

[0081] In some embodiments, the current hour time string format is YYYY-MM-DDHH:00, where YYYY represents year, MM represents month, DD represents day, and HH represents hour.

[0082] It's important to note that in the national security-based HTTP Token authentication system, the current hourly time string format is specified as YYYY-MM-DD HH:00. This format ensures that token generation has a clear time reference, thereby enhancing token timeliness and security. Time string formatting is a crucial step in the token generation process, as it allows the token to be associated with a specific time period, facilitating server-side validation of its validity and timeliness.

[0083] Specifically, a time string in the format of YYYY-MM-DD HH:00 provides a standardized way to represent time, where YYYY represents the four-digit year, MM represents the two-digit month, DD represents the two-digit day, and HH represents the two-digit hour. For example, 2024-10-10 12:00 represents 12:00 noon on October 10, 2024. The advantage of this format is that it is concise and easy to parse. The server can easily extract time information from the token and compare it with the current time to determine whether the token is within its validity period. Furthermore, this format facilitates synchronization and exchange of time and tokens across different systems and platforms.

[0084] Preferably, to further improve the time accuracy and security of the token, more details, such as minutes or seconds, can be added to the time string. For example, the time string format can be changed to YYYY-MM-DD HH:MM:SS. This provides a more accurate timestamp, making each token more unique in terms of time.

[0085] Furthermore, to prevent malicious token replay, a random number or serial number can be added to the time string. This way, even within the same timeframe, different requests will generate different tokens. For example, 2024-10-10 12:00:00-123456, where 123456 is a randomly generated serial number, further enhances token security. Furthermore, the system can set a time window, for example, allowing tokens to be valid for a certain number of minutes before or after the generation time, to mitigate issues such as network latency or clock skew.

[0086] The above-mentioned various embodiments of the present invention have the following beneficial effects: The present invention provides a HTTPToken authentication method based on national secrets, which can utilize the national secret SM4 algorithm and Base64 encoding, combined with a key consisting of the current hour time string and a specific string, to encrypt the request identifier and the current hour time string, and then generate a check value through MD5 hash operation and Base64 encoding, and finally splice the encrypted identifier, encryption time and check value into a Token. This method can make the Token generated each time a visit unique and timely, because the generation of the Token depends on the current hour time, and the Tokens generated at different times must be different, thereby effectively preventing the Token from being maliciously copied and replayed, and enhancing the security of the HTTP request. At the same time, the check value generated by the MD5 hash operation can further verify the integrity and legitimacy of the Token, ensuring that the Token has not been tampered with during transmission, and improving the reliability of authentication.

[0087] The present invention also clarifies that the request identifier can be a session name or a user name, as well as the specific format of the current hour time string. These limitations make the generation of Tokens more flexible and standardized, and appropriate request identifiers can be selected according to different application scenarios, such as using user names in user login scenarios and using session names in session management scenarios. At the same time, the unified time string format facilitates the server to parse and verify the Token, ensuring the consistency and accuracy of the Token generation and verification process. In addition, through modular design, such as the request receiving module, the identifier encryption module, the time encryption module, the check value generation module and the Token generation module, the maintainability and scalability of the system can be improved, and each module can be easily optimized and upgraded independently, further improving the performance and stability of the HTTP Token authentication system based on national encryption.

[0088] like Figure 2 As shown, in some embodiments, an HTTP Token authentication device based on national encryption includes:

[0089] A receiving unit, configured to receive a verification Token request;

[0090] An encryption unit, configured to perform the encryption step described in claim 1;

[0091] A test unit, configured to execute the test value generating step described in claim 1;

[0092] A splicing unit, configured to execute the Token splicing step described in claim 1.

[0093] It is understandable that the modules and references in the HTTP Token authentication device based on national secrets are Figure 1 Therefore, the operations, features and beneficial effects described above for the HTTP Token authentication method based on national secrets are also applicable to the HTTP Token authentication device based on national secrets and the modules contained therein, and will not be repeated here.

[0094] In some embodiments, the request identifier is a session name or a user name, and the current hour time string format is YYYY-MM-DD HH:00, where YYYY represents year, MM represents month, DD represents day, and HH represents hour.

[0095] It should be noted that in the HTTP Token authentication device based on national security, the request identifier is clearly defined as the session name or user name, and the current hour time string format is YYYY-MM-DD HH:00. This regulation is intended to provide a clear identity identifier and time reference during the token generation and verification process, thereby enhancing the timeliness and security of the token. The session name is a unique identifier generated and assigned to the user by the server after the user logs into the system. It is used to maintain the user's login status and session information. The user name is the account name registered by the user in the system and is used to identify the user. The formatting of the time string ensures that the token can be associated with a specific time period, facilitating the server-side verification of validity and timeliness.

[0096] Specifically, the session name can be a random string generated by the server, such as sess_1234567890, which is created when the user logs in and remains unchanged during the user session. The user name is provided by the user when registering, such as user123, which is the user's unique identifier in the system. The time string YYYY-MM-DD HH:00 provides a standardized way to represent time, where YYYY represents the four-digit year, MM represents the two-digit month, DD represents the two-digit day, and HH represents the two-digit hour. For example, 2024-10-10 12:00 means 12:00 noon on October 10, 2024. The advantage of this format is that it is concise and easy to parse. The server can easily extract the time information from the token and compare it with the current time to determine whether the token is within the validity period.

[0097] In addition to using session names and user names as request identifiers, the device can also support other types of identity identifiers, such as API keys or device identifiers. These identifiers can be selected based on different application scenarios and security requirements. For example, in API services, API keys can be used as request identifiers to verify the identity of the caller. In IoT scenarios, device identifiers can be used as request identifiers to identify and authenticate devices connected to the network.

[0098] Furthermore, to improve time accuracy and security, more details, such as minutes or seconds, can be added to the time string. For example, the time string format can be changed to YYYY-MM-DD HH:MM:SS. This provides a more accurate timestamp, making each token more unique in terms of time.

[0099] Furthermore, to prevent malicious replay of the token, a random number or serial number can be added to the time string. This way, even within the same time period, different requests will generate different tokens. For example, 2024-10-10 12:00:00-123456, where 123456 is a randomly generated serial number, further enhances the security of the token.

[0100] Reference below Figure 3 , which shows a schematic structural diagram of an electronic device 300 suitable for implementing some embodiments of the present invention. The electronic devices in some embodiments of the present invention may include, but are not limited to, mobile terminals such as mobile phones, laptop computers, digital broadcast receivers, PDAs (personal digital assistants), PADs (tablet computers), PMPs (portable multimedia players), in-vehicle terminals (e.g., in-vehicle navigation terminals), and fixed terminals such as digital TVs and desktop computers. Figure 3 The terminal device shown is only an example and should not bring any limitation to the functions and scope of use of the embodiments of the present invention.

[0101] like Figure 3 As shown, the electronic device 300 may include a processing device (e.g., a central processing unit, a graphics processing unit, etc.) 301, which can perform various appropriate actions and processes according to a program stored in a read-only memory (ROM) 302 or a program loaded from a storage device 308 into a random access memory (RAM) 303. Various programs and data required for the operation of the electronic device 300 are also stored in the RAM 303. The processing device 301, the ROM 302, and the RAM 303 are connected to each other via a bus 304. An input / output (I / O) interface 305 is also connected to the bus 304.

[0102] Typically, the following devices may be connected to the I / O interface 305: an input device 306 including, for example, a touch screen, a touchpad, a keyboard, a mouse, a camera, a microphone, an accelerometer, a gyroscope, etc.; an output device 307 including, for example, a liquid crystal display (LCD), a speaker, a vibrator, etc.; a storage device 308 including, for example, a magnetic tape, a hard disk, etc.; and a communication device 309. The communication device 309 may allow the electronic device 300 to communicate with other devices wirelessly or by wire to exchange data. Figure 3 The electronic device 300 is shown with various devices, but it should be understood that it is not required to implement or possess all of the devices shown. More or fewer devices may be implemented or possessed instead. Figure 3 Each block shown in the figure may represent one device, or may represent multiple devices as needed.

[0103] Furthermore, the storage medium of the embodiment of the present application stores program instructions that can implement all the above methods, wherein the program instructions can be stored in the above storage medium in the form of a software product, including a number of instructions for causing a computer device (which can be a personal computer, server, or network device, etc.) or a processor to execute all or part of the steps of the method described in each embodiment of the present application. The aforementioned storage medium includes: various media that can store program codes, such as a USB flash drive, a mobile hard disk, a read-only memory (ROM), a random access memory (RAM), a magnetic disk or an optical disk, or a terminal device such as a computer, a server, a mobile phone, or a tablet.

[0104] The above descriptions are merely some preferred embodiments of the present invention and an illustration of the technical principles employed. Those skilled in the art should understand that the scope of the invention involved in the embodiments of the present invention is not limited to the technical solutions formed by a specific combination of the above-mentioned technical features, but should also encompass other technical solutions formed by any combination of the above-mentioned technical features or their equivalents without departing from the above-mentioned inventive concept. For example, a technical solution formed by mutually replacing the above-mentioned features with (but not limited to) technical features having similar functions disclosed in the embodiments of the present invention.

Claims

1. An HTTP Token authentication method based on national secrets, characterized in that: The following steps are involved: The server receives the verification token request; The server encrypts the request identifier using the SM4 algorithm based on the national encryption algorithm, using a key consisting of the current hour time string and a specific string to obtain a first encrypted identifier. Perform Base64 encoding on the first encryption identifier to obtain a second encryption identifier; The server performs SM4 encryption on the current hour time string using a key composed of the current hour time string and a specific string based on the national secret SM4 algorithm to obtain the first encrypted time; Perform Base64 encoding on the first encrypted time to obtain a second encrypted time; Concatenate the request identifier with the current hour time string to obtain the content to be checked; Performing an MD5 hash operation on the content to be checked to obtain a first check value; Perform Base64 encoding on the first check value to obtain a second check value; The second encryption identifier, the second encryption time and the second verification value are concatenated to obtain a Token.

2. The HTTP Token authentication method based on national secrets according to claim 1 is characterized in that: The request identifier is a session name or a user name.

3. The HTTP Token authentication method based on national secrets according to claim 1 is characterized in that: The current hour time string format is "YYYY-MM-DD HH:00", where "YYYY" represents year, "MM" represents month, "DD" represents day, and "HH" represents hour.

4. An HTTP Token authentication system based on national secrets, characterized in that: include: Request receiving module, used to receive verification Token request; An identification encryption module, configured to execute the request identification encryption step described in claim 1; A time encryption module, configured to execute the step of encrypting the current hour time character string as recited in claim 1; A test value generating module, configured to execute the steps of generating content to be tested and calculating a test value as described in claim 1; The Token generation module is used to execute the Token splicing step described in claim 1.

5. The HTTP Token authentication system based on national secrets according to claim 4 is characterized in that: The request identifier is a session name or a user name.

6. The HTTP Token authentication system based on national secrets according to claim 4 is characterized in that: The current hour time string format is "YYYY-MM-DD HH:00", where "YYYY" represents year, "MM" represents month, "DD" represents day, and "HH" represents hour.

7. An HTTP Token authentication device based on national secrets, characterized in that: include: A receiving unit, configured to receive a verification Token request; An encryption unit, configured to perform the encryption step described in claim 1; A test unit, configured to execute the test value generating step described in claim 1; A splicing unit, configured to execute the Token splicing step described in claim 1.

8. The HTTP Token authentication device based on national secrets according to claim 7, characterized in that: The request identifier is a session name or a user name, and the current hour time character string format is "YYYY-MM-DD HH:00", where "YYYY" represents year, "MM" represents month, "DD" represents day, and "HH" represents hour.

9. An electronic device, characterized in that: include: Memory for storing computer programs; A processor, configured to execute the computer program to implement the HTTP Token authentication method based on national encryption as described in any one of claims 1 to 3.

10. A computer-readable storage medium having a computer program stored thereon, characterized in that: When the program is executed by a processor, the HTTP Token authentication method based on national encryption as described in any one of claims 1 to 3 is implemented.

Images