[go: up one dir, main page]
More Web Proxy on the site http://driver.im/

CN115001714A - Resource access method and device, electronic equipment and storage medium - Google Patents

Resource access method and device, electronic equipment and storage medium Download PDF

Info

Publication number
CN115001714A
CN115001714A CN202210839421.8A CN202210839421A CN115001714A CN 115001714 A CN115001714 A CN 115001714A CN 202210839421 A CN202210839421 A CN 202210839421A CN 115001714 A CN115001714 A CN 115001714A
Authority
CN
China
Prior art keywords
user
signature algorithm
token
user information
resource access
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Granted
Application number
CN202210839421.8A
Other languages
Chinese (zh)
Other versions
CN115001714B (en
Inventor
梁亚舒
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
China Telecom Corp Ltd
Original Assignee
China Telecom Corp Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by China Telecom Corp Ltd filed Critical China Telecom Corp Ltd
Priority to CN202210839421.8A priority Critical patent/CN115001714B/en
Publication of CN115001714A publication Critical patent/CN115001714A/en
Application granted granted Critical
Publication of CN115001714B publication Critical patent/CN115001714B/en
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • 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/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/321—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving a third party or a trusted authority
    • H04L9/3213—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving a third party or a trusted authority using tickets or tokens, e.g. Kerberos
    • 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
    • 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/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3247—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving digital signatures

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 discloses a resource access method and device, electronic equipment and a storage medium, wherein the method comprises the following steps: receiving a resource access request sent by a client; the resource access request carries user information and a user token, and the user token contains a signature algorithm to be verified; determining a target signature algorithm matched with the user information according to a mapping relation between preset user information and the signature algorithm; verifying the signature algorithm to be verified according to the target signature algorithm to obtain a first verification result; and determining whether to respond to the resource access request according to the first verification result. According to the method and the device, the signature algorithm of the user token carried by the resource access request is firstly verified after the resource access request is received, so that the condition that the signature algorithm in the user token is maliciously modified or deleted to forge the token which can bypass signature verification so as to illegally obtain the access resource is avoided, and the information security in the user token transmission process is ensured.

Description

Resource access method and device, electronic equipment and storage medium
Technical Field
The present application relates to the field of character recognition technologies, and in particular, to a resource access method and apparatus, an electronic device, and a storage medium.
Background
JWT (a Json-based open standard) is a Json-based open standard implemented for transferring assertions between network application environments, and is typically used to transfer authenticated user identity information between an identity provider and a service provider to facilitate resource acquisition from a resource server, and may add some additional assertion information necessary for other business logic, and the token may be used directly for authentication or may be encrypted.
The JWT consists of payload, header and signature, and the signature mechanism of the JWT token guarantees the integrity of information on one hand, but also brings great problems on the other hand. The payload and the header information of JWT are public, if the token is maliciously acquired in the transmission process, the signature algorithm in the header can be modified or deleted to forge the token which can bypass the signature verification, and the access resource can be acquired, thereby bringing great security risk to the information system.
Disclosure of Invention
To solve the foregoing technical problem, embodiments of the present application provide a resource access method and apparatus, an electronic device, a computer-readable storage medium, and a computer program product.
According to an aspect of an embodiment of the present application, there is provided a resource access method, including: receiving a resource access request sent by a client; the resource access request carries user information and a user token, and the user token contains a signature algorithm to be verified; determining a target signature algorithm matched with the user information according to a mapping relation between preset user information and the signature algorithm; verifying the signature algorithm to be verified according to the target signature algorithm to obtain a first verification result; and determining whether to respond to the resource access request according to the first verification result.
According to an aspect of an embodiment of the present application, a resource access apparatus includes: the system comprises an acquisition unit, a verification unit and a verification unit, wherein the acquisition unit is used for receiving a resource access request sent by a client, the resource access request carries real-time user information and a user token, and the user token contains a signature algorithm to be verified; the determining unit is used for determining a target signature algorithm matched with the real-time user information according to the mapping relation between the preset user information and the signature algorithm; the verification unit is used for verifying the signature algorithm to be verified based on the target signature algorithm to obtain a verification result; an execution unit to determine whether to respond to the resource access request based on the verification result.
In another exemplary embodiment, before the receiving the resource access request sent by the client, the method further includes: receiving a token acquisition request sent by the client; the token acquisition request carries user information; selecting a signature algorithm corresponding to the user information, and performing associated storage on the user information and the signature algorithm corresponding to the user information to generate a mapping relation between the preset signature algorithm and the user information; and generating the user token according to the user information and the signature algorithm corresponding to the user information.
In another exemplary embodiment, the user information includes a user identification and a login timestamp; the generating the user token according to the user information and the signature algorithm corresponding to the user information includes: generating a user key according to the user identifier, the login timestamp and a pre-stored basic key; wherein, the basic key is a preset key; and generating the user token according to the user key and the signature algorithm.
In another exemplary embodiment, the generating the user token according to the signature algorithm of the user information corresponding to the user information includes: acquiring load data, and performing associated storage on the user information and the load data to generate a mapping relation between preset load data and user information; wherein the load data is data relating to a user and a user token to be generated; and generating the user token according to the load data, the user key and the signature algorithm.
In another exemplary embodiment, the determining whether to respond to the resource access request according to the first verification result further includes: if the first verification result is characterized as passing the verification, determining target load data matched with the user information according to a mapping relation between preset load data and the user information; verifying the load data to be verified according to the target load data to obtain a second verification result; and if the second verification result is characterized in that the verification is passed, responding to the resource access request to allow the client to access the resource.
In another exemplary embodiment, the method further comprises: receiving an invalidation request for the user token sent by the client; acquiring a user key and a basic key corresponding to the user token; the basic key is obtained by presetting, and the user key is obtained by determining according to the basic key; modifying the user key to the base key to invalidate the user token.
In another exemplary embodiment, the modifying the user key into the base key comprises: if the failure request is detected to carry an instant failure instruction, modifying the user key into the basic key according to the instant failure instruction; and the instant invalidation instruction is used for indicating that the user token is immediately invalidated.
According to an aspect of an embodiment of the present application, an electronic device includes: one or more processors; storage means for storing one or more programs which, when executed by the one or more processors, cause the electronic device to implement the resource access method as described above.
According to an aspect of embodiments of the present application, a computer-readable storage medium has stored thereon computer-readable instructions which, when executed by a processor of a computer, cause the computer to execute a resource access method as described above.
According to an aspect of embodiments herein, there is provided a computer program product or computer program comprising computer instructions stored in a computer readable storage medium. The processor of the computer device reads the computer instructions from the computer-readable storage medium, and the processor executes the computer instructions to cause the computer device to perform the resource access method provided in the various alternative embodiments described above.
In the technical scheme provided by the embodiment of the application, before responding to the received resource access request, the carried user token is verified, the token validity of the resource access request is verified, firstly, a target signature algorithm matched with the user information carried by the resource access request is determined through the preset mapping relation between the user information and the signature algorithm, then, the signature algorithm to be verified in the user token is verified according to the target signature algorithm, and whether the resource access request is responded or not is determined according to the verification result. Therefore, due to the mapping relation between the preset user information and the signature algorithm, the signature algorithm of the user token carried by the user token can be verified through the mapping relation between the preset user information and the signature algorithm after the resource access request is received, the condition that the user token which can bypass the signature verification is forged to illegally obtain the access resource by modifying or deleting the signature algorithm in the user token maliciously in the related technology is avoided, and the safety in the transmission process of the user token is ensured.
It is to be understood that both the foregoing general description and the following detailed description are exemplary and explanatory only and are not restrictive of the application.
Drawings
The accompanying drawings, which are incorporated in and constitute a part of this specification, illustrate embodiments consistent with the present application and together with the description, serve to explain the principles of the application. It is obvious that the drawings in the following description are only some embodiments of the application, and that for a person skilled in the art, other drawings can be derived from them without inventive effort. In the drawings:
FIG. 1 is a schematic illustration of an implementation environment to which the present application relates;
FIG. 2 is a flow chart illustrating a method of resource access in accordance with an exemplary embodiment of the present application;
FIG. 3 is a flowchart of a resource access method shown in an exemplary embodiment, illustrating the steps of generating a user token prior to step S201 in the embodiment shown in FIG. 2;
FIG. 4 is a flow chart of step S204 in the embodiment shown in FIG. 2 in an exemplary embodiment;
FIG. 5 is a flow chart illustrating a method of resource access in an exemplary embodiment of the present application;
FIG. 6 is a flow chart illustrating a method of resource access in accordance with an exemplary embodiment of the present application;
fig. 7 is a flowchart of a resource access method shown in an exemplary embodiment, where the step of authenticating the invalidation request and authenticating the carried user token is performed before step S400 in the embodiment shown in fig. 5;
FIG. 8 is a flow chart illustrating a method of resource access in accordance with an exemplary embodiment of the present application;
FIG. 9 is a block diagram illustrating a resource access device in accordance with an exemplary embodiment of the present application;
FIG. 10 is a block diagram of a computer system suitable for use in implementing the electronic device of an embodiment of the present application.
Detailed Description
Reference will now be made in detail to the exemplary embodiments, examples of which are illustrated in the accompanying drawings. When the following description refers to the accompanying drawings, like numbers in different drawings represent the same or similar elements unless otherwise indicated. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with the present application. Rather, they are merely examples of apparatus and methods consistent with certain aspects of the application, as detailed in the appended claims.
The block diagrams shown in the figures are functional entities only and do not necessarily correspond to physically separate entities. I.e. these functional entities may be implemented in the form of software, or in one or more hardware modules or integrated circuits, or in different networks and/or processor means and/or microcontroller means.
The flow charts shown in the drawings are merely illustrative and do not necessarily include all of the contents and operations/steps, nor do they necessarily have to be performed in the order described. For example, some operations/steps may be decomposed, and some operations/steps may be combined or partially combined, so that the actual execution sequence may be changed according to the actual situation.
Reference to "a plurality" in this application means two or more. "and/or" describe the association relationship of the associated objects, meaning that there may be three relationships, e.g., A and/or B may mean: a exists alone, A and B exist simultaneously, and B exists alone. The character "/" generally indicates that the former and latter associated objects are in an "or" relationship.
In the related art, jwt (jsonwebtoken) is an open industry standard that defines a compact, self-contained protocol format for delivering json objects between two communicating parties, where the delivered information can be verified and trusted by digital signatures. The JWT token consists of three parts, a Header, Payload and Signature, and each part is separated by a point of use.
The header includes, among other things, the type of token (i.e., JWT) and the signature algorithm used (e.g., HMACSHA256 or RSA 256). The content of the payload is also a json object, which is where to store valid information, which may store jwt provided off-the-shelf fields such as: iss (issuer), exp (expiration timestamp), sub (user oriented), etc., may also customize the fields. And a visa part for preventing the JWT contents from being tampered. And in the visa part, respectively encoding the head part and the payload part by using base64url to obtain a first part and a second part of the JWT token, connecting the first part and the second part by using a point ". quadrature" after encoding to form a character string, and finally signing by using a signature algorithm selected and declared in the head part to obtain a third part of the JWT token. Only the third part of the three parts of the JWT is encrypted, and the integrity of data can be guaranteed and the identity of a data source can be verified through a digital signature mechanism. This allows the JWT token to have the advantage of being easily scalable based on json' convenient parsing and the ability to customize rich content in the token.
However, since the payload and the header information of JWT are public, if the token is maliciously acquired in the transmission process, the signature algorithm in the header is modified or deleted, the token which can bypass signature verification can be forged, finally, the access resource is illegally acquired when the resource access request is followed, and only the load information loaded in the token is verified when the token is verified, so that a great security risk is brought to the information system.
In order to solve the above problems, embodiments of the present application propose a resource access method and apparatus, an electronic device, and a computer-readable storage medium, which mainly relate to a machine-vision character recognition technology included in an artificial intelligence technology, and will be described in detail below.
Referring first to fig. 1, fig. 1 is a schematic diagram of an implementation environment related to the present application. The implementation environment includes a terminal 10 and a server 20, and communication between the terminal 10 and the server 20 is performed through a wired or wireless network.
The server 20 is configured to verify a user token carried by the resource access request after receiving the resource access request, and verify the token validity of the resource access request, and first determine a target signature algorithm matched with the user information carried by the resource access request through a preset mapping relationship between the user information and the signature algorithm, then verify a signature algorithm to be verified in the user token according to the target signature algorithm, determine whether to respond to the resource access request according to a verification result, and transmit an obtained result of whether to respond to the resource access request to the terminal 10, so that the terminal 10 accesses the resource to the server 20 when receiving a feedback determination response to the resource access request. Compared with the resource access scheme in the prior art, the resource access method provided by the implementation environment can ensure the information security in the user token transmission process.
It should be noted that the terminal 10 in the implementation environment shown in fig. 1 may be any electronic device such as a smart phone, a tablet, a notebook, a computer, etc.; the server 20 may be an independent server, or may be a cloud server that provides basic cloud computing services such as cloud service, cloud database, cloud computing, cloud function, cloud storage, web service, cloud communication, middleware service, domain name service, security service, Content Delivery Network (CDN), big data, and artificial intelligence platform, which is not limited herein.
Fig. 2 is a flowchart illustrating a resource access method according to an exemplary embodiment of the present application. The method can be applied to the implementation environment shown in fig. 1, and is specifically executed by a server side where the server 20 is located in the embodiment environment shown in fig. 1. In other embodiments, the method may be performed by a device in other embodiments, and the embodiment is not limited thereto.
As shown in fig. 2, in an exemplary embodiment, the resource access method may include steps S201 to S204, which are described in detail as follows:
step S201, receiving a resource access request sent by a client; the resource access request carries user information and a user token, and the user token contains a signature algorithm to be verified.
The server receives a resource access request sent by the client, wherein the resource access request is used for requesting the right of resource access from the server by the client. The resource access request carries user information and a user token which are associated with the resource access request, wherein the user information can comprise user names, user accounts, login passwords and other basic information of the user; the user token is a token which is obtained from the server and corresponds to the user information of the client before the client sends the resource access request, and the server verifies the access validity of the client through the user token, so that the user token carried by the resource access request contains a signature algorithm to be verified.
Step S202, determining a target signature algorithm matched with the user information according to the mapping relation between the preset user information and the signature algorithm.
The server stores the mapping relationship between the preset user information and the signature algorithm, and can acquire and store the mapping relationship between the preset user information and the signature algorithm when the server generates the token corresponding to the client in advance, namely, the client which has acquired the user token has the unique and correct signature algorithm corresponding to the mapping relationship between the preset user information and the signature algorithm. Therefore, after a resource access request sent by a client is received and user information carried by the resource access request is acquired, a target signature algorithm matched with the user information can be determined through the user information carried by the resource access request and is used for verifying the signature algorithm to be verified.
Step S203, verifying the signature algorithm to be verified according to the target signature algorithm to obtain a first verification result.
And after determining a target signature algorithm matched with the user information according to the mapping relation between the preset user information and the signature algorithm, acquiring the signature algorithm to be verified from the user token carried by the resource access request. And verifying the signature algorithm to be verified by judging whether the signature algorithm to be verified is consistent with the target signature algorithm or not to obtain a first verification result, wherein if the signature algorithm to be verified is consistent with the target signature algorithm, the first verification result is characterized as passing verification, otherwise, if the signature algorithm to be verified is inconsistent, the first verification result is characterized as failing verification.
And step S204, determining whether to respond to the resource access request according to the first verification result.
And the server side determines whether to respond to the resource access request according to the content represented by the first verification result, if the representation is that the verification is passed, the server side responds to the resource access request and allows the client side to access the resource, and if the representation is that the verification is not passed, the server side returns abnormal information to the client side and refuses to respond to the resource access request.
As can be seen from the above, in the method provided in this embodiment, the user token carried in the resource access request is verified, so as to verify the token validity of the resource access request, first, a target signature algorithm matched with the user information carried in the resource access request is determined through a mapping relationship between preset user information and a signature algorithm stored in the server in advance, then, the consistency of the signature algorithm to be verified in the user token is verified according to the target signature algorithm, and whether the server responds to the resource access request is determined according to an obtained first verification result. Therefore, after the resource access request is received, the signature algorithm of the user token carried by the resource access request is verified through the preset mapping relation between the user information and the signature algorithm, the condition that the signature algorithm in the user token is modified or deleted maliciously to forge the token which can bypass the signature verification so as to illegally obtain the right of accessing the resource is avoided, the safety in the transmission process of the user token is ensured, and the safety risk problems of information leakage and the like are avoided.
Referring to fig. 3, fig. 3 is a flowchart illustrating steps of generating a user token at a server before step S201 in the embodiment shown in fig. 2, in an exemplary embodiment, the resource access method provided by the present application further includes the step. As shown in fig. 3, the step of generating the user token may specifically include steps S301 to S305, and the user token is generated according to the token obtaining request through the steps, which are described in detail as follows:
step S301, receiving a token obtaining request sent by a client.
The client side obtains the user token by sending the token obtaining request to the server side, and the server side needs to generate the user token related to the server side according to the token obtaining request, so that the token obtaining request sent by the client side carries user information, the user token is used for generating the user token, and the token obtaining request also plays a role of identification so that the generated user token corresponds to the client side.
Step S302, selecting a signature algorithm corresponding to the user information, and performing associated storage on the user information and the signature algorithm corresponding to the user information to generate a mapping relation between a preset signature algorithm and the user information.
The server selects a signature algorithm corresponding to the user information, and the selected signature algorithm may include, but is not limited to, a symmetric signature algorithm (HS256) or an asymmetric signature algorithm (RS 256). And associating the selected signature algorithm with the user request carried by the token acquisition request, further storing the association relationship, and generating a mapping relationship between the preset signature algorithm and the user information, wherein the mapping relationship is used for determining a target signature algorithm from the stored mapping relationship between the preset signature algorithm and the user information when the user token of the resource access request is verified and prepared.
The method for selecting the corresponding signature algorithm may be selected according to user requirements, or may be selected according to different signature algorithms corresponding to different user types set in advance, or may be selected according to JWT related specifications, which is not limited herein.
Further, the user information carried by the token obtaining request includes a user identifier and a login timestamp, and step S303 generates a user key according to the user identifier, the login timestamp, and a pre-stored basic key.
And acquiring a user identifier and a login timestamp included in the user information, obtaining and storing a user key in the form of a basic key, the user identifier and the login timestamp, wherein the user key is used for encrypting various data in the process of generating the user token. The basic key mentioned above is a preset key, and may be a key randomly generated by the server in the initialization stage, and is used as the basic key.
Step S304, load data is obtained, the user information and the load data are stored in an associated mode, and a mapping relation between the preset load data and the user information is generated.
Load data for adding to the load part of the token is obtained, the load data refers to data related to the user and the user token to be generated, and may include, but is not limited to, a subject, a token issuer, a party receiving the token, an issuing time of the token, an expiration time of the token, a time when the token is available, an identity of the token, and other custom user information such as a user name. And associating the acquired load data with the user request carried by the token acquisition request, further storing the association relationship, and generating a mapping relationship between the preset load data and the user information.
Step S305 generates a user token according to the load data, the user key, and the signature algorithm.
After the load data, the user key and the signature algorithm are obtained or generated according to the steps, the selected signature algorithm is described in the head part, the obtained load data is added in the load part, the data of the head part and the data of the load part are combined and encrypted through the signature algorithm and the user key to obtain encrypted data written in the visa part, finally the head part, the load part and the visa part are combined to form a character string, each part is separated by a 'so', a whole JWT token object is formed, and a user token corresponding to a token obtaining request sent by a client side is generated.
In addition, it should be noted that, the step of generating and storing the mapping relationship between the preset signature algorithm and the user information may be after selecting the signature algorithm, or may be during or after generating the user token, and this embodiment describes the step in step S302, which is only for easy understanding, and the meaning of the mapping relationship between the preset signature algorithm and the user information may be generated without limiting the implementation sequence of the step to the selection of the signature algorithm; the mapping relationship between the preset load data and the user information may be generated and stored, and may be generated after the load data is acquired, or may be generated at the time of generating the user token or after the user token is generated.
In another embodiment of the present application, before the server selects the corresponding signature algorithm according to the user information carried in the received token acquisition request in step S302, the method further includes a step of performing identity verification on the client user, which may specifically include: acquiring account data, such as an account and a login password, included in the user information, performing identity verification based on the account data, and if the identity verification passes, executing a step S302 of selecting a signature algorithm, and implementing a step of generating a user token; and if the identity authentication is not passed, returning abnormal information to the client and refusing to respond to the token acquisition request.
According to the embodiment provided by the application, the user token matched with the client side is generated according to the token obtaining request, and the mapping relation between the preset signature algorithm and the user information is generated for verifying the user token carried by the resource access request when the resource access request is subsequently received, so that the signature algorithm of the user token can be verified, the safety in the user token transmission process is ensured, and the safety risk problems of information leakage and the like are avoided.
Referring to fig. 4, fig. 4 is a flowchart of step S204 in the embodiment shown in fig. 2 in an exemplary embodiment. As shown in fig. 4, step S204 may include steps S401 to S403, and the load data to be verified contained in the user token is further verified through the above steps, which are described in detail as follows:
step S401, if the first verification result is characterized in that the verification is passed, determining target load data matched with the user information according to the mapping relation between the preset load data and the user information.
If the first verification result is characterized in that the verification is passed, the signature algorithm of the user token is consistent with the determined target signature algorithm, and then the load data of the user token needs to be verified. In this embodiment, load data matched with the user information carried by the resource access request is determined as target load data according to a mapping relationship between preset load data stored in advance and the user information.
And S402, verifying the load data to be verified according to the target load data to obtain a second verification result.
And meanwhile, the server side can also acquire load data to be verified contained in the user token, so that after the target load data is acquired, the load data to be verified is verified by judging whether the load data to be verified is consistent with the target load data or not to obtain a second verification result, if the judgment is consistent, the second verification result is characterized as passing the verification, otherwise, if the judgment is inconsistent, the second verification result is characterized as failing the verification.
Obtaining a second verification result, namely obtaining a signature algorithm to be verified or a target signature algorithm verified by the signature algorithm and a user key corresponding to the signature algorithm to be verified or the target signature algorithm, and extracting head part data and load part load data in the user token; combining and encrypting the head part data and the load part data through the acquired user secret key and a signature algorithm to be verified or a target signature algorithm to obtain new encrypted data, namely a new visa part; and comparing the new visa part with the visa part of the user token carried by the resource access request, and judging whether the new visa part is consistent with the visa part of the user token carried by the resource access request. Therefore, whether the load data part of the user token or even the user key is tampered or not is verified, and the safety in the user token transmission process is guaranteed.
Step S403, if the second verification result is characterized as verification passing, responding to the resource access request to allow the client to perform resource access.
If the second verification result is characterized as verification passing, it indicates that the user token carried by the resource access request passes the verification of the load data again after the verification of the signature algorithm passes, and the server needs to respond to the resource access request to allow the client to access the resource. If the second verification result is characterized in that the verification fails, the server needs to return abnormal information to the client and refuse to respond to the resource access request.
Therefore, in the method provided by the embodiment, the user load information verification is performed on the basis of the correctness of the verification signature algorithm, so that the security of the user token in the transmission process is further ensured, and the problem that the signature verification can be bypassed by forging the token through maliciously modifying or deleting the signature algorithm in the header due to the structure of the token is avoided.
In addition, after the user token generated at the server is sent to the client, the token is independent of the server, even if the sent user token is revoked at the server but the unexpired token may be used maliciously, a great safety risk brought to an information system is further increased, and most of the users acquire a random key to perform invalidation processing on the token when the token needs to be invalidated each time, so that a great amount of random keys need to be stored, and the problem that more computing resources are occupied exists.
Further, referring to fig. 5 for the user token provided in each of the foregoing embodiments, fig. 5 is a flowchart of a resource access method shown in an exemplary embodiment of the present application, and specifically includes steps S501 to S503, where the user token provided in each of the foregoing embodiments is instructed to be a failure request through the foregoing steps, and the following is introduced in detail:
step S501, receiving a failure request for a user token sent by a client.
When a user needs to send a request for offline or logout service and the like through a client, the client sends a failure request aiming at a user token to a server, and the server carries out failure processing on the user token carried by the server and corresponding to the user of the client according to the failure request so as to finish offline or logout service.
Step S502, a user key and a basic key corresponding to the user token are obtained.
The basic key is preset, and the user key is determined according to the basic key. Specifically, when the user token is generated, the user key is obtained in the form of a basic key + a user identifier + a login timestamp, and the user identifier and the login timestamp are obtained from user information. The basic key mentioned above is a preset key, and may be a key randomly generated by the server in the initialization stage, and is used as the basic key.
In step S503, the user key is modified into the basic key to invalidate the user token.
After the user key and the basic key corresponding to the user token are obtained, the user key is modified into the basic key, namely the form of the user key is changed from the basic key, the user identifier and the login timestamp into the form of only the basic key.
Thus, in the embodiment, for the failure instruction of the user token transmission, the user key corresponding to the user token is changed into the basic key, so that the previous user token fails to be valid, the token cannot be used for requesting the next login, and the preset basic key is used for modifying the user key, thereby solving the problem that the calculation resources occupy more resources due to the random generation of the key during the token failure processing, avoiding the revoked user token from being used maliciously, further ensuring the security during the user token transmission process, and avoiding the security risk problems of information leakage and the like.
In another embodiment, the invalidation request further carries an immediate invalidation instruction, as shown in fig. 6, step S503 in the embodiment shown in fig. 5 may specifically be represented as:
step S600, if the failure request is detected to carry the instant failure instruction, the user key is modified into the basic key according to the instant failure instruction.
The instant invalidation command is used for indicating that invalidation processing is immediately carried out on the user token and immediately modifying the user key into the user token invalidation processing of the basic key, so that the user token can be prevented from being maliciously used in a time gap between receiving the invalidation command and implementing the invalidation processing.
Referring to fig. 7, fig. 7 is a flowchart illustrating steps of authenticating a revocation request and authenticating a carried user token in an exemplary embodiment of a resource access method provided by the present application before step S502 in the embodiment shown in fig. 5. As shown in fig. 7, the method may specifically include steps S701 to S704, which are described in detail as follows:
and step S701, performing identity authentication based on the user information carried by the failure request.
Account data, such as an account and a login password, included in user information carried by the invalidation request is obtained, identity verification is performed based on the account data, and the legality of user login is verified immediately.
Step S702, if the identity authentication is passed, determining a target signature algorithm and target load data matched with the user information according to the mapping relation between the preset user information and the signature algorithm and the mapping relation between the preset load data and the user information.
Otherwise, if the identity authentication is not passed, returning abnormal information and refusing to respond to the failure request.
And step S703, sequentially and respectively verifying the signature algorithm and the load of the to-be-invalidated user token carried by the invalidation request based on the target signature algorithm and the target load data to obtain a third verification result.
The server side can also obtain a signature algorithm and load data contained in the user token to be invalidated, so that after the target load data is obtained, the signature algorithm of the user token to be invalidated is verified by judging whether the signature algorithm is consistent with the target signature algorithm or not, and if the signature algorithm is not verified, a third verification result is characterized as not passing; and if the signature algorithm passes the verification, verifying the load data of the user token to be failed according to whether the load data is consistent with the target load data, if so, representing that the third verification result is passed, otherwise, representing that the third verification result is failed.
And step S704, if the third verification result is characterized in that the verification is passed, responding to the invalidation request, and carrying out invalidation processing on the user token.
If the third verification result is characterized as passing, executing the steps of the embodiment shown in fig. 5 to perform failure processing on the user token; and if the third verification result is characterized as failing, returning abnormal information and refusing to respond to the failure request.
Therefore, by the method of the embodiment, before the user token is subjected to invalidation processing according to the invalidation request, the validity of the user token is verified sequentially through the signature algorithm and the load data, so that the condition that the token which can bypass signature verification is forged through maliciously modifying or deleting the signature algorithm in the user token so as to illegally and even maliciously invalidate the token is avoided, and the safety in the transmission process of the user token is ensured.
Referring to fig. 8, fig. 8 is a flowchart of a resource access method provided in the present application in an exemplary embodiment, which may include steps S801 to S811 as follows:
step S801, receiving a token acquisition request sent by a client.
Step S802, performing identity authentication according to the user information carried by the token acquisition request, and judging whether the identity authentication passes, if the identity authentication passes, skipping to step S803, and if the identity authentication does not pass, skipping to step S811.
Step S803, selecting a signature algorithm, generating a user key according to the user information and the basic key, acquiring load data, and generating a user token according to the load data, the user key, and the signature algorithm.
Step S804, storing a mapping relationship between the preset user information and the signature algorithm and a mapping relationship between the preset load data and the user information.
Step S805, receiving a resource access request carrying user information and a user token sent by a client.
Step S806, receiving an invalidation request for the user token sent by the client.
Step S807, a target signature algorithm matched with the user information is determined according to the mapping relation between the preset user information and the signature algorithm, the signature algorithm to be verified is verified according to the target signature algorithm to obtain a first verification result, whether the first verification result is characterized to be passed or not is judged, if the first verification result is characterized to be passed, the step S808 is skipped, and if the first verification result is not passed, the step S811 is skipped.
Step S808, determining target load data matched with the user information according to the mapping relation between the preset load data and the user information, verifying the load data to be verified according to the target load data to obtain a second verification result, judging whether the second verification result is characterized as passing or not, and if the second verification result is characterized as passing and the received resource access request is received, jumping to step S809; if the failure request is received and passed, the process goes to step S810, and if not, the process goes to step S811.
Step S809, responding to the resource access request to allow the client to perform resource access.
Step S810, modify the user key into the basic key to invalidate the user token.
Step S811 returns the abnormality information and rejects the response request.
In the embodiment, when the user token is generated, the mapping relation between the preset user information and the signature algorithm and the mapping relation between the preset load data and the user information are stored, and the mapping relations are used for sequentially verifying the signature algorithm and the load data when the resource access request or the invalidation request is received, so that the condition that the signature algorithm in the user token is maliciously modified or deleted to forge the token which can bypass the signature verification, thereby illegal and even malicious invalidation tokens is avoided, and the safety in the user token transmission process is ensured.
Fig. 9 is a block diagram illustrating a resource access device 900 according to an exemplary embodiment of the present application. As shown in fig. 9, the apparatus includes:
an obtaining unit 901, configured to receive a resource access request sent by a client, where the resource access request carries real-time user information and a user token, and the user token contains a signature algorithm to be verified;
a determining unit 902, configured to determine, according to a mapping relationship between preset user information and a signature algorithm, a target signature algorithm matched with real-time user information;
the verification unit 903 is used for verifying the signature algorithm to be verified based on the target signature algorithm to obtain a verification result;
and an execution unit 904, configured to determine whether to respond to the resource access request based on the verification result.
After the resource access request sent by the client is received by the obtaining unit 901, the determining unit 902 determines a target signature algorithm matched with the user information carried in the resource access request through a mapping relation between preset user information stored in the server in advance and the signature algorithm, the verifying unit 903 verifies the consistency of the signature algorithm to be verified in the user token according to the target signature algorithm, and finally the executing unit 904 determines whether the server responds to the resource access request according to the obtained first verification result. Therefore, the signature algorithm of the user token carried by the resource access request is verified through the preset mapping relation between the user information and the signature algorithm, the signature algorithm in the user token is prevented from being maliciously modified or deleted, the safety in the transmission process of the user token is ensured, and the safety risk problems of information leakage and the like are avoided.
In another exemplary embodiment, the apparatus further comprises:
the token generation unit is used for receiving a token acquisition request sent by a client; selecting a signature algorithm corresponding to the user information, and performing associated storage on the user information and the signature algorithm corresponding to the user information to generate a mapping relation between a preset signature algorithm and the user information; generating a user key according to the user identifier, the login timestamp and a pre-stored basic key; acquiring load data, and performing associated storage on user information and the load data to generate a mapping relation between preset load data and the user information; and generating a user token according to the load data, the user key and the signature algorithm.
In another exemplary embodiment, the verification unit 903 is further configured to determine, if the first verification result is characterized as that the verification passes, target load data matched with the user information according to a mapping relationship between preset load data and the user information; verifying the load data to be verified according to the target load data to obtain a second verification result; and if the second verification result is characterized in that the verification is passed, responding to the resource access request to allow the client to access the resource.
In another exemplary embodiment, the apparatus further comprises:
the token invalidation unit is used for receiving an invalidation request aiming at the user token sent by the client; acquiring a user key and a basic key corresponding to a user token; the basic key is obtained by presetting, and the user key is obtained by determining according to the basic key; the user key is modified to the base key to invalidate the user token.
In another exemplary embodiment, the token invalidation unit is further configured to modify the user key into the basic key according to the immediate invalidation instruction if it is detected that the invalidation request carries the immediate invalidation instruction; the instant invalidation instruction is used for indicating that invalidation processing is carried out on the user token immediately.
It should be noted that the resource access apparatus provided in the foregoing embodiment and the resource access method provided in the foregoing embodiment belong to the same concept, and specific ways for the modules and units to perform operations have been described in detail in the method embodiment, and are not described herein again. In practical applications, the resource access device provided in the foregoing embodiment may allocate the above functions to different functional modules according to needs, that is, the internal structure of the device is divided into different functional modules to complete all or part of the above described functions, which is not limited herein.
An embodiment of the present application further provides an electronic device, including: one or more processors; the storage device is used for storing one or more programs, and when the one or more programs are executed by one or more processors, the electronic equipment is enabled to realize the resource access method provided in the above embodiments.
FIG. 10 illustrates a schematic structural diagram of a computer system suitable for use in implementing the electronic device of an embodiment of the present application. It should be noted that the computer system 1000 of the electronic device shown in fig. 10 is only an example, and should not bring any limitation to the functions and the scope of use of the embodiments of the present application.
As shown in fig. 10, the computer system 1000 includes a Central Processing Unit (CPU)1001, which can perform various appropriate actions and processes, such as executing the method in the above-described embodiment, according to a program stored in a Read-only memory (ROM) 1002 or a program loaded from a storage portion 1008 into a Random Access Memory (RAM) 1003. In the RAM1003, various programs and data necessary for system operation are also stored. The CPU1001, ROM1002, and RAM1003 are connected to each other via a bus 1004. An Input/Output (I/O) interface 1005 is also connected to the bus 1004.
The following components are connected to the I/O interface 1005: an input section 1006 including a keyboard, a mouse, and the like; an output section 1007 including a display such as a Cathode Ray Tube (CRT), a Liquid Crystal Display (LCD), and a speaker; a storage portion 1008 including a hard disk and the like; and a communication portion 1009 including a network interface card such as a LAN (local area network) card, a modem, and the like. The communication section 1009 performs communication processing via a network such as the internet. The driver 1010 is also connected to the I/O interface 1005 as necessary. A removable medium 1011 such as a magnetic disk, an optical disk, a magneto-optical disk, a semiconductor memory, or the like is mounted on the drive 1010 as necessary, so that a computer program read out therefrom is mounted into the storage section 1008 as necessary.
In particular, according to embodiments of the application, the processes described above with reference to the flow diagrams may be implemented as computer software programs. For example, embodiments of the present application include a computer program product comprising a computer program embodied on a computer readable medium, the computer program comprising a computer program for performing the method illustrated by the flow chart. In such an embodiment, the computer program may be downloaded and installed from a network through the communication part 1009 and/or installed from the removable medium 1011. When the computer program is executed by a Central Processing Unit (CPU)1001, various functions defined in the system of the present application are executed.
It should be noted that the computer readable medium shown in the embodiments of the present application may be a computer readable signal medium or a computer readable storage medium or any combination of the two. The computer readable storage medium may be, for example, an electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any combination of the foregoing. More specific examples of the computer readable storage medium may include, but are not limited to: an electrical connection having one or more wires, a portable computer diskette, a hard disk, a Random Access Memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM), a flash memory, an optical fiber, a portable compact disc read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination of the foregoing. In the present application, a computer-readable signal medium may include a propagated data signal with a computer program embodied therein, for example, in baseband or as part of a carrier wave. Such a propagated data signal may take any of a variety of forms, including, but not limited to, electro-magnetic, optical, or any suitable combination thereof. A computer readable signal medium may also be any computer readable medium that is not a computer readable storage medium and that can communicate, propagate, or transport a program for use by or in connection with an instruction execution system, apparatus, or device. The computer program embodied on the computer readable medium may be transmitted using any appropriate medium, including but not limited to: wireless, wired, etc., or any suitable combination of the foregoing.
The flowchart and block diagrams in the figures illustrate the architecture, functionality, and operation of possible implementations of systems, methods and computer program products according to various embodiments of the present application. Each block in the flowchart or block diagrams may represent a module, segment, or portion of code, which comprises one or more executable instructions for implementing the specified logical function(s). It should also be noted that, in some alternative implementations, the functions noted in the block may occur out of the order noted in the figures. For example, two blocks shown in succession may, in fact, be executed substantially concurrently, or the blocks may sometimes be executed in the reverse order, depending upon the functionality involved. It will also be noted that each block of the block diagrams or flowchart illustration, and combinations of blocks in the block diagrams or flowchart illustration, can be implemented by special purpose hardware-based systems which perform the specified functions or acts, or combinations of special purpose hardware and computer instructions.
The units described in the embodiments of the present application may be implemented by software, or may be implemented by hardware, and the described units may also be disposed in a processor. Wherein the names of the elements do not in some way constitute a limitation on the elements themselves.
Yet another aspect of the present application provides a computer-readable storage medium having stored thereon a computer program which, when executed by a processor, implements the foregoing resource access method. The computer-readable storage medium may be included in the electronic device described in the above embodiment, or may exist separately without being incorporated in the electronic device.
Another aspect of the application also provides a computer program product or computer program comprising computer instructions stored in a computer readable storage medium. The processor of the computer device reads the computer instructions from the computer-readable storage medium, and the processor executes the computer instructions, so that the computer device executes the resource access method provided in the above embodiments.
The present invention is not intended to be limited to the particular embodiments shown and described, but is to be accorded the widest scope consistent with the principles and novel features herein disclosed.

Claims (10)

1. A method for accessing resources, comprising:
receiving a resource access request sent by a client; the resource access request carries user information and a user token, and the user token contains a signature algorithm to be verified;
determining a target signature algorithm matched with the user information according to a mapping relation between preset user information and a signature algorithm;
verifying the signature algorithm to be verified according to the target signature algorithm to obtain a first verification result;
and determining whether to respond to the resource access request according to the first verification result.
2. The method of claim 1, wherein prior to receiving the resource access request sent by the client, the method further comprises:
receiving a token acquisition request sent by the client; the token acquisition request carries user information;
selecting a signature algorithm corresponding to the user information, and performing associated storage on the user information and the signature algorithm corresponding to the user information to generate a mapping relation between the preset signature algorithm and the user information;
and generating the user token according to the user information and the signature algorithm corresponding to the user information.
3. The method of claim 2, wherein the user information comprises a user identification and a login timestamp; the generating the user token according to the user information and the signature algorithm corresponding to the user information includes:
generating a user key according to the user identifier, the login timestamp and a pre-stored basic key; wherein, the basic key is a preset key;
and generating the user token according to the user key and the signature algorithm.
4. The method of claim 3, wherein the generating the user token according to the signature algorithm of the user information corresponding to the user information comprises:
acquiring load data, and performing associated storage on the user information and the load data to generate a mapping relation between preset load data and user information; wherein the load data is data relating to a user and a user token to be generated;
and generating the user token according to the load data, the user key and the signature algorithm.
5. The method according to any one of claims 1 to 4, wherein the user token further contains load data to be verified, and the determining whether to respond to the resource access request according to the first verification result comprises:
if the first verification result is characterized as passing the verification, determining target load data matched with the user information according to a mapping relation between preset load data and the user information;
verifying the load data to be verified according to the target load data to obtain a second verification result;
and if the second verification result is characterized in that the verification is passed, responding to the resource access request to allow the client to access the resource.
6. The method according to any one of claims 1 to 4, further comprising:
receiving an invalidation request for the user token sent by the client;
acquiring a user key and a basic key corresponding to the user token; the basic key is obtained by presetting, and the user key is obtained by determining according to the basic key;
modifying the user key to the base key to invalidate the user token.
7. The method of claim 6, wherein modifying the user key into the base key comprises:
if the failure request is detected to carry an instant failure instruction, modifying the user key into the basic key according to the instant failure instruction; the instant invalidation instruction is used for indicating that invalidation processing is immediately carried out on the user token.
8. A resource access apparatus, comprising:
the system comprises an acquisition unit, a verification unit and a verification unit, wherein the acquisition unit is used for receiving a resource access request sent by a client, the resource access request carries real-time user information and a user token, and the user token contains a signature algorithm to be verified;
the determining unit is used for determining a target signature algorithm matched with the real-time user information according to the mapping relation between the preset user information and the signature algorithm;
the verification unit is used for verifying the signature algorithm to be verified based on the target signature algorithm to obtain a verification result;
an execution unit to determine whether to respond to the resource access request based on the verification result.
9. An electronic device, comprising:
one or more processors;
storage means for storing one or more programs which, when executed by the one or more processors, cause the electronic device to implement the resource access method of any of claims 1 to 7.
10. A computer-readable storage medium having stored thereon computer-readable instructions which, when executed by a processor of a computer, cause the computer to perform the resource access method of any one of claims 1 to 7.
CN202210839421.8A 2022-07-15 2022-07-15 Resource access method and device, electronic equipment and storage medium Active CN115001714B (en)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN202210839421.8A CN115001714B (en) 2022-07-15 2022-07-15 Resource access method and device, electronic equipment and storage medium

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN202210839421.8A CN115001714B (en) 2022-07-15 2022-07-15 Resource access method and device, electronic equipment and storage medium

Publications (2)

Publication Number Publication Date
CN115001714A true CN115001714A (en) 2022-09-02
CN115001714B CN115001714B (en) 2024-03-19

Family

ID=83022323

Family Applications (1)

Application Number Title Priority Date Filing Date
CN202210839421.8A Active CN115001714B (en) 2022-07-15 2022-07-15 Resource access method and device, electronic equipment and storage medium

Country Status (1)

Country Link
CN (1) CN115001714B (en)

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN115963808A (en) * 2022-12-30 2023-04-14 阿波罗智联(北京)科技有限公司 Method, device, electronic equipment and storage medium for remotely controlling vehicle
CN117650950A (en) * 2024-01-30 2024-03-05 浙江省电子信息产品检验研究院(浙江省信息化和工业化融合促进中心) Secure communication method and apparatus

Citations (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN107251477A (en) * 2015-02-11 2017-10-13 维萨国际服务协会 System and method for safely managing biometric data
CN108965230A (en) * 2018-05-09 2018-12-07 深圳市中信网安认证有限公司 A kind of safety communicating method, system and terminal device
US20190273620A1 (en) * 2017-07-18 2019-09-05 Zhongan Information Technology Service Co., Ltd. Data sharing method and data sharing system
CN110311782A (en) * 2019-04-29 2019-10-08 山东工商学院 Zero-knowledge proof method, system and the storage medium of personal information
CN110784457A (en) * 2019-10-17 2020-02-11 中诚信征信有限公司 Service access method and device
CN114244530A (en) * 2021-12-16 2022-03-25 中国电信股份有限公司 Resource access method and device, electronic equipment and computer readable storage medium
CN114528571A (en) * 2022-02-11 2022-05-24 京东科技信息技术有限公司 Resource access and data processing method, device, electronic equipment and medium

Patent Citations (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN107251477A (en) * 2015-02-11 2017-10-13 维萨国际服务协会 System and method for safely managing biometric data
US20190273620A1 (en) * 2017-07-18 2019-09-05 Zhongan Information Technology Service Co., Ltd. Data sharing method and data sharing system
CN108965230A (en) * 2018-05-09 2018-12-07 深圳市中信网安认证有限公司 A kind of safety communicating method, system and terminal device
CN110311782A (en) * 2019-04-29 2019-10-08 山东工商学院 Zero-knowledge proof method, system and the storage medium of personal information
CN110784457A (en) * 2019-10-17 2020-02-11 中诚信征信有限公司 Service access method and device
CN114244530A (en) * 2021-12-16 2022-03-25 中国电信股份有限公司 Resource access method and device, electronic equipment and computer readable storage medium
CN114528571A (en) * 2022-02-11 2022-05-24 京东科技信息技术有限公司 Resource access and data processing method, device, electronic equipment and medium

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN115963808A (en) * 2022-12-30 2023-04-14 阿波罗智联(北京)科技有限公司 Method, device, electronic equipment and storage medium for remotely controlling vehicle
CN117650950A (en) * 2024-01-30 2024-03-05 浙江省电子信息产品检验研究院(浙江省信息化和工业化融合促进中心) Secure communication method and apparatus
CN117650950B (en) * 2024-01-30 2024-04-19 浙江省电子信息产品检验研究院(浙江省信息化和工业化融合促进中心) Secure communication method and apparatus

Also Published As

Publication number Publication date
CN115001714B (en) 2024-03-19

Similar Documents

Publication Publication Date Title
US12095932B2 (en) Digital certificate verification method and apparatus, computer device, and storage medium
CN108259438B (en) Authentication method and device based on block chain technology
JP2021526341A (en) Digital certificate management methods, devices, computer devices and computer programs
CN112073400A (en) Access control method, system and device and computing equipment
US11539526B2 (en) Method and apparatus for managing user authentication in a blockchain network
US20230370265A1 (en) Method, Apparatus and Device for Constructing Token for Cloud Platform Resource Access Control
CN112165382B (en) Software authorization method and device, authorization server side and terminal equipment
CN112202705A (en) Digital signature verification generation and verification method and system
CN110943844B (en) Electronic document security signing method and system based on local service of webpage client
CN115001714B (en) Resource access method and device, electronic equipment and storage medium
CN112446050B (en) Business data processing method and device applied to block chain system
CN115967508A (en) Data access control method and device, equipment, storage medium and program product
CN112311779B (en) Data access control method and device applied to block chain system
CN113032837A (en) Anonymous authentication method and system for open platform
CN115150072B (en) Cloud network issuing authentication method, equipment, device and storage medium
CN108449568A (en) Identity identifying method and device for video conference
CN116975901A (en) Identity verification method, device, equipment, medium and product based on block chain
CN115460019A (en) Method, apparatus, device and medium for providing digital identity-based target application
CN110276693B (en) Insurance claim settlement method and system
CN113328854A (en) Service processing method and system based on block chain
CN114710362B (en) Identity authentication method and device based on block chain and electronic equipment
CN116647345A (en) Method and device for generating permission token, storage medium and computer equipment
CN113014540B (en) Data processing method, device, equipment and storage medium
CN118410469B (en) Application verification method and device
US20230224309A1 (en) Method and system for digital identity and transaction verification

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