CN113971292A - Authorization method and related device - Google Patents
Authorization method and related device Download PDFInfo
- Publication number
- CN113971292A CN113971292A CN202111248137.5A CN202111248137A CN113971292A CN 113971292 A CN113971292 A CN 113971292A CN 202111248137 A CN202111248137 A CN 202111248137A CN 113971292 A CN113971292 A CN 113971292A
- Authority
- CN
- China
- Prior art keywords
- application program
- authorization
- token
- service request
- client
- 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.)
- Pending
Links
- 238000013475 authorization Methods 0.000 title claims abstract description 146
- 238000000034 method Methods 0.000 title claims abstract description 60
- 238000013507 mapping Methods 0.000 claims description 12
- 238000000605 extraction Methods 0.000 claims description 5
- 238000010586 diagram Methods 0.000 description 9
- 150000003839 salts Chemical class 0.000 description 4
- 230000008878 coupling Effects 0.000 description 3
- 238000010168 coupling process Methods 0.000 description 3
- 238000005859 coupling reaction Methods 0.000 description 3
- 238000012545 processing Methods 0.000 description 3
- 238000004891 communication Methods 0.000 description 2
- 238000013461 design Methods 0.000 description 2
- 238000011161 development Methods 0.000 description 2
- 238000005516 engineering process Methods 0.000 description 2
- 230000002159 abnormal effect Effects 0.000 description 1
- 230000009286 beneficial effect Effects 0.000 description 1
- 230000005540 biological transmission Effects 0.000 description 1
- 230000001186 cumulative effect Effects 0.000 description 1
- 230000006870 function Effects 0.000 description 1
- 238000012986 modification Methods 0.000 description 1
- 230000004048 modification Effects 0.000 description 1
- 230000003287 optical effect Effects 0.000 description 1
- 230000001960 triggered effect Effects 0.000 description 1
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
- G06F21/60—Protecting data
- G06F21/602—Providing cryptographic facilities or services
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
- G06F21/60—Protecting data
- G06F21/604—Tools and structures for managing or administering access control systems
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F2221/00—Indexing scheme relating to security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
- G06F2221/21—Indexing scheme relating to G06F21/00 and subgroups addressing additional information or applications relating to security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
- G06F2221/2141—Access rights, e.g. capability lists, access control lists, access tables, access matrices
Landscapes
- Engineering & Computer Science (AREA)
- Theoretical Computer Science (AREA)
- Software Systems (AREA)
- General Health & Medical Sciences (AREA)
- Computer Hardware Design (AREA)
- Computer Security & Cryptography (AREA)
- Health & Medical Sciences (AREA)
- Physics & Mathematics (AREA)
- General Engineering & Computer Science (AREA)
- General Physics & Mathematics (AREA)
- Bioethics (AREA)
- Automation & Control Theory (AREA)
- Storage Device Security (AREA)
Abstract
The application discloses an authorization method and a related device, wherein the authorization method comprises the following steps: the method comprises the steps that a client receives an access instruction for accessing an application program installed on the client, and a token is generated according to the security authority of the application program; and sending the token, the unique code of the application program and the service request corresponding to the access instruction to a server side, so that the server side judges whether the service request can pass the authorization according to the unique code of the application program and the token. Through the mode, the complexity can be reduced on the premise of ensuring the safety.
Description
Technical Field
The present application belongs to the field of computer technology, and in particular, relates to an authorization method and a related apparatus.
Background
With the development of 5G services, cloud-edge systems are more and more popular. In some application scenarios, the server side is required to authenticate the application program so that the server side can service the service request from the application program.
Currently, the traditional authorization methods include the following two methods: firstly, the server side gives an authorization file, and the client side loads the authorization file, so that the scheme is good in safety and tedious; secondly, the server outputs the authorization code, and the client uses the authorization code to request the server. Namely, the existing authorization scheme has the problem that the security and the convenience cannot be compatible.
Disclosure of Invention
The application provides an authorization method and a related device, so as to reduce complexity on the premise of ensuring security.
In order to solve the technical problem, the application adopts a technical scheme that: there is provided an authorization method comprising: the method comprises the steps that a client receives an access instruction for accessing an application program installed on the client, and a token is generated according to the security authority of the application program; and sending the token, the unique code of the application program and the service request corresponding to the access instruction to a server side, so that the server side judges whether the service request can pass the authorization according to the unique code of the application program and the token.
In order to solve the technical problem, the application adopts a technical scheme that: there is provided an authorization method comprising: the server receives a token, the unique code of the application program and a service request sent by the client; the token is generated according to the security authority of the application program, and the service request is related to an access instruction for accessing the application program installed on the client; and judging whether the service request can pass the authorization according to the unique code of the application program and the token.
In order to solve the above technical problem, another technical solution adopted by the present application is: there is provided an authorization method comprising: the method comprises the steps that a client receives an access instruction for accessing an application program installed on the client, and the client generates a token according to the security authority of the application program; the client sends the token, the unique code of the application program and the service request corresponding to the access instruction to a server; and the server side judges whether the service request can pass the authorization according to the unique code of the application program and the token.
In order to solve the above technical problem, another technical solution adopted by the present application is: the authorization device is applied to a client and comprises: the extraction module is used for receiving an access instruction for accessing an application program installed on a client and generating a token according to the security authority of the application program; and the sending module is used for sending the token, the unique code of the application program and the service request corresponding to the access instruction to a server side so that the server side can judge whether the service request can pass the authorization according to the unique code of the application program and the token.
In order to solve the above technical problem, the present application adopts another technical solution: the authorization device is applied to a server side and comprises: the receiving module is used for receiving the token sent by the client, the unique code of the application program and the service request; the token is generated according to the security authority of the application program, and the service request is related to an access instruction for accessing the application program installed on the client; and the judging module is used for judging whether the service request can pass the authorization according to the unique code of the application program and the token.
In order to solve the above technical problem, the present application adopts another technical solution: there is provided an electronic device comprising a memory and a processor coupled to each other, the memory having stored therein program instructions, the processor being configured to execute the program instructions to implement the authorization method described in any of the above embodiments.
In order to solve the above technical problem, the present application adopts another technical solution: there is provided a memory device storing program instructions executable by a processor for implementing the authorisation method described in any one of the embodiments above.
Being different from the prior art situation, the beneficial effect of this application is: according to the authorization method, after a client receives an access instruction for accessing an application program installed in the client, the client generates a token according to the security authority of the application program; the token, the unique code of the application program and the service request related to the access instruction can be sent to the server side, so that the server side judges whether the service request can pass the authorization according to the unique code of the application program and the token. The client can obtain the authorization without the authorization file of the server, and the convenience is high; in addition, the token is generated according to the security authority of the application program, so that the security of the authorization process is ensured as much as possible.
Drawings
In order to more clearly illustrate the technical solutions in the embodiments of the present application, the drawings needed to be used in the description of the embodiments are briefly introduced below, it is obvious that the drawings in the following description are only some embodiments of the present application, and other drawings can be obtained by those skilled in the art without inventive efforts, wherein:
FIG. 1 is a schematic flow chart diagram illustrating an embodiment of a client-based authorization method according to the present application;
FIG. 2 is a flowchart illustrating an embodiment of a server-side based authorization method according to the present application;
FIG. 3 is a flowchart illustrating an embodiment corresponding to step S202 in FIG. 2;
FIG. 4 is a schematic flow chart illustrating another embodiment corresponding to step S201 in FIG. 2;
FIG. 5 is a flowchart illustrating an embodiment of an authorization method based on a client and a server according to the present application;
FIG. 6 is a schematic structural diagram of an embodiment of an authorization apparatus applied to a client according to the present application;
FIG. 7 is a schematic structural diagram of an embodiment of an authorization apparatus applied to a server side according to the present application;
FIG. 8 is a schematic structural diagram of an embodiment of an electronic device according to the present application;
fig. 9 is a schematic structural diagram of an embodiment of a memory device according to the present application.
Detailed Description
The technical solutions in the embodiments of the present application will be clearly and completely described below with reference to the drawings in the embodiments of the present application, and it is obvious that the described embodiments are only a part of the embodiments of the present application, and not all of the embodiments. All other embodiments, which can be derived by a person skilled in the art from the embodiments given herein without making any creative effort, shall fall within the protection scope of the present application.
Referring to fig. 1, fig. 1 is a schematic flowchart illustrating an embodiment of a client-based authorization method according to the present application, where the authorization method includes:
s101: the client receives an access instruction for accessing the application program installed in the client, and generates a token according to the security authority of the application program.
Specifically, in this embodiment, the client may be a terminal such as a mobile phone or a computer, and the client may download one or more application programs from an application store in advance, where the application programs may be from one or more companies. And different applications have a unique encoded appid. For example, the unique code appid of an application of the tenderer bank is 001, the unique code appid of another application of the tenderer bank is 002, the unique code appid of an application of the industrial and commercial banks is 003, etc. In addition, the same application program can be suitable for a plurality of user groups, and different user groups can have different security rights; for example, users at the employee level may only have access to data information related to their work content when using the application, while users at the leader level may have access to data information related to their work content and to work content under them when using the application. Therefore, the same application program facing different user groups can be provided with different security rights.
In an application scenario, when company a signs an agreement with company B, and company a provides some services, such as voice services, for a plurality of application programs flagged by company B, a server side located at company a generates one or more pairs of security rights for the application program (e.g., application program with api of 002, etc.); alternatively, each pair of security rights may comprise a pair of key secret _ key and key code secret _ id, the key code secret _ id of different security rights being different. When an application developer located in or serving for company B develops the application program, the server notifies all security permissions generated for the application program to the application developer, and the application developer directly writes the security permissions into parameter information of the application program in an application development stage.
Further, when an application has multiple pairs of security rights, application developers can respectively develop an application corresponding to the security rights for different user groups, and at this time, the parameter information in the application downloaded by the user through some channels only includes a pair of security rights. Alternatively, the application developer may develop only one application program, and the parameter information of the application program includes all security rights. In the subsequent use process, the application program can match the corresponding security authority according to the account information input by the user.
In another application scenario, when a user triggers a function related to an application program from a desktop of a client, for the client, the client receives an access instruction for accessing the application program, and then the client generates a corresponding service request according to the access instruction; optionally, in this embodiment, the access instruction may include not only a login instruction for logging in the current application program, but also another instruction triggered after logging in the current application program. For example, the access instruction may be a login instruction, a file download instruction, and the like of the application program; accordingly, the service request may be a login request of an application program, a file download request, and the like. Further, the client obtains the security authority of the application program, and generates a corresponding token by using the security authority.
Optionally, in this embodiment, the step of generating, by the client, a token according to the security authority of the application in step S101 includes: splicing the secret key secret _ key, the secret key code secret _ id and the random number salt to form a string of values; encrypting the string value to generate a token; the encryption method may be any one of the existing technologies, for example, HMAC-SHA 256. Specifically, the control layer at the client transmits the key secret _ key and the key code secret _ id of the security authority of the application to the basic software development kit sdk in advance; each time an application is accessed, the underlying software development kit sdk generates a random number salt, e.g., a 10-byte random number, etc.; meanwhile, the basic software development kit sdk concatenates the key secret _ key, the key code secret _ id, and the random number salt into a new string of values, and then encrypts the string of values to generate the token. The token generating mode is simple and easy to implement.
In some cases, there may be some small probability that when tokens are generated in the manner described in the above embodiments, the tokens from different clients may be the same, which may result in a service request from one of the clients being unacceptable. In order to avoid this situation, the implementation manner of the token generated by the client according to the security authority of the application in step S101 may be other, for example, the token may be generated according to the security authority of the application and the device information of the client. Optionally, in this embodiment, the device information of the client includes a device code device _ id of the client. In general, the device code device _ id of the client is unique; because the device information of the client is added when the token is generated, the probability that the token tokens generated by different clients are the same can be greatly reduced, so that the probability of abnormal authorization is reduced. Specifically, the step of generating the token according to the security authority of the application and the device information of the client includes: splicing the secret key secret _ key, the secret key code secret _ id, the equipment code device _ id and the random number salt to form a string of values; the string value is encrypted to generate a token. The token generating mode is simple and easy to implement.
S102: and sending the token, the unique code appid of the application program and the service request corresponding to the access instruction to the server side, so that the server side judges whether the service request can pass the authorization according to the unique code appid of the application program and the token.
Specifically, in this embodiment, the content mentioned in step S102 may be transmitted to the server side through the head segment of the https protocol, and the transmission manner is mature. The process of determining whether the service request can pass the authorization according to the unique code and the token of the application program by the specific server side will be described in detail in the following embodiments. When the server side judges that the service request can pass the authorization, the server side sends a result related to the service request back to the client side; and when the server side judges that the service request can not pass the authorization, the server side refuses the service request.
In the design mode, the client can obtain the authorization without an authorization file of the server, and the convenience is high; in addition, the token is generated according to the security authority of the application program, so that the security of the authorization process is ensured as much as possible.
In addition, in another embodiment, in the step S102, the token, the unique code appid of the application, the service request corresponding to the access instruction, and the key code secret _ id may be sent to the server side together, so that the server side determines whether the service request can pass the authorization according to the unique code appid of the application, the token, and the key code secret _ id, so as to improve the security in the authorization process. The process of determining whether the service request can pass the authorization by the specific server side will be described in detail in the following embodiments.
Referring to fig. 2, fig. 2 is a schematic flowchart illustrating an embodiment of a server-side based authorization method according to the present application, where the authorization method includes:
s201: the server receives a token, a unique code appid of an application program and a service request sent by the client; the token is generated according to the security authority of the application program, and the service request is related to an access instruction for accessing the application program installed on the client.
Specifically, in this embodiment, the process of generating the token by the client may refer to the foregoing embodiment, and is not described herein again.
S202: and judging whether the service request can pass the authorization according to the unique code appid and the token of the application program.
In one embodiment, please refer to fig. 3, fig. 3 is a flowchart illustrating an embodiment corresponding to step S202 in fig. 2, where the step S202 specifically includes:
s301: it is determined whether a token already exists in the cache.
Specifically, in this embodiment, the server may query whether the token has been cached from the cache.
S302: if so, the service request is judged to be incapable of passing the authorization.
Specifically, if the token already exists in the cache of the server, it indicates that the service request is repeated, and the service request is rejected. The process of the steps S301 to S302 can prevent the server from allowing multiple sets of accesses to the same client, and prevent the reentry attack started after the network packet capturing. In addition, if the token does not exist in the cache of the server, the token can be added into the cache; and when the service request corresponding to a certain token in the cache of the server passes the authorization, the server returns the result related to the service request, and the token can be removed from the cache.
S303: otherwise, decrypting the token to obtain the security authority of the application program; and obtaining the pre-stored information of the application program from the permission mapping table according to the unique code appid of the application program.
Specifically, if the token does not exist in the cache of the server, it indicates that the service request is legal, and the subsequent steps may be performed. In addition, when the token is decrypted, the decryption algorithm used is matched with the encryption algorithm used by the previous client, and the encryption algorithm and the decryption algorithm used can be agreed in advance by the client and the server. By decrypting the token, the security rights of the application can be obtained, for example, the key secret _ key and the key code secret _ id can be parsed out.
In addition, in this embodiment, the server side may store an authority mapping table in advance, where the authority mapping table may include the unique code appid of each application and all corresponding security authority information (that is, the pre-stored information includes all key codes secret _ id and key secret _ key), and in step S303, the server side may search and obtain the pre-stored information related to the application from the authority mapping table by using the received unique code appid of the application.
S304: and judging whether the pre-stored information contains the decrypted security authority.
S305: if yes, the service request is judged to pass the authorization.
Specifically, if the pre-stored information includes the decrypted security permission, it indicates that the service request is legal. Correspondingly, simultaneously with step S305, otherwise, it is determined that the service request cannot pass the authorization, and step S302 is entered.
In another embodiment, in some cases, for example, company a has an agreement with company B, and company a provides voice services for several applications under the flag of company B, the server side of company a responds to the voice service request received from the application under the flag of company B and provides the services. At this time, the server side of company a needs to verify whether the received service request is from APP flagged by company B, and needs to control the total amount to ensure that the total authorization limit is not exceeded. At this time, referring to fig. 4, fig. 4 is a schematic flowchart illustrating another embodiment corresponding to step S201 in fig. 2, where step S202 specifically includes:
s401: it is determined whether a token already exists in the cache.
Specifically, this step is the same as step S301 in the above embodiment, and is not described in detail here.
S402: if so, the service request is judged to be incapable of passing the authorization.
S403: otherwise, decrypting the token to obtain the security authority of the application program; and obtaining the pre-stored information of the application program from the permission mapping table according to the unique code appid of the application program.
Specifically, this step is the same as step S303 in the above embodiment, and is not described in detail here.
S404: and judging whether the pre-stored information contains the decrypted security authority.
Specifically, this step is the same as step S304 in the above embodiment, and is not described in detail here.
S405: if yes, obtaining the maximum authorization number according to the unique code appid of the application program.
Specifically, if the pre-stored information contains the decrypted security permission, it indicates that the service request is legal; it is further possible to obtain the pre-stored maximum authorization number from its memory area based on the received unique code appid of the application. Alternatively, the maximum authorization number may be the maximum authorization number for a period of time, such as daily or monthly or year round. In some cases, the maximum authorization numbers corresponding to different security authorities of the same application may be different, and in this case, the step S405 specifically includes obtaining the maximum authorization number according to the unique code appid of the application and the key code secret _ id obtained by decryption. Certainly, in some cases, the maximum authorization number may also be related to the service request, for example, the maximum authorization number corresponding to the file downloading request and the reading request may be different, and in this case, the step S405 specifically includes obtaining the corresponding maximum authorization number according to the unique code appid of the application program, the key code secret _ id obtained by decryption, and the service request; or, the corresponding maximum authorization number is obtained according to the unique code appid of the application program and the service request.
S406: it is determined whether the number of times that authorization has been passed is greater than or equal to a maximum number of authorizations.
Specifically, when performing step S406, the processor may obtain the number of times that the application program has passed the authorization from the storage area; wherein the application has been associated with the setting of the maximum number of authorizations in a cumulative manner over the number of authorizations. For example, when the maximum authorization number is the maximum authorization number per day, the number of times the application has passed authorization is also accumulated in days. For another example, when the maximum number of grants is associated with a security right of an application, then the number of times the application has passed the grants accumulates corresponds to the security right.
S407: if not, the service request is judged to pass the authorization, and the number of times of passing the authorization is increased by one.
Specifically, after determining that the current service request passes the authorization, the server may respond to the service request and return a result related to the service request to the application program of the client.
In addition, simultaneously with step S407, if the number of times that the current application has passed the authorization is greater than or equal to the maximum authorization number, the service request is rejected, and it is determined that the service request cannot pass the authorization.
In another embodiment, when the server side further receives a key code secret _ id sent by the client side, before or after the step of determining whether the pre-stored information includes the decrypted security right in the above two embodiments, the method may further include: judging whether the received secret key code secret _ id is the same as the secret key code secret _ id obtained after the token is decrypted; if yes, entering a step of judging whether the pre-stored information contains the decrypted security authority; otherwise, the service request is judged to be incapable of passing the authorization. The above design can further improve the security of the authorization process. In some cases, the key secret _ key and the key code secret _ id used in generating the token may be incorrect, and at this time, the key secret _ id and the key code secret _ id used in generating the token may be confirmed by the server side in a manner of transmitting the key code secret _ id and the token to the server side at the same time, so as to reduce the probability of occurrence of an authorization exception.
Optionally, in this embodiment, before the step S201, the authorization method provided by the present application includes:
A. and setting the maximum authorization number and at least one security right of each application program.
B. And generating a permission mapping table by using the unique code appid of the application program and all corresponding security permissions. Of course, the maximum authorization number may also be included in the authorization mapping table at this time. Alternatively, the unique code appid of the application and the corresponding maximum authorization number can be used to generate the authorization mapping table for subsequent query.
C. And sending the security permission corresponding to the application program to a terminal of an application program developer so that the application program developer writes the security permission into the parameter information of the application program.
Referring to fig. 5, fig. 5 is a schematic flowchart illustrating an embodiment of an authorization method based on a client and a server according to the present application, where the authorization method specifically includes:
s501: the client receives an access instruction for accessing the application program installed in the client, and the client generates a token according to the security authority of the application program.
Specifically, step S501 is the same as step S101 in the above embodiment, and details are not repeated.
S502: and the client sends the token, the unique code appid of the application program and the service request corresponding to the access instruction to the server.
Specifically, step S502 is the same as step S102 in the above embodiment, and details are not repeated.
S503: and the server side judges whether the service request can pass the authorization or not according to the unique code appid and the token of the application program.
Specifically, step S503 is the same as step S202 in the above embodiment, and details are not repeated.
Referring to fig. 6, fig. 6 is a schematic structural diagram of an authorization device applied to a client according to an embodiment of the present application. The authorization apparatus comprises an extraction module 10 and a sending module 12. The extraction module 10 is configured to receive an access instruction for accessing an application installed on a client, and generate a token according to a security authority of the application; the sending module 12 is connected to the extracting module 10, and is configured to send the token, the unique code of the application program, and the service request corresponding to the access instruction to the server, so that the server determines whether the service request can pass the authorization according to the unique code of the application program and the token.
Specifically, the process of generating the token according to the security authority of the application program in the extraction module 10 includes: and generating a token according to the security authority of the application program and the device information of the client.
Optionally, the security rights of the application include a key and a key encoding in pair; the device information of the client comprises a device code of the client; the step of generating the token according to the security authority of the application program and the device information of the client comprises the following steps: splicing the secret key, the secret key code, the equipment code and the random number to form a string of values; the string value is encrypted to generate a token.
In addition, the sending module 12 may send the token, the unique code of the application program, and the service request corresponding to the access instruction to the server, and send the key code to the server at the same time, so that the server determines whether the service request can pass the authorization according to the token, the unique code of the application program, and the key code.
Referring to fig. 7, fig. 7 is a schematic structural diagram of an embodiment of an authorization apparatus applied to a server side according to the present application, where the authorization apparatus includes a receiving module 20 and a determining module 22. The receiving module 20 is configured to receive a token sent by a client, a unique code of an application program, and a service request; and the token is generated according to the security authority of the application program, and the service request is related to an access instruction for accessing the application program installed in the client. The determination module 22 is connected to the receiving module 20 and is used for determining whether the service request can pass the authorization according to the unique code and the token of the application program.
Optionally, in this embodiment, the determining module 22 is specifically configured to: judging whether a token already exists in the cache; if so, judging that the service request cannot pass the authorization; otherwise, decrypting the token to obtain the security authority of the application program; obtaining pre-stored information of the application program from the permission mapping table according to the unique code of the application program; judging whether the pre-stored information contains the decrypted security authority; if so, judging that the service request passes the authorization; otherwise, the service request is judged to be incapable of passing the authorization.
In one embodiment, before the step of determining that the service request passes the authorization, the method includes: obtaining a maximum authorization number according to the unique code of the application program; judging whether the number of times of passing the authorization is larger than or equal to the maximum authorization number or not; if so, judging that the service request cannot pass the authorization; otherwise, entering the step of judging that the service request passes the authorization, and adding one to the number of times of passing the authorization.
In another embodiment, the security authority of the application program comprises a key and a key code which are paired, and the token is formed by splicing and encrypting the key, the key code, the device code of the client and a random value; the receiving module 20 is further configured to receive a key code sent by the client, where before the step of determining whether the pre-stored information includes the decrypted security right, the determining module 22 includes: judging whether the received key code is the same as the key code obtained after the token is decrypted; if yes, entering a step of judging whether the pre-stored information contains the decrypted security authority; otherwise, the service request is judged to be incapable of passing the authorization.
In addition, please refer to fig. 7, the authorization apparatus further includes a setting module 24, the setting module 24 is connected to the determining module 22, and the setting module 24 is specifically configured to set a maximum authorization number and at least one security right of each application; and generating a permission mapping table by using the unique code of the application program and all corresponding security permissions.
Further, please refer to fig. 7, the authorization apparatus further includes a sending module 26, connected to the setting module 24, for sending the security right corresponding to the application program to a terminal of an application program developer, so that the application program developer writes the security right into the parameter information of the application program. Of course, the sending module 26 may also be connected to the determining module 22, and is used for sending the result related to the application request to the application program of the client when the determining module 22 determines that the current application request can pass the authorization.
Referring to fig. 8, fig. 8 is a schematic structural diagram of an embodiment of an electronic device according to the present application, where the electronic device specifically includes: a memory 30 and a processor 32 coupled to each other, the memory 30 storing program instructions, and the processor 32 executing the program instructions to implement the steps of any of the above authorization methods. Specifically, electronic devices include, but are not limited to: desktop computers, notebook computers, tablet computers, servers, etc., without limitation thereto. Further, the processor 32 may also be referred to as a CPU (Central Processing Unit). The processor 32 may be an integrated circuit chip having signal processing capabilities. The Processor 32 may also be a general purpose Processor, a Digital Signal Processor (DSP), an Application Specific Integrated Circuit (ASIC), a Field Programmable Gate Array (FPGA) or other Programmable logic device, discrete Gate or transistor logic, discrete hardware components. A general purpose processor may be a microprocessor or the processor may be any conventional processor or the like. In addition, the processor 32 may be commonly implemented by an integrated circuit chip.
Referring to fig. 9, fig. 9 is a schematic structural diagram of an embodiment of a storage device 50 of the present application, in which program instructions 52 capable of being executed by a processor are stored, and the program instructions 52 are used for implementing steps in any one of the authorization methods.
In the several embodiments provided in the present application, it should be understood that the disclosed method and apparatus may be implemented in other ways. For example, the above-described apparatus embodiments are merely illustrative, and for example, a division of a module or a unit is merely a logical division, and an actual implementation may have another division, for example, a plurality of units or components may be combined or integrated into another system, or some features may be omitted, or not executed. In addition, the shown or discussed mutual coupling or direct coupling or communication connection may be an indirect coupling or communication connection of devices or units through some interfaces, and may be in an electrical, mechanical or other form.
Units described as separate parts may or may not be physically separate, and parts displayed as units may or may not be physical units, may be located in one place, or may be distributed on a plurality of network units. Some or all of the units can be selected according to actual needs to achieve the purpose of the embodiment.
In addition, functional units in the embodiments of the present application may be integrated into one processing unit, or each unit may exist alone physically, or two or more units are integrated into one unit. The integrated unit can be realized in a form of hardware, and can also be realized in a form of a software functional unit.
The integrated unit, if implemented in the form of a software functional unit and sold or used as a stand-alone product, may be stored in a computer readable storage medium. Based on such understanding, the technical solution of the present application may be substantially implemented or contributed to by the prior art, or all or part of the technical solution may be embodied in a software product, which is stored in a storage medium and includes instructions for causing a computer device (which may be a personal computer, a server, a network device, or the like) or a processor (processor) to execute all or part of the steps of the method according to the embodiments of the present application. And the aforementioned storage medium includes: a U-disk, a removable hard disk, a Read-Only Memory (ROM), a Random Access Memory (RAM), a magnetic disk or an optical disk, and other various media capable of storing program codes.
The above description is only an example of the present application and is not intended to limit the scope of the present application, and all modifications of equivalent structures and equivalent processes, which are made by the contents of the specification and the drawings, or which are directly or indirectly applied to other related technical fields, are intended to be included within the scope of the present application.
Claims (14)
1. An authorization method, comprising:
the method comprises the steps that a client receives an access instruction for accessing an application program installed on the client, and a token is generated according to the security authority of the application program;
and sending the token, the unique code of the application program and the service request corresponding to the access instruction to a server side, so that the server side judges whether the service request can pass the authorization according to the unique code of the application program and the token.
2. The authorization method according to claim 1, characterized in that the step of generating a token according to the security rights of the application comprises:
and generating a token according to the security authority of the application program and the equipment information of the client.
3. The authorization method according to claim 2,
the security authority of the application program comprises a key and a key code which are paired; the device information of the client comprises a device code of the client;
the step of generating a token according to the security right of the application program and the device information of the client comprises: splicing the secret key, the secret key code, the equipment code and the random number to form a string of values; encrypting the string value to generate the token.
4. The authorization method according to claim 3, wherein the step of sending the token, the unique code of the application program and the service request corresponding to the access instruction to a server side includes:
and sending the token, the unique code of the application program, the service request corresponding to the access instruction and the key code to the server side together.
5. An authorization method, comprising:
the server receives a token, the unique code of the application program and a service request sent by the client; the token is generated according to the security authority of the application program, and the service request is related to an access instruction for accessing the application program installed on the client;
and judging whether the service request can pass the authorization according to the unique code of the application program and the token.
6. The authorization method according to claim 5, wherein the step of determining whether the service request can be authorized according to the unique code of the application program comprises:
judging whether the token exists in a cache or not;
if yes, judging that the service request cannot pass the authorization;
otherwise, decrypting the token to obtain the security authority of the application program; obtaining pre-stored information of the application program from a permission mapping table according to the unique code of the application program;
judging whether the pre-stored information contains the decrypted safety authority or not;
if yes, judging that the service request passes the authorization;
otherwise, the service request is judged to be incapable of passing the authorization.
7. The authorization method according to claim 6, wherein the step of determining that the service request is authorized comprises:
obtaining a maximum authorization number according to the unique code of the application program;
judging whether the number of times of passing the authorization is larger than or equal to the maximum authorization number or not;
if yes, judging that the service request cannot pass the authorization;
otherwise, entering the step of judging that the service request passes the authorization, and adding one to the number of times of passing the authorization.
8. The authorization method according to claim 6,
the security authority of the application program comprises a key and a key code which are paired, and the token is formed by splicing and encrypting the key, the key code, the equipment code of the client and a random value;
the server side further receives the key code sent by the client side, and before the step of judging whether the pre-stored information contains the decrypted security right, the method comprises the following steps:
judging whether the received secret key code is the same as the secret key code obtained after the token is decrypted;
if yes, entering the step of judging whether the pre-stored information contains the decrypted safety permission;
otherwise, the service request is judged to be incapable of passing the authorization.
9. The authorization method according to claim 7, characterized in that the step of receiving the token sent by the client, the unique code of the application program and the service request at the server side is preceded by the following steps:
setting the maximum authorization number and at least one security authority of each application program;
generating the permission mapping table by using the unique code of the application program and all the corresponding safety permissions;
and sending the security permission corresponding to the application program to a terminal of an application program developer so that the application program developer writes the security permission into parameter information of the application program.
10. An authorization method, comprising:
the method comprises the steps that a client receives an access instruction for accessing an application program installed on the client, and the client generates a token according to the security authority of the application program;
the client sends the token, the unique code of the application program and the service request corresponding to the access instruction to a server;
and the server side judges whether the service request can pass the authorization according to the unique code of the application program and the token.
11. An authorization apparatus, applied to a client, includes:
the extraction module is used for receiving an access instruction for accessing an application program installed on a client and generating a token according to the security authority of the application program;
and the sending module is used for sending the token, the unique code of the application program and the service request corresponding to the access instruction to a server side so that the server side can judge whether the service request can pass the authorization according to the unique code of the application program and the token.
12. An authorization device, applied to a server, includes:
the receiving module is used for receiving the token sent by the client, the unique code of the application program and the service request; the token is generated according to the security authority of the application program, and the service request is related to an access instruction for accessing the application program installed on the client;
and the judging module is used for judging whether the service request can pass the authorization according to the unique code of the application program and the token.
13. An electronic device comprising a memory and a processor coupled to each other, the memory having stored therein program instructions, the processor being configured to execute the program instructions to implement the authorization method of any of claims 1 to 10.
14. A storage device storing program instructions executable by a processor to perform the method of any one of claims 1 to 10.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202111248137.5A CN113971292A (en) | 2021-10-26 | 2021-10-26 | Authorization method and related device |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202111248137.5A CN113971292A (en) | 2021-10-26 | 2021-10-26 | Authorization method and related device |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| CN113971292A true CN113971292A (en) | 2022-01-25 |
Family
ID=79588412
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN202111248137.5A Pending CN113971292A (en) | 2021-10-26 | 2021-10-26 | Authorization method and related device |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN113971292A (en) |
Citations (4)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN104869102A (en) * | 2014-02-24 | 2015-08-26 | 腾讯科技（北京）有限公司 | Authorization method, device and system based on xAuth protocols |
| CN111093197A (en) * | 2019-12-31 | 2020-05-01 | 北大方正集团有限公司 | Authority authentication method, authority authentication system and computer readable storage medium |
| CN112422477A (en) * | 2019-08-21 | 2021-02-26 | 普天信息技术有限公司 | Service authentication method, server, electronic device and storage medium |
| CN112565293A (en) * | 2020-12-23 | 2021-03-26 | 平安养老保险股份有限公司 | Information security management method and device, computer equipment and readable storage medium |
-
2021
- 2021-10-26 CN CN202111248137.5A patent/CN113971292A/en active Pending
Patent Citations (4)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN104869102A (en) * | 2014-02-24 | 2015-08-26 | 腾讯科技（北京）有限公司 | Authorization method, device and system based on xAuth protocols |
| CN112422477A (en) * | 2019-08-21 | 2021-02-26 | 普天信息技术有限公司 | Service authentication method, server, electronic device and storage medium |
| CN111093197A (en) * | 2019-12-31 | 2020-05-01 | 北大方正集团有限公司 | Authority authentication method, authority authentication system and computer readable storage medium |
| CN112565293A (en) * | 2020-12-23 | 2021-03-26 | 平安养老保险股份有限公司 | Information security management method and device, computer equipment and readable storage medium |
Non-Patent Citations (2)
| Title |
|---|
| 指间: "OAuth2.0协议原理与实现：Token生成策略", pages 1 - 4, Retrieved from the Internet <URL:https://www.zhenchao.io/2017/03/11/protocol/oauth-v2-token/> * |
| 指间: "OAuth2.0协议原理与实现：协议原理", pages 1 - 10, Retrieved from the Internet <URL:https://www.zhenchao.io/2017/03/04/protocol/oauth-v2-principle/> * |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CN111429254B (en) | Business data processing method and device and readable storage medium | |
| US11295565B2 (en) | Secure smart unlocking | |
| CN110417750B (en) | Block chain technology-based file reading and storing method, terminal device and storage medium | |
| TWI782255B (en) | Unlocking method, device for realizing unlocking, and computer-readable medium | |
| EP2956852B1 (en) | Data security service | |
| CN110445840B (en) | File storage and reading method based on block chain technology | |
| US11102204B1 (en) | Agreement and enforcement of rules for a shared resource | |
| CN110908786A (en) | A smart contract calling method, device and medium | |
| CN110598429B (en) | Method, terminal device and storage medium for encrypted storage and reading of data | |
| CN109302442B (en) | Data storage proving method and related equipment | |
| CN115473655B (en) | Terminal authentication method, device and storage medium for access network | |
| CN105491058A (en) | API access distributed authorization method and system | |
| CN110708162B (en) | Resource acquisition method and device, computer readable medium and electronic equipment | |
| CN112423302B (en) | Wireless network access method, terminal and wireless access equipment | |
| CN107040501B (en) | Authentication method and device based on platform as a service | |
| CN104994498B (en) | The method and system that a kind of terminal applies are interacted with mobile phone card application | |
| WO2025020651A1 (en) | Data generation method, data processing method, data sending method, communication system, electronic terminal and storage medium | |
| CN115086428B (en) | Network request sending method and device and electronic equipment | |
| CN113971292A (en) | Authorization method and related device | |
| Park et al. | An efficient motion estimation method for QTBT structure in JVET future video coding | |
| CN111031075B (en) | Network service security access method, terminal, system and readable storage medium | |
| CN117997519A (en) | Data processing method, apparatus, program product, computer device, and medium | |
| CN113010908B (en) | Safe storage method suitable for large-capacity SIM card | |
| CN114024682A (en) | Cross-domain single sign-on method, service equipment and authentication equipment | |
| CN113194090A (en) | Authentication method, authentication device, terminal device and computer readable storage medium |
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 |