CN115277130B - User silence authorization method - Google Patents
User silence authorization method Download PDFInfo
- Publication number
- CN115277130B CN115277130B CN202210824115.7A CN202210824115A CN115277130B CN 115277130 B CN115277130 B CN 115277130B CN 202210824115 A CN202210824115 A CN 202210824115A CN 115277130 B CN115277130 B CN 115277130B
- Authority
- CN
- China
- Prior art keywords
- sub
- application
- user
- server
- 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.)
- Active
Links
- 238000013475 authorization Methods 0.000 title claims abstract description 129
- 238000000034 method Methods 0.000 title claims abstract description 28
- 230000008569 process Effects 0.000 claims abstract description 15
- 230000003993 interaction Effects 0.000 claims abstract description 9
- 238000003032 molecular docking Methods 0.000 claims description 11
- 238000013507 mapping Methods 0.000 claims description 6
- 230000000694 effects Effects 0.000 claims description 3
- 230000005540 biological transmission Effects 0.000 abstract description 5
- 230000001550 time effect Effects 0.000 abstract description 3
- 210000001503 joint Anatomy 0.000 description 3
- 208000032484 Accidental exposure to product Diseases 0.000 description 1
- 231100000818 accidental exposure Toxicity 0.000 description 1
- 230000009471 action Effects 0.000 description 1
- 238000011161 development Methods 0.000 description 1
- 230000006870 function Effects 0.000 description 1
- 230000002452 interceptive effect Effects 0.000 description 1
- 238000012986 modification Methods 0.000 description 1
- 230000004048 modification Effects 0.000 description 1
- 230000008447 perception Effects 0.000 description 1
- 238000012545 processing Methods 0.000 description 1
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 application relates to a user silence authorization method which is characterized by comprising the following steps that before a sub-application module is accessed into a main APP: configuring manufacturer information of a manufacturer where the sub application module is located in a database by a main APP server; 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 application, the user sensitive information is not exposed to the client, is not transmitted through the client, and 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 asymmetric encryption and symmetric encryption of the national cipher is used, so that the security of data transmission is ensured, and the access legitimacy is identified. An IP white list is preset, and based on the IP white list, whether the IP is legal or not is verified when the authorized interface is accessed. And setting the time effect of the authorization code, so that the authorization code can be used only once, and the use safety is ensured.
Description
Technical Field
The application relates to an authorization method for realizing user information docking between a main APP and a sub-application module.
Background
Mobile APP is increasingly functional, with different functions typically implemented by unused application modules within the mobile APP. These application modules may be developed by the same department of the same company, by different departments of the same company, or even by different companies. However, whether the application modules in the APP are developed by the same company or by the same department, the application modules are used as the modules in the same mobile APP, and the user needs to use the application modules as a whole without perception, which involves the problem of user information butt joint between the main APP and the sub-application modules.
In order to realize the user information butt joint between the main APP and the sub-application module, the prior technical scheme mainly adopts the following method: after the unique user identification and the sensitive information are encrypted in a preset encryption mode, the encrypted user identification and the sensitive information are carried into the URL of the access sub-application module and are decrypted and acquired by the sub-application module, so that the sub-application module can share the information of the user currently logged in the main APP and provide services. The main problem of the foregoing solution is that the encrypted string formed after the encryption of the user identification and the sensitive information can be reused, so that the encrypted string is exposed accidentally. Once the encryption string is exposed, unauthorized operations are easily caused. 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 reused. Outside of the validity period, the encrypted string fails, requiring re-encryption of the user identification and sensitive information to generate a new encrypted string. It is apparent that the encryption string is still reusable for the duration of the validity period and still cannot reduce the risk of accidental exposure, so that the security level of this solution is still low and is not applicable in some situations where a higher security level is required.
Disclosure of Invention
The application aims to solve the technical problems that: in order to realize the user information butt joint between the main APP and the sub-application module, the encryption string generated by the prior technical scheme can be repeatedly used, and the security level is lower.
In order to solve the technical problem, the technical scheme of the application provides a user silence authorization method, which is characterized by comprising the following steps:
step 1, before a sub application module accesses a main APP:
the main APP server configures vendor information of a vendor where the sub application module is located in a database, generates a random character string consumerId, SM2 asymmetric encryption public key and an SM2 asymmetric encryption private key which are uniquely corresponding to the vendor, and stores the random character string consumerId, SM asymmetric encryption public key and the SM2 asymmetric encryption private key in the database, wherein: the random character string consumerId and the SM2 asymmetric encryption public key consumerKey are provided for the sub-application server side to use; the manufacturer information at least comprises a manufacturer server IP;
the method comprises the steps that a main APP server side configures sub-application information of a sub-application module in a database, 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 concsmerId; the sub-application authorization modes comprise an authCode authorization, an authToken authorization and a custom authorization, wherein the custom authorization self-defines a specific docking mode of the main APP and the sub-application module through an expansion field;
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 mode through the configured sub-application information:
if in step 1, the main APP server configures the authorization mode of the sub application module in the database as authCode authorization, then the step 4 is skipped; if in step 1, the main APP server configures the sub-application authorization mode of the sub-application module in the database as authToken authorization, then the step 5 is skipped; if in step 1, the main APP server configures a custom authorization mode of the sub application module in the database, then the step 6 is skipped;
step 4, performing authCode authorization, which specifically comprises the following steps:
step 401, a main APP client applies for an access authorization code from a main APP server with a user credential of a current user and a sub-application ID configured in sub-application information;
step 402, the main APP server obtains the corresponding user ID through the user credential 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 of Redis mapping, returns the generated random character string to the main APP client as an access authorization code, and sets the expiration time of the access authorization code in the Redis database;
step 403, after the main APP client takes the access authorization code, splicing the access authorization code to a sub-application jump URL in the sub-application information, and loading the sub-application jump URL in a jump manner, wherein the address pointed by the sub-application jump URL is the front-end page of the sub-application;
step 404, the front end page of the sub-application takes the access authorization code spliced after the sub-application jumps to the URL, and the access authorization code is transmitted to the sub-application server;
step 405, after receiving the access authorization code, the sub application server encrypts the random string consumerId generated in step 1 and the current timestamp by using the SM2 asymmetric encryption public key consumerKey generated in step 1 to generate an encrypted string; the sub-application server side carries the encrypted character string and the random character string concremerId of the plaintext to access the main APP server side;
step 406, after receiving the plaintext random character string consumeid and the encrypted character string, the main APP server uses the random character string consumeid to query the associated manufacturer server IP preconfigured in step 1 through the database, and compares whether the random character string consumeid is consistent with the current accessed IP address, thereby identifying whether the access from the white list server is achieved, if so, entering the next step, and if not, rejecting the access;
step 407, the master APP server uses a random character string consumerId to inquire the related SM2 asymmetric encryption private key preset in the step 1 through a database, decrypts the encrypted character string, refuses the access if the decryption fails, further judges whether the current time stamp obtained by decrypting the current time stamp is within a preset time length if the decryption is successful, successfully authenticates the user, and enters the next step if the decryption is not successful, otherwise, fails to authenticate the user, refuses the access;
step 408, the main APP server generates a new SM2 public and private key, stores the new SM2 asymmetric encryption private key affairsSendPrivatekey and a random character string condumerId into a Redis database, randomly generates a character string as a key mapped by Redis, and returns the randomly generated character string as an affairToken, and the new SM2 asymmetric encryption public key as an affairsSendKey to the sub-application server;
step 409, after receiving the affairToken and the affairSendKey fed back by the master APP server by the sub application server accessing the master APP server in step 405, randomly generating a character string as an SM4 encryption key for SM4 encryption, encrypting the access authorization code obtained in step 405 by using SM4, and using the SM4 encryption key generated randomly by SM2 encryption as a parameter I based on the affairSendKey;
step 410, the sub-application server puts the affairToken and the parameter one obtained in step 409 into the http header, and the encrypted access authorization code is put into the http body to access the main APP server;
step 411, after receiving the affairToken, the parameter one, and the encrypted access authorization code, the master APP server:
querying an SM2 asymmetric encryption private key affairsSendPrivatekey and a random character string consumerId associated with the key in the step 408 through the affairToken;
after decrypting the first parameter, obtaining an SM4 encryption key randomly generated by the sub-application server in step 409;
step 412, the master APP server decrypts the encrypted access authorization code 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 ensured to have 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 association, if so, the next step is continued, otherwise, the feedback weight code is 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 encrypted user information to the sub-APP 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 step 409 to obtain the user information, and the sub-application server uses the user information to generate a login credential and returns the login credential to the front end of the sub-application;
step 417, the front end of the sub-application receives the login credentials, and can normally process the business of the same user, so that the authorization process of the authCode is finished;
step 5, carrying out authToken authorization, which specifically comprises the following steps:
step 501, after a user logs in, a main APP server stores user information into a Redis database, randomly generates a character string as a user credential authToken, returns the character string to a main APP client, and the main APP client uses the user credential authToken as a user credential when interaction is performed;
step 502, when a user clicks a sub-application module, the main APP client checks a sub-application authorization mode through the configured sub-application information, judges that the main application client is authorized by an authToken, and jumps to a sub-application jump URL in the sub-application information;
step 503, the master APP starts JavaScript to obtain the authority of the user certificate authToken;
step 504, the front end of the sub-application acquires a user credential authToken of the main APP through JavaScript interaction;
step 505, the front end of the sub-application carries the user credentials authToken to access the sub-application server;
step 506, the sub-application server accesses the Redis database in step 501 through the user certificate authToken to acquire the corresponding user information;
step 507, the sub-application server uses the user information to generate a login credential, 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 business of the same user, and the authorization process of the authToken is ended;
step 6, performing custom authorization:
and forming a complete docking scheme of the main APP and the sub application module by 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 includes a vendor name and a vendor profile.
Preferably, the sub-application information further includes a presentation level of the sub-application, a sub-application name, a sub-application type, a sub-application number, a domain where the sub-application is located, a sub-application icon URL, a sub-application jump mode, and a sub-menu of the sub-application.
The application provides a complete solution from configuration of the sub-application module to generation of temporary authorization credentials and finally to service interactive authentication, thereby guaranteeing the security of user information authorization. Compared with the prior art, the application has the following advantages:
1) The user sensitive information is not exposed to the client, is not transferred through the client, and is replaced by user credentials 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 asymmetric encryption and symmetric encryption of the national cipher is used, so that the security of data transmission is ensured, and the access legitimacy is identified.
3) An IP white list is preset, and based on the IP white list, whether the IP is legal or not is verified when the authorized interface is accessed.
4) And setting the time effect of the authorization code, so that the authorization code can be used only once, and the use safety is ensured.
The whole process is finished instantaneously, and a process user does not feel, so that the user can safely and conveniently dock, and the master APP in the application can have the capability of accessing the webpage application of each manufacturer.
Detailed Description
The application will be further illustrated with reference to specific examples. It is to be understood that these examples are illustrative of the present application and are not intended to limit the scope of the present application. Furthermore, it should be understood that various changes and modifications can be made by one skilled in the art after reading the teachings of the present application, and such equivalents are intended to fall within the scope of the application as defined in the appended claims.
The user silence authorization method disclosed by the embodiment comprises the following steps:
step 1, before a sub application module accesses a main APP:
(1) The main APP server configures vendor information of a vendor where the sub-application module is located in the database, generates a 16-bit random string consumerId, SM2 asymmetric encryption public key and an SM2 asymmetric encryption private key which are uniquely corresponding to the vendor, and stores the 16-bit random string in the database, wherein the concureId and the SM2 asymmetric encryption public key consumekey are provided for the sub-application server to use. In this embodiment, the vendor information includes vendor name, vendor profile, vendor server IP, etc.
(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 presentation hierarchy 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 where the sub-application is located, a sub-application icon URL, a sub-application authorization mode, a sub-application jump mode, a sub-menu and expansion of the sub-application, and the like. When the sub-application ID of the sub-application module is configured, the sub-application ID starts with a concremerId, so that the manufacturer can be conveniently searched later.
Step 1 considers the situation that a plurality of sub-application modules may belong to the same vendor for development, generates corresponding consumerId, consumerKey and controlprivatekey for different vendors, and configures the sub-application ID of the sub-application module based on the controlid.
And 2, the main APP client displays the sub-application modules 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 mode through the configured sub-application information, wherein the sub-application authorization mode comprises an authCode authorization, an authToken authorization and a custom authorization.
If in step 1, the main APP server configures the authorization mode of the sub application module in the database as authCode authorization, then the step 4 is skipped; if in step 1, the main APP server configures the sub-application authorization mode of the sub-application module in the database as authToken authorization, then the step 5 is skipped; if in step 1, the main APP server configures a child application authorization mode of the child application module in the database as a custom authorization, then step 6 is skipped.
Step 4, performing authCode authorization, which specifically comprises the following steps:
step 401, a main APP client applies for an access authorization code from a main APP server with a user credential of a current user and a sub-application ID configured in sub-application information;
step 402, the main APP server obtains the corresponding user ID through the user credential 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 of Redis mapping, returns the generated random character string to the main APP client as an access authorization code, and sets the expiration time of the access authorization code mapped in the Redis database as 2 minutes;
in the step, the validity period of the access authorization code is ensured by setting the time effect of the Redis database;
step 403, after the main APP client takes the access authorization code, splicing the access authorization code to a sub-application jump URL in the sub-application information, and loading the sub-application jump URL in a jump manner, wherein the address pointed by the sub-application jump URL is the front-end page of the sub-application;
step 404, the front end page of the sub-application takes the access authorization code spliced after the sub-application jumps to the URL, and the access authorization code is transmitted to the sub-application server;
step 405, after receiving the access authorization code, the sub application server encrypts the 16-bit random string consumeid and the current timestamp generated in step 1 by using the SM2 asymmetric encryption public key consumerKey generated in step 1 to generate an encrypted string; the sub-application server side carries the encrypted character string and the 16-bit random character string concurerId of the plaintext to access the main APP server side;
step 406, after receiving the 16-bit random character string consumeid and the encrypted character string of the plaintext, the main APP server uses the 16-bit random character string consumeid to query the associated manufacturer server IP preconfigured in the step 1 through a database and compares whether the IP address is consistent with the IP address of the current access, thereby identifying whether the access from the white list server is performed, if so, entering the next step, and if not, refusing the access;
step 407, the main APP server uses a 16-bit random character string consumerId to inquire the related SM2 asymmetric encryption private key preset in the step 1 through a database, decrypts the encrypted character string, refuses the access if the decryption fails, further judges whether the current timestamp obtained by decrypting the current timestamp is within 1 minute if the decryption is successful, if yes, the authentication is successful, and enters the next step, otherwise, the authentication fails, and refuses the access;
step 408, the main APP server generates a new SM2 public and private key, stores the new SM2 asymmetric encryption private key affairsSendPrivatekey and a 16-bit random character string condumerId into a Redis database, randomly generates a character string as a key mapped by Redis, takes the randomly generated character string as an affairToken, and returns the new SM2 asymmetric encryption public key as an affairsSendKey to the sub-application server;
the method is used for preparing one-time pad for subsequent service interaction, so that the safety is improved;
step 409, after receiving the affairToken and the affairSendKey fed back by the master APP server by the sub application server accessing the master APP server in step 405, randomly generating a 16-bit character string as an SM4 encryption key for SM4 encryption, encrypting the access authorization code obtained in step 405 by using SM4, and using the SM4 encryption key randomly generated by SM2 encryption as a parameter I based on the affairSendKey;
in the step, because the SM4 encryption key is randomly generated, the encryption keys can be different every time, thereby realizing one-time encryption; the application encrypts the SM4 encryption key by using the affairsSendKey and transmits the encrypted SM4 encryption key to the main APP server, so that only the main APP server can decrypt the encrypted SM4 encryption key, and the secure transmission of the key is ensured while one-time encryption is performed;
step 410, the sub-application server puts the affairToken and the parameter one obtained in step 409 into the http header, and the encrypted access authorization code is put into the http body to access the main APP server;
step 411, after receiving the affairToken, the parameter one, and the encrypted access authorization code, the master APP server:
(1) Querying an SM2 asymmetric encryption private key affairsSendPrivatekey and a 16-bit random string consumerId associated with the key in the step 408 through the affairToken;
(2) After decrypting the first parameter, obtaining an SM4 encryption key randomly generated by the sub-application server in step 409;
step 412, the master APP server decrypts the encrypted access authorization code 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 ensured to have only one-time use effect;
step 414, the main APP server compares the 16-bit random string consumeid obtained in step 411 with the sub-application ID obtained in step 413 to determine whether the sub-application ID is an association (in step 1, the sub-application ID is configured by starting with the 16-bit random string consumeid), if so, the next step is continued, otherwise, the feedback weight code is not matched with the sub-application;
the step is to ensure that the scope of action of the access authorization code is only the 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 encrypted user information to the sub-APP 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 step 409 to obtain the user information, and the sub-application server uses the user information to generate a login credential and returns the login credential to the front end of the sub-application;
in step 417, the front end of the sub-application receives the login credentials, and can normally process the service of the same user, so that the authorization process of the authCode is finished.
Step 5, performing authToken authorization (usually, the main APP and the sub-application module are used when developed for different departments in the same company), specifically including the following steps:
step 501, after a user logs in, a main APP server stores user information into a Redis database, randomly generates a character string as a user credential authToken, returns the character string to a main APP client, and the main APP client uses the user credential authToken as a user credential when interaction is performed;
step 502, when a user clicks a sub-application module, the main APP client checks a sub-application authorization mode through the configured sub-application information, judges that the main application client is authorized by an authToken, and jumps to a sub-application jump URL in the sub-application information;
step 503, the master APP starts JavaScript to obtain the authority of the user certificate authToken;
step 504, the front end of the sub-application acquires a user credential authToken of the main APP through JavaScript interaction;
step 505, the front end of the sub-application carries the user credentials authToken to access the sub-application server;
step 506, the sub-application server accesses the Redis database in step 501 through the user certificate authToken to acquire the corresponding user information;
step 507, the sub-application server uses the user information to generate a login credential, and returns the login credential to the front end of the sub-application;
and 508, receiving the login credentials by the front end of the sub-application, and normally processing the business of the same user, so that the authorization process of the authToken is finished.
And 6, performing custom authorization. The custom authorization is a special custom authorization mode, a complete docking scheme of the main APP and the sub application module is formed, and the main APP is required to be docked in a reverse authorization mode. When the custom authorization is performed, a specific docking mode is specified through an expansion field in the sub-application information, and flexible configuration is achieved while customization is performed.
Claims (3)
1. A method for user silence authorization, comprising the steps of:
step 1, before a sub application module accesses a main APP:
the main APP server configures vendor information of a vendor where the sub application module is located in a database, generates a random character string consumerId, SM2 asymmetric encryption public key and an SM2 asymmetric encryption private key which are uniquely corresponding to the vendor, and stores the random character string consumerId, SM asymmetric encryption public key and the SM2 asymmetric encryption private key in the database, wherein: the random character string consumerId and the SM2 asymmetric encryption public key consumerKey are provided for the sub-application server side to use; the manufacturer information at least comprises a manufacturer server IP;
the method comprises the steps that a main APP server side configures sub-application information of a sub-application module in a database, 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 concsmerId; the sub-application authorization modes comprise an authCode authorization, an authToken authorization and a custom authorization, wherein the custom authorization self-defines a specific docking mode of the main APP and the sub-application module through an expansion field;
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 mode through the configured sub-application information:
if in step 1, the main APP server configures the authorization mode of the sub application module in the database as authCode authorization, then the step 4 is skipped; if in step 1, the main APP server configures the sub-application authorization mode of the sub-application module in the database as authToken authorization, then the step 5 is skipped; if in step 1, the main APP server configures a custom authorization mode of the sub application module in the database, then the step 6 is skipped;
step 4, performing authCode authorization, which specifically comprises the following steps:
step 401, a main APP client applies for an access authorization code from a main APP server with a user credential of a current user and a sub-application ID configured in sub-application information;
step 402, the main APP server obtains the corresponding user ID through the user credential 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 of Redis mapping, returns the generated random character string to the main APP client as an access authorization code, and sets the expiration time of the access authorization code in the Redis database;
step 403, after the main APP client takes the access authorization code, splicing the access authorization code to a sub-application jump URL in the sub-application information, and loading the sub-application jump URL in a jump manner, wherein the address pointed by the sub-application jump URL is the front-end page of the sub-application;
step 404, the front end page of the sub-application takes the access authorization code spliced after the sub-application jumps to the URL, and the access authorization code is transmitted to the sub-application server;
step 405, after receiving the access authorization code, the sub application server encrypts the random string consumerId generated in step 1 and the current timestamp by using the SM2 asymmetric encryption public key consumerKey generated in step 1 to generate an encrypted string; the sub-application server side carries the encrypted character string and the random character string concremerId of the plaintext to access the main APP server side;
step 406, after receiving the plaintext random character string consumeid and the encrypted character string, the main APP server uses the random character string consumeid to query the associated manufacturer server IP preconfigured in step 1 through the database, and compares whether the random character string consumeid is consistent with the current accessed IP address, thereby identifying whether the access from the white list server is achieved, if so, entering the next step, and if not, rejecting the access;
step 407, the master APP server uses a random character string consumerId to inquire the related SM2 asymmetric encryption private key preset in the step 1 through a database, decrypts the encrypted character string, refuses the access if the decryption fails, further judges whether the current time stamp obtained by decrypting the current time stamp is within a preset time length if the decryption is successful, successfully authenticates the user, and enters the next step if the decryption is not successful, otherwise, fails to authenticate the user, refuses the access;
step 408, the main APP server generates a new SM2 public and private key, stores the new SM2 asymmetric encryption private key affairsSendPrivatekey and a random character string condumerId into a Redis database, randomly generates a character string as a key mapped by Redis, and returns the randomly generated character string as an affairToken, and the new SM2 asymmetric encryption public key as an affairsSendKey to the sub-application server;
step 409, after receiving the affairToken and the affairSendKey fed back by the master APP server by the sub application server accessing the master APP server in step 405, randomly generating a character string as an SM4 encryption key for SM4 encryption, encrypting the access authorization code obtained in step 405 by using SM4, and using the SM4 encryption key generated randomly by SM2 encryption as a parameter I based on the affairSendKey;
step 410, the sub-application server puts the affairToken and the parameter one obtained in step 409 into the http header, and the encrypted access authorization code is put into the http body to access the main APP server;
step 411, after receiving the affairToken, the parameter one, and the encrypted access authorization code, the master APP server:
querying the SM2 asymmetric encryption private key and the random character string consumeid associated with the step 408 through an affairToken;
after decrypting the first parameter, obtaining an SM4 encryption key randomly generated by the sub-application server in step 409;
step 412, the master APP server decrypts the encrypted access authorization code 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 ensured to have 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 association, if so, the next step is continued, otherwise, the feedback weight code is 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 encrypted user information to the sub-APP 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 step 409 to obtain the user information, and the sub-application server uses the user information to generate a login credential and returns the login credential to the front end of the sub-application;
step 417, the front end of the sub-application receives the login credentials, and can normally process the business of the same user, so that the authorization process of the authCode is finished;
step 5, carrying out authToken authorization, which specifically comprises the following steps:
step 501, after a user logs in, a main APP server stores user information into a Redis database, randomly generates a character string as a user credential authToken, returns the character string to a main APP client, and the main APP client uses the user credential authToken as a user credential when interaction is performed;
step 502, when a user clicks a sub-application module, the main APP client checks a sub-application authorization mode through the configured sub-application information, judges that the main application client is authorized by an authToken, and jumps to a sub-application jump URL in the sub-application information;
step 503, the master APP starts JavaScript to obtain the authority of the user certificate authToken;
step 504, the front end of the sub-application acquires a user credential authToken of the main APP through JavaScript interaction;
step 505, the front end of the sub-application carries the user credentials authToken to access the sub-application server;
step 506, the sub-application server accesses the Redis database in step 501 through the user certificate authToken to acquire the corresponding user information;
step 507, the sub-application server uses the user information to generate a login credential, 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 business of the same user, and the authorization process of the authToken is ended;
step 6, performing custom authorization:
and forming a complete docking scheme of the main APP and the sub application module by 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 user silence authorization of claim 1, wherein the vendor information further comprises a vendor name and a vendor profile.
3. The method of claim 1, wherein the sub-application information further comprises 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 in which the sub-application is located, a URL of an icon of the sub-application, a jump mode of the sub-application, and a sub-menu of the sub-application.
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 CN115277130A (en) | 2022-11-01 |
| CN115277130B true 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 (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| 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 | 政采云有限公司 | Authorization verification system and method |
| CN112306978A (en) * | 2020-12-24 | 2021-02-02 | 大汉软件股份有限公司 | Trusted data authorization method, authentication authorization method and service access method |
Family Cites Families (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| GB2474661B (en) * | 2009-10-21 | 2013-09-11 | 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 |
-
2022
- 2022-07-14 CN CN202210824115.7A patent/CN115277130B/en active Active
Patent Citations (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| 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 | 政采云有限公司 | Authorization 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 |
|---|---|
| CN115277130A (en) | 2022-11-01 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CN103685282B (en) | A kind of identity identifying method based on single-sign-on | |
| Neuman et al. | The Kerberos network authentication service (V5) | |
| US8719952B1 (en) | Systems and methods using passwords for secure storage of private keys on mobile devices | |
| CN104798083B (en) | For the method and system of authentication-access request | |
| CN110650011B (en) | Encryption storage method and encryption storage card based on quantum key | |
| CN111901346B (en) | Identity authentication system | |
| CN103220303B (en) | The login method of server and server, authenticating device | |
| IL189131A (en) | Distributed single sign-on service | |
| KR101452708B1 (en) | CE device management server, method for issuing DRM key using CE device management server, and computer readable medium | |
| CN104412273A (en) | Method and system for activation | |
| CN111193743A (en) | Identity authentication method, system and related device of storage system | |
| CN108881153B (en) | Authentication method used to log in | |
| JP7079528B2 (en) | Service provision system and service provision method | |
| CN103905390B (en) | Permission acquisition method, device, electronic equipment and system | |
| CA2553081A1 (en) | A method for binding a security element to a mobile device | |
| JP2016139910A (en) | Authentication system, authentication key management device, authentication key management method and authentication key management program | |
| CN115277130B (en) | User silence authorization method | |
| KR20150005789A (en) | Method for Authenticating by using Certificate | |
| JP2016163198A (en) | File management device, file management system, file management method, and file management program | |
| CN116074129B (en) | Login method and system integrating and compatible with third party authentication | |
| CN115996126B (en) | Information interaction method, application device, auxiliary platform and electronic device | |
| CN115967538B (en) | Security encryption method and device for man-machine cloud terminal of power system | |
| KR101510473B1 (en) | Method and system of strengthening security of member information offered to contents provider | |
| KR20040092031A (en) | Method and apparatus for maintaining the security of contents | |
| CN115348036A (en) | Method and device for issuing certificates based on GBA |
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 |