CN115277130A - User silent authorization method - Google Patents

User silent authorization method Download PDF

Info

Publication number
CN115277130A
CN115277130A CN202210824115.7A CN202210824115A CN115277130A CN 115277130 A CN115277130 A CN 115277130A CN 202210824115 A CN202210824115 A CN 202210824115A CN 115277130 A CN115277130 A CN 115277130A
Authority
CN
China
Prior art keywords
sub
application
user
main app
authorization
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Granted
Application number
CN202210824115.7A
Other languages
Chinese (zh)
Other versions
CN115277130B (en
Inventor
汤士伟
毛志军
王骏
沈欢
姜锋
徐奎东
潘宁
宋丙龙
石志愿
杨文飞
杨秋芬
张丽
马玉刚
周融
王卫新
党忠妍
汪森然
王奇
韦法林
田亚龙
张志航
吕军成
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
WONDERS INFORMATION CO Ltd
Original Assignee
WONDERS INFORMATION CO Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by WONDERS INFORMATION CO Ltd filed Critical WONDERS INFORMATION CO Ltd
Priority to CN202210824115.7A priority Critical patent/CN115277130B/en
Publication of CN115277130A publication Critical patent/CN115277130A/en
Application granted granted Critical
Publication of CN115277130B publication Critical patent/CN115277130B/en
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/04—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks
    • H04L63/0428—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks wherein the data content is protected, e.g. by encrypting or encapsulating the payload
    • H04L63/045—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks wherein the data content is protected, e.g. by encrypting or encapsulating the payload wherein the sending and receiving network entities apply hybrid encryption, i.e. combination of symmetric and asymmetric encryption
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/10—Network architectures or network communication protocols for network security for controlling access to devices or network resources
    • H04L63/101—Access control lists [ACL]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/08—Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
    • H04L9/0861—Generation of secret information including derivation or calculation of cryptographic keys or passwords
    • H04L9/0869—Generation of secret information including derivation or calculation of cryptographic keys or passwords involving random numbers or seeds
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L2209/00—Additional information or applications relating to cryptographic mechanisms or cryptographic arrangements for secret or secure communication H04L9/00
    • H04L2209/08—Randomization, e.g. dummy operations or using noise

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computer Hardware Design (AREA)
  • Computing Systems (AREA)
  • General Engineering & Computer Science (AREA)
  • Storage Device Security (AREA)

Abstract

The invention relates to a user silent authorization method, which is characterized by comprising the following steps that before a sub-application module accesses a main APP: configuring manufacturer information of a manufacturer where the sub application module is located in a database by a main APP server side; configuring sub-application information of a sub-application module in a database by a main APP server; an authCode authorization, an authToken authorization, or a custom authorization is performed. In the invention, the user sensitive information is not exposed at the client and is not transmitted by the client, and the user sensitive information is replaced by the user certificate with timeliness. In the whole authorization interaction process, the transmission of the complete information of the user only occurs between the server side and the server side. And the combination of national password asymmetric encryption and symmetric encryption is used, so that the data transmission safety is ensured, and the access legitimacy is identified. And presetting an IP white list, and verifying whether the IP is legal or not when accessing the authorized interface based on the IP white list. The time efficiency of the authorization code is set, so that the authorization code can be used only once, and the use safety is guaranteed.

Description

User silent authorization method
Technical Field
The invention relates to an authorization method for realizing user information docking between a main APP and a sub application module.
Background
Mobile APPs are increasingly rich in functionality, with different functions typically being implemented by unused application modules within the mobile APP. The application modules may be developed by the same department of the same company, may be developed by different departments of the same company, and may even be developed by different companies. However, no matter whether the application modules in the APP are developed by the same company or the same department, the application modules as built-in modules of the same mobile APP need to be used by the user as a whole in an imperceptible manner, which relates to the problem of user information interfacing between the main APP and the sub-application modules.
In order to realize the user information docking between the main APP and the sub-application module, the main adopted method in the existing technical scheme is as follows: the only user identification and the sensitive information are encrypted in a pre-agreed encryption mode, then carried into the URL of the access sub-application module, and then decrypted and obtained by the sub-application module, so that the sub-application module can share the information of the user currently logging in the main APP and provide services. The main problem of the aforementioned scheme is that the encryption string formed after the user identification and the sensitive information are encrypted can be reused, so that the encryption string has a risk of accidental exposure. Once the encryption string is exposed, it is easy to cause an unauthorized operation. To solve this problem, a solution proposed by those skilled in the art is to add a time stamp to the encryption parameter, and the encryption string is valid only for a certain period of time (i.e., validity period) and can be used repeatedly. Outside the validity period, the encryption string is invalid and the user identification and sensitive information needs to be re-encrypted to generate a new encryption string. It is obvious that during the validity period, the encryption string can still be reused, and the risk of accidental exposure cannot be reduced, so that the security level of the solution is still low, and the solution is not suitable for some occasions requiring a high security level.
Disclosure of Invention
The technical problem to be solved by the invention is as follows: in order to realize the user information butt joint between the main APP and the sub application modules, the encryption string generated by the existing technical scheme can be repeatedly used, and the security level is low.
In order to solve the above technical problem, the technical solution of the present invention is to provide a user silent authorization method, which is characterized by comprising the following steps:
step 1, before the sub-application module accesses the main APP:
the method comprises the steps that a main APP server side configures manufacturer information of a manufacturer where a sub-application module is located in a database, generates a random character string consumerId, an SM2 asymmetric encryption public key consumerKey and an SM2 asymmetric encryption private key consumerPrivatekey which are uniquely corresponding to the manufacturer and stores the random character string consumerId, the SM2 asymmetric encryption public key consumerKey and the SM2 asymmetric encryption private key consumerPrivatekey into the database, wherein: the random character string consumerId and the SM2 asymmetric encryption public key consumerKey are provided for the sub application server to be used; the vendor information at least comprises a vendor server IP;
configuring sub-application information of a sub-application module in a database by a main APP server, wherein the sub-application information at least comprises a sub-application ID, a sub-application jump URL, a sub-application authorization mode and an expansion field, and the sub-application ID starts with a consumerId; the sub-application authorization mode comprises authCode authorization, authToken authorization and custom authorization, wherein the custom authorization defines a specific butt joint mode of the main APP and the sub-application module through an expanded field;
step 2, the main APP client displays the sub-application module to a user according to the configuration information of the main APP server for the user to use; when a user clicks a certain sub-application module, the main APP client checks the configured sub-application authorization mode through the configured sub-application information:
if the sub-application authorization mode of the sub-application module configured by the main APP server side in the database is authCode authorization in the step 1, jumping to a step 4; if the sub-application authorization mode of the sub-application module configured by the main APP server side in the database is authToken authorization in the step 1, jumping to a step 5; if the sub-application authorization mode of the sub-application module configured by the main APP server in the database is custom authorization in the step 1, jumping to a step 6;
and 4, performing authCode authorization, specifically comprising the following steps:
step 401, the main APP client side carries a user certificate of a current user and a sub application ID configured in sub application information to apply for an access authorization code to the main APP server side;
step 402, the main APP server obtains a corresponding user ID through a user certificate transmitted by the main APP client, the user ID and the sub-application ID are stored in a Redis database, a random character string is generated to serve as a key of Redis mapping, the main APP server returns the generated random character string serving as an access authorization code to the main APP client, and the expiration time of the access authorization code in the Redis database is set;
step 403, after the main APP client side takes the access authorization code, splicing the access authorization code to a sub-application jump URL in the sub-application information, and jumping and loading the sub-application jump URL, wherein an address pointed by the sub-application jump URL is a front-end page of the sub-application;
step 404, the front page of the sub application takes the access authorization code spliced behind the jump URL of the sub application and transmits the access authorization code to the sub application server;
step 405, after receiving the access authorization code, the sub application server uses the SM2 asymmetric encryption public key consumerKey generated in the step 1 to perform SM2 encryption on the random character string consumerId generated in the step 1 and the current timestamp to generate an encryption character string; the sub-application server carries the encrypted character string and the plaintext random character string consumerId to access the main APP server;
step 406, after receiving the random string consumerId and the encrypted string of the plaintext, the main APP server queries the associated vendor server IP preconfigured in step 1 through the database by using the random string consumerId, and compares whether the associated vendor server IP is consistent with the currently accessed IP address, so as to identify whether the access is from the white list server, if so, the next step is performed, and if not, the access is denied;
step 407, the main APP server queries, through the database, the associated SM2 asymmetric encryption private key consumerPrivatekey preconfigured in step 1 with the random character string consumerId, decrypts the encrypted character string, if decryption fails, the access is denied, if decryption succeeds, whether the current timestamp obtained by further decrypting the current timestamp distance is within a preset time length is determined, if yes, authentication succeeds, the next step is entered, and if not, authentication fails, the access is denied;
step 408, the main APP server generates a set of new SM2 public private key, stores the new SM2 asymmetric encryption private key affauirsSendPrivatekey and the random character string consumerId into the Redis database, randomly generates a character string as a key mapped by Redis, takes the randomly generated character string as affaurToken, and returns the new SM2 asymmetric encryption public key as affauirsSendKey to the sub-application server;
step 409, after the sub-application server accessing the main APP server in step 405 receives affaurttoken and affaurssendkey fed back by the main APP server, randomly generating a character string as SM4 encryption key encrypted by SM4, encrypting the access authorization code obtained in step 405 by SM4, and encrypting the randomly generated SM4 encryption key as parameter one by SM2 based on affaurssendkey;
step 410, the sub application server side puts affair token and the parameter I obtained in the step 409 into an HTTPHeader, puts the encrypted access authorization code into an HTTPbody, and accesses the main APP server side;
step 411, after the main APP server receives the affair token, the parameter one and the encrypted access authorization code, the main APP server:
querying an SM2 asymmetric encryption private key afairrs SendPrivatekey and a random string consumerId associated with the AFfairToken in step 408 through afairToken;
after the first parameter is decrypted, an SM4 encryption key randomly generated by the sub-application server in step 409 is obtained;
step 412, the master APP server decrypts the encrypted access authorization code by using the SM4 encryption key obtained in the step 411 to obtain an original access authorization code;
step 413, the main APP server queries the user ID and the sub-application ID associated with the main APP server through the access authorization code, and deletes the mapping of the access authorization code in the Redis database, thereby ensuring that the access authorization code has only one-time use effect;
step 414, the main APP server compares whether the random character string consumerId obtained in step 411 and the sub-application ID obtained in step 413 are in an association relationship, if so, continues the next step, otherwise, returns an authorization code not matched with the sub-application;
step 415, the main APP server queries corresponding user information through the user ID obtained in step 413, encrypts the user information by using the SM4 encryption key obtained in step 411, and returns the user information to the sub-application server;
step 416, the sub-application server receives the encrypted user information, decrypts the encrypted user information by using the SM4 encryption key generated in the step 409 to obtain the user information, generates a login certificate by using the user information, and returns the login certificate to the sub-application front end;
step 417, the front end of the sub-application receives the login certificate, and can normally process the service of the same user, so that the authCode authorization process is finished;
step 5, performing authToken authorization, specifically comprising the following steps:
step 501, after the user logs in, the main APP server stores the user information in a Redis database, randomly generates a character string as a user certificate authToken and returns the character string to the main APP client, and the main APP client takes the user certificate authToken as the user certificate during interface interaction;
step 502, when the user clicks the sub-application module, the main APP client checks the sub-application authorization mode through the configured sub-application information, if the authorization is judged to be authToken authorization, the main APP client jumps to a sub-application jump URL in the sub-application information;
step 503, the main APP starts JavaScript to acquire the authority of the user credential authToken;
step 504, the front end of the sub application obtains a user certificate authToken of the main APP through JavaScript interaction;
505, the front end of the sub-application carries the authToken of the user to access the server end of the sub-application;
step 506, the sub-application server accesses the Redis database in step 501 through the user credential authToken to obtain the user information corresponding to the Redis database;
step 507, the sub-application server generates a login credential by using the user information, and returns the login credential to the front end of the sub-application;
step 508, the front end of the sub-application receives the login credentials, and can normally process the services of the same user, so that the authToken authorization process is ended;
step 6, performing custom authorization:
and forming a complete docking scheme of the main APP and the sub-application module through a specific docking mode specified by an expansion field in the sub-application information, and performing reverse authorization docking by the main APP.
Preferably, the vendor information further comprises a vendor name and a vendor profile.
Preferably, the sub-application information further includes a display hierarchy of the sub-application, a name of the sub-application, a type of the sub-application, a number of the sub-application, a domain in which the sub-application is located, a sub-application icon URL, a sub-application skip mode, and a sub-menu of the sub-application.
The invention provides a complete solution from the configuration of the sub-application module, the generation of the temporary authorization certificate and the final service interactive authentication, thereby ensuring the security of the user information authorization. Compared with the prior art, the invention has the following advantages:
1) The sensitive information of the user is not exposed at the client and is not transmitted by the client, and the sensitive information of the user is replaced by the user certificate with timeliness. In the whole authorization interaction process, the transmission of the complete information of the user only occurs between the server side and the server side.
2) And the combination of national password asymmetric encryption and symmetric encryption is used, so that the data transmission safety is ensured, and the access legitimacy is identified.
3) And presetting an IP white list, and verifying whether the IP is legal or not when accessing the authorized interface based on the IP white list.
4) The time efficiency of the authorization code is set, so that the authorization code can be used only once, and the use safety is guaranteed.
The whole process is completed instantly, the process user has no perception, the user is enabled to be safely and conveniently docked, and the main APP in the method can have the capability of accessing the webpage application of each manufacturer.
Detailed Description
The invention will be further illustrated with reference to the following specific examples. It should be understood that these examples are for illustrative purposes only and are not intended to limit the scope of the present invention. Further, it should be understood that various changes or modifications of the present invention may be made by those skilled in the art after reading the teaching of the present invention, and such equivalents may fall within the scope of the present invention as defined in the appended claims.
The user silence authorization method disclosed by the embodiment comprises the following steps:
step 1, before the sub-application module accesses the main APP:
(1) The method comprises the steps that a main APP server side configures manufacturer information of a manufacturer where a sub-application module is located in a database, and generates a 16-bit random character string consumerId, an SM2 asymmetric encryption public key consumerKey and an SM2 asymmetric encryption private key consumerPrivatekey which are uniquely corresponding to the manufacturer and are stored in the database, wherein the consumerId and the SM2 asymmetric encryption public key consumerKey are provided for the sub-application server side to use. In this embodiment, the vendor information includes vendor name, vendor profile, vendor server IP, and the like.
(2) And configuring the sub-application information of the sub-application module in the database by the main APP server. In this embodiment, the sub-application information includes information such as a display level of the sub-application, a sub-application ID, a sub-application name, a sub-application jump URL, a sub-application type, a sub-application number, a domain in which the sub-application is located, a sub-application icon URL, a sub-application authorization mode, a sub-application jump mode, and a sub-menu and an extension of the sub-application. When configuring the sub-application ID of the sub-application module, the sub-application ID starts with consumerId, so that the subsequent search for the affiliated manufacturer is facilitated.
Step 1 considers the situation that a plurality of sub-application modules may belong to the same manufacturer for development, generates corresponding consumerId, consumerKey and consumerPrivatekey for different manufacturers, and configures the sub-application IDs of the sub-application modules based on the consumerId.
And step 2, the main APP client displays the sub-application module to the user according to the configuration information of the main APP server for the user to use. When a user clicks a certain sub-application module, the main APP client checks the configured sub-application authorization modes through the configured sub-application information, wherein the sub-application authorization modes comprise authCode authorization, authToken authorization and custom authorization.
If the sub-application authorization mode of the sub-application module configured by the main APP server side in the database is authCode authorization in the step 1, jumping to a step 4; if the sub-application authorization mode of the sub-application module configured by the main APP server side in the database is authToken authorization in the step 1, jumping to a step 5; and if the sub-application authorization mode of the sub-application module configured by the main APP server in the database in the step 1 is custom authorization, jumping to a step 6.
And 4, performing authCode authorization, specifically comprising the following steps:
step 401, the main APP client side carries a user certificate of a current user and a sub application ID configured in sub application information to apply for an access authorization code to the main APP server side;
step 402, the main APP server obtains a corresponding user ID through a user certificate transmitted by the main APP client, stores the user ID and the sub-application ID into a Redis database, generates a random character string as a key for Redis mapping, returns the generated random character string as an access authorization code to the main APP client, and sets the expiration time of the access authorization code mapped in the Redis database to 2 minutes;
in the step, the validity period of the access authorization code is ensured by setting the validity period of the Redis database;
step 403, after the main APP client receives the access authorization code, splicing the access authorization code to a sub-application jump URL in the sub-application information, and jumping and loading the sub-application jump URL, wherein an address pointed by the sub-application jump URL is a front-end page of the sub-application;
step 404, the front page of the sub application takes the access authorization code spliced behind the jump URL of the sub application and transmits the access authorization code to the sub application server;
step 405, after receiving the access authorization code, the sub application server uses the SM2 asymmetric encryption public key consumerKey generated in the step 1 to perform SM2 encryption on the 16-bit random character string consumerId generated in the step 1 and the current timestamp to generate an encryption character string; the sub-application server carries 16-bit random character string consumerId of an encrypted character string and a plaintext to access the main APP server;
step 406, after receiving the 16-bit random string consumerId and the encrypted string in the plaintext, the main APP server queries the associated vendor server IP preconfigured in step 1 through the database by using the 16-bit random string consumerId, and compares whether the vendor server IP is consistent with the currently accessed IP address, so as to identify whether the access is from the white list server, if so, the next step is performed, and if not, the access is rejected;
step 407, the main APP server uses a 16-bit random string consumerId to query the associated SM2 asymmetric encryption private key consumerPrivatekey configured in advance in step 1 through a database, decrypts the encrypted string, if decryption fails, the access is denied, if decryption succeeds, whether the current timestamp obtained by further decrypting the current timestamp distance is within 1 minute is determined, if yes, authentication succeeds, the next step is entered, and if not, authentication fails, the access is denied;
step 408, the main APP server generates a new SM2 public private key, stores the new SM2 asymmetric encryption private key affauirsSendPrivatekey and the 16-bit random character string consumerId into a Redis database, randomly generates a character string as a key mapped by Redis, takes the randomly generated character string as affaurToken, and returns the new SM2 asymmetric encryption public key as affauirsSendKey to the sub-application server;
the step is to prepare for the one-time pad of the subsequent service interaction, so as to improve the safety;
in the step 409 and the step 405, after the sub application server accessing the master APP server receives afafirtoken and afafirssendkey fed back by the master APP server, a 16-bit character string is randomly generated as an SM4 encryption key encrypted by SM4, the SM4 is used to encrypt the access authorization code obtained in the step 405, and the SM4 encryption key randomly generated by SM2 encryption is used as a parameter one based on afafirssendkey;
in the step, since the SM4 encryption key is randomly generated, the encryption key can be different every time, so that one-time pad is realized; the invention encrypts the SM4 encryption key by afairrs SendKey and transmits the encrypted key to the main APP server, thereby ensuring that only the main APP server can decrypt the encrypted key and ensuring the safe transmission of the key at the same time of one-time encryption;
step 410, the sub application server side puts affair token and the parameter I obtained in the step 409 into an HTTPHeader, puts the encrypted access authorization code into an HTTPbody, and accesses the main APP server side;
step 411, after the main APP server receives the affair token, the parameter one and the encrypted access authorization code, the main APP server:
(1) Querying an SM2 asymmetric encryption private key afairrs SendPrivatekey associated with the step 408 and a 16-bit random string consumerId through afairToken;
(2) After the first parameter is decrypted, an SM4 encryption key randomly generated by the sub-application server in the step 409 is obtained;
step 412, the master APP server decrypts the encrypted access authorization code by using the SM4 encryption key obtained in the step 411 to obtain an original access authorization code;
step 413, the main APP server queries the user ID and the sub-application ID associated with the main APP server through the access authorization code, and deletes the mapping of the access authorization code in the Redis database, thereby ensuring that the access authorization code has only one-time use effect;
step 414, the main APP server compares whether the 16-bit random string consumerId obtained in step 411 and the sub-application ID obtained in step 413 are in an association relationship (in step 1, the sub-application ID is configured beginning with the 16-bit random string consumerId), if so, the next step is continued, otherwise, the returned authorization code is not matched with the sub-application;
the method comprises the following steps of ensuring that the action range of an access authorization code is only a currently authorized sub-application;
step 415, the main APP server queries corresponding user information through the user ID obtained in step 413, encrypts the user information by using the SM4 encryption key obtained in step 411, and returns the user information to the sub-application server;
step 416, the sub-application server receives the encrypted user information, decrypts the encrypted user information by using the SM4 encryption key generated in the step 409 to obtain the user information, generates a login certificate by using the user information, and returns the login certificate to the sub-application front end;
step 417, the front end of the sub-application receives the login credential, and can normally process the service of the same user, so that the authCode authorization process is ended.
Step 5, performing authToken authorization (usually used when the main APP and the sub-application module are developed by different departments in the same company), specifically including the following steps:
step 501, after the user logs in, the main APP server stores the user information in a Redis database, randomly generates a character string as a user certificate authToken and returns the character string to the main APP client, and the main APP client takes the user certificate authToken as the user certificate during interface interaction;
step 502, when the user clicks the sub-application module, the main APP client checks the sub-application authorization mode through the configured sub-application information, if the authorization mode is judged as authToken authorization, the main APP client jumps to a sub-application jump URL in the sub-application information;
step 503, the main APP starts JavaScript to acquire the authority of the user credential authToken;
step 504, the front end of the sub application obtains a user certificate authToken of the main APP through JavaScript interaction;
505, the front end of the sub-application carries the user certificate authToken to access the service end of the sub-application;
step 506, the sub-application server accesses the Redis database in step 501 through the user credential authToken to obtain the user information corresponding to the Redis database;
step 507, the sub-application server generates a login credential by using the user information, and returns the login credential to the front end of the sub-application;
and step 508, the front end of the sub-application receives the login certificate, and can normally process the service of the same user, so that the authToken authorization process is finished.
And 6, performing custom authorization. The custom authorization is a special self-defined authorization mode, a complete docking scheme of the main APP and the sub application modules is formed, and the main APP needs to be docked in a reverse authorization mode. When custom authorization is carried out, a specific docking mode is specified through an expansion field in the sub application information, and flexible configuration is achieved while self-defining is carried out.

Claims (3)

1. A silent authorization method for a user, comprising the steps of:
step 1, before the sub application module accesses the main APP:
configuring manufacturer information of a manufacturer where the sub-application module is located in a database by a main APP server, generating a random character string consumerId, an SM2 asymmetric encryption public key consumerKey and an SM2 asymmetric encryption private key consumerPrivatekey which are uniquely corresponding to the manufacturer, and storing the random character string consumerId, the SM2 asymmetric encryption public key consumerPrivatekey and the SM2 asymmetric encryption private key consumerPrivatekey into the database, wherein: the random character string consumerId and the SM2 asymmetric encryption public key consumerKey are provided for the sub application server to be used; the vendor information at least comprises a vendor server IP;
configuring sub-application information of a sub-application module in a database by a main APP server side, wherein the sub-application information at least comprises a sub-application ID, a sub-application jump URL, a sub-application authorization mode and an expansion field, and the sub-application ID starts with a consumerId; the sub-application authorization mode comprises authCode authorization, authToken authorization and custom authorization, wherein the custom authorization defines a specific butt joint mode of the main APP and the sub-application module through an expanded field;
step 2, the main APP client displays the sub-application module to a user according to the configuration information of the main APP server for the user to use; when a user clicks a certain sub-application module, the main APP client checks the configured sub-application authorization mode through the configured sub-application information:
if the sub-application authorization mode of the sub-application module configured by the main APP server side in the database is authCode authorization in the step 1, jumping to a step 4; if the sub-application authorization mode of the sub-application module configured by the main APP server side in the database is authToken authorization in the step 1, jumping to a step 5; if the sub-application authorization mode of the sub-application module configured by the main APP server in the database in the step 1 is custom authorization, jumping to a step 6;
and 4, performing authCode authorization, specifically comprising the following steps:
step 401, the main APP client side carries a user certificate of a current user and a sub application ID configured in sub application information to apply for an access authorization code to the main APP server side;
step 402, the main APP server obtains a corresponding user ID through a user certificate transmitted by the main APP client, the user ID and the sub-application ID are stored in a Redis database, a random character string is generated to serve as a key of Redis mapping, the main APP server returns the generated random character string serving as an access authorization code to the main APP client, and the expiration time of the access authorization code in the Redis database is set;
step 403, after the main APP client receives the access authorization code, splicing the access authorization code to a sub-application jump URL in the sub-application information, and jumping and loading the sub-application jump URL, wherein an address pointed by the sub-application jump URL is a front-end page of the sub-application;
step 404, the front page of the sub-application takes the access authorization code spliced after the jump URL of the sub-application, and transmits the access authorization code to the sub-application server;
step 405, after receiving the access authorization code, the sub application server uses the SM2 asymmetric encryption public key consumerKey generated in the step 1 to perform SM2 encryption on the random character string consumerId generated in the step 1 and the current timestamp to generate an encryption character string; the sub-application server carries the encrypted character string and the plaintext random character string consumerId to access the main APP server;
step 406, after receiving the random string consumerId and the encrypted string of the plaintext, the main APP server queries the associated vendor server IP preconfigured in step 1 through the database by using the random string consumerId, and compares whether the associated vendor server IP is consistent with the currently accessed IP address, so as to identify whether the access is from the white list server, if so, the next step is performed, and if not, the access is denied;
step 407, the main APP server queries, through the database, the associated SM2 asymmetric encryption private key consumerPrivatekey preconfigured in step 1 with the random character string consumerId, decrypts the encrypted character string, if decryption fails, the access is denied, if decryption succeeds, whether the current timestamp obtained by further decrypting the current timestamp distance is within a preset time length is determined, if yes, authentication succeeds, the next step is entered, and if not, authentication fails, the access is denied;
step 408, the main APP server generates a set of new SM2 public private key, stores the new SM2 asymmetric encryption private key affauirsSendPrivatekey and the random character string consumerId into the Redis database, randomly generates a character string as a key mapped by Redis, takes the randomly generated character string as affaurToken, and returns the new SM2 asymmetric encryption public key as affauirsSendKey to the sub-application server;
in the step 409 and the step 405, after the sub application server accessing the master APP server receives afairToken and afairSendKey fed back by the master APP server, a character string is randomly generated as an SM4 encryption key encrypted by SM4, the access authorization code obtained in the step 405 is encrypted by SM4, and the SM4 encryption key randomly generated by SM2 encryption is used as a parameter one based on afairSendKey;
step 410, the sub application server side puts affair token and the parameter I obtained in the step 409 into an HTTPHeader, puts the encrypted access authorization code into an HTTPbody, and accesses the main APP server side;
step 411, after the main APP server receives the affair token, the parameter one and the encrypted access authorization code, the main APP server:
querying the SM2 asymmetric encryption private key consumprivatekey and the random string consummerid associated therewith in step 408 through afafirttoken;
after the first parameter is decrypted, an SM4 encryption key randomly generated by the sub-application server in step 409 is obtained;
step 412, the main APP server decrypts the encrypted access authorization code by using the SM4 encryption key obtained in step 411 to obtain an original access authorization code;
step 413, the main APP server queries the user ID and the sub-application ID associated with the main APP server through the access authorization code, and deletes the mapping of the access authorization code in the Redis database, so that the access authorization code is guaranteed to have a one-time use effect;
step 414, the main APP server compares whether the random character string consumerId obtained in step 411 and the sub-application ID obtained in step 413 are in an association relationship, if so, continues the next step, otherwise, returns an authorization code not matched with the sub-application;
step 415, the main APP server queries corresponding user information through the user ID obtained in step 413, encrypts the user information by using the SM4 encryption key obtained in step 411, and returns the user information to the sub-application server;
step 416, the sub-application server receives the encrypted user information, decrypts the encrypted user information by using the SM4 encryption key generated in the step 409 to obtain the user information, generates a login certificate by using the user information, and returns the login certificate to the sub-application front end;
step 417, the front end of the sub-application receives the login certificate, and can normally process the service of the same user, so that the authCode authorization process is finished;
step 5, performing authToken authorization, specifically comprising the following steps:
step 501, after a user logs in, the main APP server stores user information into a Redis database, randomly generates a character string as a user credential authToken, and returns the character string to the main APP client, wherein the main APP client uses the user credential authToken as a user credential during interface interaction;
step 502, when the user clicks the sub-application module, the main APP client checks the sub-application authorization mode through the configured sub-application information, if the authorization is judged to be authToken authorization, the main APP client jumps to a sub-application jump URL in the sub-application information;
step 503, the main APP starts JavaScript to acquire the authority of the user credential authToken;
step 504, the front end of the sub application obtains a user certificate authToken of the main APP through JavaScript interaction;
505, the front end of the sub-application carries the authToken of the user to access the server end of the sub-application;
step 506, the sub application server accesses the Redis database in step 501 through the user credential authToken to acquire the user information corresponding to the user credential;
step 507, the sub-application server generates a login credential by using the user information, and returns the login credential to the front end of the sub-application;
step 508, the front end of the sub-application receives the login certificate, and can process the business of the same user normally, until the authToken authorization process is finished;
step 6, performing custom authorization:
and forming a complete docking scheme of the main APP and the sub-application module through a specific docking mode specified by an expansion field in the sub-application information, and performing reverse authorization docking by the main APP.
2. The method of claim 1, wherein the vendor information further comprises a vendor name and a vendor profile.
3. The method for user silence authorization according to claim 1, wherein the sub-application information further includes a presentation level of the sub-application, a name of the sub-application, a type of the sub-application, a number of the sub-application, a domain where the sub-application is located, a URL of an icon of the sub-application, a skip mode of the sub-application, and a sub-menu of the sub-application.
CN202210824115.7A 2022-07-14 2022-07-14 User silence authorization method Active CN115277130B (en)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN202210824115.7A CN115277130B (en) 2022-07-14 2022-07-14 User silence authorization method

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN202210824115.7A CN115277130B (en) 2022-07-14 2022-07-14 User silence authorization method

Publications (2)

Publication Number Publication Date
CN115277130A true CN115277130A (en) 2022-11-01
CN115277130B CN115277130B (en) 2023-11-17

Family

ID=83764389

Family Applications (1)

Application Number Title Priority Date Filing Date
CN202210824115.7A Active CN115277130B (en) 2022-07-14 2022-07-14 User silence authorization method

Country Status (1)

Country Link
CN (1) CN115277130B (en)

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20120304256A1 (en) * 2009-10-21 2012-11-29 Sion Euros Evans Electronic mail system and method
US20140279474A1 (en) * 2013-03-12 2014-09-18 Visa International Service Association Multi-purse one card transaction apparatuses, methods and systems
CN104618369A (en) * 2015-01-27 2015-05-13 广州市戴为智能科技有限公司 Method, device and system for unique authorization of Internet-of-Things equipment based on OAuth
CN111832055A (en) * 2020-07-22 2020-10-27 政采云有限公司 Authority verification system and method
CN112306978A (en) * 2020-12-24 2021-02-02 大汉软件股份有限公司 Trusted data authorization method, authentication authorization method and service access method

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20120304256A1 (en) * 2009-10-21 2012-11-29 Sion Euros Evans Electronic mail system and method
US20140279474A1 (en) * 2013-03-12 2014-09-18 Visa International Service Association Multi-purse one card transaction apparatuses, methods and systems
CN104618369A (en) * 2015-01-27 2015-05-13 广州市戴为智能科技有限公司 Method, device and system for unique authorization of Internet-of-Things equipment based on OAuth
CN111832055A (en) * 2020-07-22 2020-10-27 政采云有限公司 Authority verification system and method
CN112306978A (en) * 2020-12-24 2021-02-02 大汉软件股份有限公司 Trusted data authorization method, authentication authorization method and service access method

Also Published As

Publication number Publication date
CN115277130B (en) 2023-11-17

Similar Documents

Publication Publication Date Title
CN109617698B (en) Method for issuing digital certificate, digital certificate issuing center and medium
US9867051B2 (en) System and method of verifying integrity of software
US9231758B2 (en) System, device, and method of provisioning cryptographic data to electronic devices
CN103685282B (en) A kind of identity identifying method based on single-sign-on
CN101860540B (en) Method and device for identifying legality of website service
CN103235906B (en) A kind of application program encryption, decryption method and encryption, decryption device
EP3425842B1 (en) Communication system and communication method for certificate generation
KR101210260B1 (en) OTP certification device
CN102833593A (en) Authorization method and system applied to smart TV (television) as well as smart TV
CN104412273A (en) Method and system for activation
JP2014531659A (en) System and method for user authentication
TW201813361A (en) Method and device for providing and obtaining graphic code information, and terminal
US11943345B2 (en) Key management method and related device
KR100668446B1 (en) Safe --method for transferring digital certificate
JP2024501326A (en) Access control methods, devices, network equipment, terminals and blockchain nodes
CN103078739A (en) Dynamic-password authenticating method, device and network system
KR101478526B1 (en) System and method of managing and offering cryptographic key with using authentication information
CN114070620B (en) Short address access method, device, computer equipment and storage medium
CN107241341B (en) Access control method and device
KR100726074B1 (en) Method And System Of Certifying Mobile Internet User
CN115277130A (en) User silent authorization method
WO2019234801A1 (en) Service provision system and service provision method
KR20150005789A (en) Method for Authenticating by using Certificate
CN108881153B (en) Authentication method for login
TW202121867A (en) Point-to-point authority management method based on manager's self-issued ticket achieves purpose of decentralizing management by issuing tickets for managing use permission and management authority of electronic devices

Legal Events

Date Code Title Description
PB01 Publication
PB01 Publication
SE01 Entry into force of request for substantive examination
SE01 Entry into force of request for substantive examination
GR01 Patent grant
GR01 Patent grant