CN112787986B - Multi-path bidirectional authentication method and device - Google Patents
Multi-path bidirectional authentication method and device Download PDFInfo
- Publication number
- CN112787986B CN112787986B CN201911096818.7A CN201911096818A CN112787986B CN 112787986 B CN112787986 B CN 112787986B CN 201911096818 A CN201911096818 A CN 201911096818A CN 112787986 B CN112787986 B CN 112787986B
- Authority
- CN
- China
- Prior art keywords
- access
- resource path
- reverse proxy
- client certificate
- proxy server
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Active
Links
- 238000000034 method Methods 0.000 title claims abstract description 47
- 230000002457 bidirectional effect Effects 0.000 title claims abstract description 28
- 238000012795 verification Methods 0.000 claims abstract description 54
- 238000010200 validation analysis Methods 0.000 claims 3
- 230000009471 action Effects 0.000 description 8
- 239000002699 waste material Substances 0.000 description 6
- 230000008569 process Effects 0.000 description 4
- 238000010586 diagram Methods 0.000 description 3
- 230000006870 function Effects 0.000 description 3
- 230000004048 modification Effects 0.000 description 3
- 238000012986 modification Methods 0.000 description 3
- 230000005540 biological transmission Effects 0.000 description 2
- 230000003287 optical effect Effects 0.000 description 2
- 238000012545 processing Methods 0.000 description 2
- 230000008859 change Effects 0.000 description 1
- 230000006872 improvement Effects 0.000 description 1
- 230000007246 mechanism Effects 0.000 description 1
- 239000003607 modifier Substances 0.000 description 1
- 239000007787 solid Substances 0.000 description 1
- 230000003068 static effect Effects 0.000 description 1
- 238000012546 transfer Methods 0.000 description 1
Images
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L63/00—Network architectures or network communication protocols for network security
- H04L63/02—Network architectures or network communication protocols for network security for separating internal from external traffic, e.g. firewalls
- H04L63/0281—Proxies
-
- 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/08—Network architectures or network communication protocols for network security for authentication of entities
- H04L63/0823—Network architectures or network communication protocols for network security for authentication of entities using certificates
-
- 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/08—Network architectures or network communication protocols for network security for authentication of entities
- H04L63/0869—Network architectures or network communication protocols for network security for authentication of entities for achieving mutual authentication
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/01—Protocols
- H04L67/02—Protocols based on web technology, e.g. hypertext transfer protocol [HTTP]
Landscapes
- Engineering & Computer Science (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Computer Hardware Design (AREA)
- Computer Security & Cryptography (AREA)
- Computing Systems (AREA)
- General Engineering & Computer Science (AREA)
- Computer And Data Communications (AREA)
Abstract
The application discloses a multi-path bidirectional authentication method and a device, wherein the method comprises the following steps: storing the corresponding relation between each resource path and a client certificate allowing to access the resource path in a back-end server in advance; when a client requests to access the resource path from a reverse proxy server and passes the bidirectional authentication with the reverse proxy server, the reverse proxy server sends an access verification message to the back-end server, wherein the access verification message comprises the client certificate and the resource path requested to be accessed; the back-end server matches the client certificate and the resource path requested to access contained in the access verification message with the corresponding relation between the pre-stored resource path and the corresponding client certificate allowing to access the resource path, and if the matching is successful, the verification is passed.
Description
Technical Field
This description relates to the internet field.
Background
https mutual authentication is a mechanism for solving secure transmission on the internet, but the current standard practice is only to perform mutual authentication for a certain domain name, that is, no matter which client is, as long as the client possesses a client certificate under the domain name, all resources under the domain name can be accessed, and there is a limitation on hierarchical management of resources.
Further, the current authentication method can only solve the management of multiple resources and paths by applying more domain names and client certificates, which results in resource waste and lower management efficiency.
Disclosure of Invention
The present specification provides a multi-path mutual authentication method and apparatus, which can more effectively manage different resource paths under the same domain name, and avoid resource waste.
The application discloses a multi-path bidirectional authentication method, which comprises the following steps:
storing the corresponding relation between each resource path and a client certificate allowing to access the resource path in a back-end server in advance;
when a client requests to access the resource path from a reverse proxy server and passes the bidirectional authentication with the reverse proxy server, the reverse proxy server sends an access verification message to the back-end server, wherein the access verification message comprises the client certificate and the resource path requested to be accessed; and
and the back-end server matches the client certificate and the resource path requested to be accessed, which are contained in the access verification message, with the corresponding relation between the pre-stored resource path and the corresponding client certificate allowing the resource path to be accessed, and if the matching is successful, the verification is passed.
In a preferred embodiment, in the step of matching, by the back-end server, the client certificate included in the access verification message, and the resource path requested to be accessed with the correspondence between the pre-stored resource path and the corresponding client certificate allowed to access the resource path, if the matching is successful, the verification is passed, and if the matching is unsuccessful, a message passing the verification is returned to the reverse proxy server, otherwise, a 401http error code is returned to the reverse proxy server.
In a preferred embodiment, when the client requests the reverse proxy server to access the resource path and passes the bidirectional authentication with the reverse proxy server, the reverse proxy server sends an access verification message to the backend server, including the following sub-steps:
the client requests the reverse proxy server to access the resource path;
and the reverse proxy server and the client perform bidirectional authentication, and if the reverse proxy server passes the bidirectional authentication, the reverse proxy server sends an access verification message to the back-end server, wherein the access verification message comprises the client certificate and a resource path requesting access.
In a preferred embodiment, the http request header of the access authentication message contains the client certificate.
In a preferred embodiment, the http request header of the access authentication message further contains one or any combination of the following: requested method, URI, protocol version, customer information.
In a preferred embodiment, the method further comprises the following steps:
storing the effective time of the corresponding relation between each resource path and a client certificate allowing to access the resource path in a back-end server in advance; and is provided with
When the back-end server matches the client certificate contained in the access verification message and the resource path requested to be accessed with the corresponding relation between the pre-stored resource path and the corresponding client certificate allowed to access the resource path, the back-end server also matches the current time with the effective time, and if the current time is not within the effective time, an error code is returned to the reverse proxy server.
In a preferred example, the correspondence between each resource path and the client certificate that allows access to the resource path is stored in a database of the back-end server.
The application also discloses a multipath mutual authentication device includes:
the storage module is used for storing the corresponding relation between each resource path and the client certificate which is allowed to access the resource path in the back-end server in advance;
a verification message sending module, configured to send an access verification message to the backend server when a client requests the reverse proxy server to access the resource path and passes bidirectional authentication with the reverse proxy server, where the access verification message includes the client certificate and the resource path requested to be accessed; and
and the matching module is used for matching the client certificate and the resource path requested to be accessed, which are contained in the access verification message, with the corresponding relation between the pre-stored resource path and the corresponding client certificate which allows the resource path to be accessed, and if the matching is successful, the verification is passed.
The application also discloses a multi-path mutual authentication device includes:
a memory for storing computer executable instructions; and (c) a second step of,
a processor for implementing the steps in the method as described above when executing the computer executable instructions.
The present application also discloses a computer-readable storage medium having stored thereon computer-executable instructions which, when executed by a processor, implement the steps in the method as described above.
The multi-path bidirectional authentication method and device provided by the specification can more effectively manage different resource paths under the same domain name, and avoid resource waste.
A large number of technical features are described in the specification, and are distributed in various technical solutions, so that the specification is too long if all possible combinations of the technical features (namely, the technical solutions) in the application are listed. In order to avoid this problem, the respective technical features disclosed in the above summary of the invention of the present specification, the respective technical features disclosed in the following embodiments and examples, and the respective technical features disclosed in the drawings may be freely combined with each other to constitute various new technical solutions (which should be regarded as having been described in the present specification) unless such a combination of the technical features is technically impossible. For example, in one example, feature a + B + C is disclosed, in another example, feature a + B + D + E is disclosed, and features C and D are equivalent technical means that serve the same purpose, technically only one feature is used, but not both, and feature E may be technically combined with feature C, then the solution of a + B + C + D should not be considered as already described because the technology is not feasible, and the solution of a + B + C + E should be considered as already described.
Drawings
Fig. 1 is a schematic flowchart of a multipath bidirectional authentication method according to a first embodiment of the present description;
fig. 2 is a system diagram of a multi-path mutual authentication method according to a first embodiment of the present specification:
fig. 3 is a schematic configuration diagram of a multipath bidirectional authentication device according to a second embodiment of the present specification.
Detailed Description
In the following description, numerous technical details are set forth in order to provide a better understanding of the present application. However, it will be understood by those skilled in the art that the technical solutions claimed in the present application may be implemented without these technical details and with various changes and modifications based on the following embodiments.
Embodiments of the present description will be described in further detail below with reference to the accompanying drawings.
The applicant finds that the current authentication method can only solve the management of multiple resources and paths by applying more domain names and client certificates, which results in the waste of resources and has low management efficiency, and therefore, a new multi-path bidirectional authentication method is provided, which has the core idea at least comprising: the method comprises the steps that the corresponding relation between each resource path under the same domain name and a client certificate allowing to access the resource path is stored in advance, when a client passes the bidirectional authentication with a reverse proxy server, the reverse proxy server sends an access verification message to a back-end server, the message carries the client certificate and the resource path requesting to access, and the back-end server verifies the client certificate and the resource path requesting to access again according to the corresponding relation between the pre-stored resource path and the corresponding client certificate allowing to access the resource path. Therefore, different resource paths under the same domain name are managed differently, resource waste is effectively avoided, and resource path management efficiency is improved.
A first embodiment of the present specification relates to a multi-path mutual authentication method, a flow of which is shown in fig. 1, and a system diagram of which is shown in fig. 2. Specifically, the method comprises the steps of:
step 101: the correspondence between each resource path and the client certificate that is allowed to access the resource path is stored in the back-end server in advance.
Note that, in the embodiment of the present specification, the public network server includes a reverse proxy server and a backend server. Specifically, the reverse proxy is a kind of proxy server, and obtains resources from one or more sets of backend servers (e.g. Web servers) associated with the client according to a request of the client, and then returns the resources to the client, so that the client only knows an IP address of the reverse proxy and does not know existence of a server cluster behind the proxy server. In other words, the client can indirectly access the resources of many different internet servers (clusters) via the forward proxy, and the reverse proxy is a proxy through which many clients indirectly access the resources on different backend servers without knowing the existence of these backend servers, and for all resources come from this reverse proxy server.
Since the specific ways of setting the resource path and the client permitted to access as needed and setting and storing the correspondence between each resource path and the client certificate permitted to access the resource path are techniques that can be implemented by those skilled in the art according to common knowledge, details are not described herein.
Further, in this embodiment, the correspondence between each resource path and the client certificate that is allowed to access the resource path may be stored in a database of the backend server. Thereby, further management of the access rights of the client can be achieved.
For example, for a website of a certain company, the company may determine that different clients have different access rights, and accordingly, by binding the resource path and the client certificate allowing access to the resource path, more effective management is achieved, for example, for client a, resource path 1 and resource path 2 may be accessed, and for client B, resource path 1 may not be accessed, but only resource path 2 may be accessed. By storing the corresponding relationship between each resource path and the client certificate which allows to access the resource path, the difference of the different clients and the access authority of the clients to the resource path can be effectively managed.
Step 102: when a client requests to access the resource path from a reverse proxy server and passes the bidirectional authentication with the reverse proxy server, the reverse proxy server sends an access verification message to the back-end server, wherein the access verification message comprises the client certificate and the resource path requested to be accessed.
Specifically, the above steps further include the following substeps:
step 1202: the client requests access to the resource path from the reverse proxy server.
Step 1204: the reverse proxy server performs bidirectional authentication with the client, if the bidirectional authentication is passed, step 1206 is executed, otherwise, the request of the client is rejected.
It should be noted that, in the embodiments of the present specification, the server certificate refers to a certificate used for authenticating the client in hypertext transfer security protocol (https) mutual authentication, and the server certificate is a root for verifying the client certificate, and can only pass authentication if matching. The client certificate is a client certificate which is issued by a server (such as OpenSSL) to a trusted terminal for mutual authentication, namely, the client certificate is manufactured by using OpenSSL software and corresponds to the server certificate. More specifically, the reverse proxy server is pre-installed with a root certificate made by OpenSSL software, and a client certificate of the terminal is generated from the root certificate. Since mutual authentication is well known to those skilled in the art, it will not be described herein.
Step 1206: and the reverse proxy server sends an access verification message to the back-end server, wherein the access verification message comprises the client certificate and a resource path for requesting access.
Specifically, in the embodiments of the present specification, the http request header of the access verification message may include one of the following or any combination thereof: a method of the request, a URI (Uniform Resource Identifier), a protocol version, and a MIME-like message structure containing a request modifier, customer information and content, etc. Further, the http request header also includes the client certificate.
In other words, the reverse proxy server places the client certificate in an http header, which is forwarded to the backend server.
Note that the URI, i.e., the uniform resource identifier, included in the http request header is a character string for identifying a name of a certain internet resource. This identification allows the user to interoperate with any resource (including local and internet) via a particular protocol. The URI is defined by a scheme that includes a deterministic syntax and associated protocols. In embodiments of the present description, a resource path is identified by a URI.
Step 103: and the back-end server matches the client certificate and the resource path requested to be accessed, which are contained in the access verification message, with the corresponding relation between the pre-stored resource path and the corresponding client certificate allowing the resource path to be accessed, and if the matching is successful, the verification is passed.
In this step, the back-end server further verifies whether the client has the right to the specific resource path to be accessed according to the corresponding relationship between the resource path pre-stored in the database of the back-end server and the client certificate allowing to access the resource path. If the matching is successful, the verification is passed, a message passing the verification is returned to the reverse proxy server, otherwise, if the matching is unsuccessful, a 401http error code is returned to the reverse proxy server.
Therefore, although the clients with different authorities can pass the mutual authentication, the management of the access to different resource paths under the same domain name can be more effectively realized by further verifying the binding relationship between the client certificate in the access verification message and the resource path requested to be accessed.
Through the embodiment, although different client certificates generated by the same server certificate can pass the mutual authentication, on the basis, the corresponding relation between the resource path and the client certificate allowed to access the resource path is stored in the back-end server in advance, when the client requests the reverse proxy server to access the resource path and passes the mutual authentication with the reverse proxy server, the reverse proxy server forwards the client certificate and the resource path requested to access to the back-end server, the back-end server matches the received client certificate and the resource path requested to access with the corresponding relation between the pre-stored resource path and the client certificate allowed to access the resource path, and if the matching is successful, the verification is passed.
Therefore, different client certificates can be used for authentication of different resource paths under a single domain name, and more effective management of different resource paths under the same domain name is realized.
In other embodiments of the present specification, the manner of authentication may be further increased. Specifically, the method comprises the following steps: in step 101, the valid time of the correspondence between each resource path and the client certificate that is allowed to access the resource path is stored in the back-end server in advance. For example, the effective time may be one week, one month, or the like, and may be set according to specific needs.
In step 103, when the backend server matches the client certificate included in the access verification message and the resource path requested to be accessed with the correspondence between the pre-stored resource path and the client certificate allowed to access the resource path, matching the current time with the valid time, and if the current time is within the valid time, passing the verification; otherwise, if the current time is not within a small time later, for example, the valid time is exceeded, the verification is failed, and an error code is returned to the reverse proxy server.
The multi-path bidirectional authentication method and device in the embodiments of the present description can more effectively manage different resource paths under the same domain name, and avoid resource waste.
A second embodiment of the present specification relates to a multipath bidirectional authentication device, which is configured as shown in fig. 3, and includes:
the storage module is used for storing the corresponding relation between each resource path and the client certificate which is allowed to access the resource path in the back-end server in advance;
a verification message sending module, configured to send an access verification message to the backend server when a client requests the reverse proxy server to access the resource path and passes bidirectional authentication with the reverse proxy server, where the access verification message includes the client certificate and the resource path requested to be accessed; and
and the matching module is used for matching the client certificate and the resource path requested to be accessed, which are contained in the access verification message, with the corresponding relation between the pre-stored resource path and the corresponding client certificate which allows the resource path to be accessed, and if the matching is successful, the verification is passed.
The first embodiment is a method embodiment corresponding to the present embodiment, and the technical details in the first embodiment may be applied to the present embodiment, and the technical details in the present embodiment may also be applied to the first embodiment.
It should be noted that, as will be understood by those skilled in the art, the implementation functions of the modules shown in the above embodiments of the multi-path bidirectional authentication device can be understood by referring to the related description of the multi-path bidirectional authentication method. The functions of the respective blocks shown in the above-described embodiments of the multipath bidirectional authentication device may be implemented by a program (executable instructions) running on a processor, or may be implemented by a specific logic circuit. The multi-path mutual authentication device in the embodiments of the present disclosure may also be stored in a computer-readable storage medium if it is implemented in the form of a software function module and sold or used as an independent product. Based on such understanding, the technical solutions of the embodiments of the present specification may be essentially or partially implemented in the form of a software product stored in a storage medium and including instructions for causing a computer device (which may be a personal computer, a server, or a network device) to execute all or part of the methods described in the embodiments of the present specification. And the aforementioned storage medium includes: various media capable of storing program codes, such as a usb disk, a removable hard disk, a Read 0nly Memory (ROM), a magnetic disk, or an optical disk. Thus, embodiments of the present description are not limited to any specific combination of hardware and software.
Accordingly, the present specification embodiments also provide a computer-readable storage medium having stored therein computer-executable instructions that, when executed by a processor, implement the method embodiments of the present specification. Computer-readable storage media, including both non-transitory and non-transitory, removable and non-removable media, may implement information storage by any method or technology. The information may be computer readable instructions, data structures, modules of a program, or other data. Examples of computer storage media include, but are not limited to, phase change memory (PRAM), static Random Access Memory (SRAM), dynamic Random Access Memory (DRAM), other types of Random Access Memory (RAM), read Only Memory (ROM), electrically Erasable Programmable Read Only Memory (EEPROM), flash memory or other memory technology, compact disc read only memory (CD-ROM), digital Versatile Discs (DVD) or other optical storage, magnetic cassettes, magnetic tape magnetic disk storage or other magnetic storage devices, or any other non-transmission medium that can be used to store information that can be accessed by a computing device. As defined herein, a computer readable storage medium does not include a transitory computer readable medium such as a modulated data signal and a carrier wave.
In addition, the present specification embodiments also provide a multi-path mutual authentication device, which includes a memory for storing computer executable instructions, and a processor; the processor is configured to implement the steps of the method embodiments described above when executing the computer-executable instructions in the memory. The Processor may be a Central Processing Unit (CPU), another general-purpose Processor, a Digital Signal Processor (DSP), an Application Specific Integrated Circuit (ASIC), or the like. The aforementioned memory may be a read-only memory (ROM), a Random Access Memory (RAM), a Flash memory (Flash), a hard disk, or a solid state disk. The steps of the method disclosed in the embodiments of the present invention may be directly implemented by a hardware processor, or implemented by a combination of hardware and software modules in the processor.
It is noted that, in the present patent application, relational terms such as first and second, and the like are used solely to distinguish one entity or action from another entity or action without necessarily requiring or implying any actual such relationship or order between such entities or actions. Also, the terms "comprises," "comprising," or any other variation thereof, are intended to cover a non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements does not include only those elements but may include other elements not expressly listed or inherent to such process, method, article, or apparatus. Without further limitation, the use of the verb "comprise a" to define an element does not exclude the presence of another, same element in a process, method, article, or apparatus that comprises the element. In the present patent application, if it is mentioned that a certain action is executed according to a certain element, it means that the action is executed according to at least the element, and two cases are included: performing the action based only on the element, and performing the action based on the element and other elements. The expression of a plurality of, a plurality of and the like includes 2, 2 and more than 2, more than 2 and more than 2.
All documents mentioned in this specification are to be considered as being incorporated in their entirety into the disclosure of this specification so as to be subject to modification as necessary. It should be understood that the above description is only a preferred embodiment of the present disclosure, and is not intended to limit the scope of the present disclosure. Any modification, equivalent replacement, improvement, etc. made within the spirit and principle of one or more embodiments of the present disclosure should be included in the scope of protection of one or more embodiments of the present disclosure.
The foregoing description has been directed to specific embodiments of this disclosure. Other embodiments are within the scope of the following claims. In some cases, the actions or steps recited in the claims may be performed in a different order than in the embodiments and still achieve desirable results. In addition, the processes depicted in the accompanying figures do not necessarily require the particular order shown, or sequential order, to achieve desirable results. In some embodiments, multitasking and parallel processing may also be possible or may be advantageous.
Claims (10)
1. A multi-path mutual authentication method, comprising the steps of:
storing the corresponding relation between each different resource path under the same domain name and a client certificate allowing to access the resource path in a back-end server in advance;
when a client requests to access the resource path from a reverse proxy server and passes the bidirectional authentication with the reverse proxy server, the reverse proxy server sends an access verification message to the back-end server, wherein the access verification message comprises the client certificate and the resource path requested to be accessed; and
and the back-end server matches the client certificate and the resource path requested to be accessed, which are contained in the access verification message, with the corresponding relation between the pre-stored resource path and the corresponding client certificate allowing the resource path to be accessed, and if the matching is successful, different resource paths under the same domain name are distinguished and managed through verification.
2. The method according to claim 1, wherein in the step of matching the client certificate included in the access verification message and the resource path requested to be accessed with the correspondence between the pre-stored resource path and the corresponding client certificate allowed to access the resource path by the backend server, if the matching is successful, the verification is passed and the verified message is returned to the reverse proxy server, otherwise, if the matching is unsuccessful, an error code is returned to the reverse proxy server.
3. The method of claim 1, wherein when a client requests access to the resource path from a reverse proxy server and passes mutual authentication with the reverse proxy server, the reverse proxy server sending an access validation message to the back-end server, comprising the sub-steps of:
the client requests the reverse proxy server to access the resource path;
and the reverse proxy server and the client perform bidirectional authentication, and if the reverse proxy server passes the bidirectional authentication, the reverse proxy server sends an access verification message to the back-end server, wherein the access verification message comprises the client certificate and a resource path requesting access.
4. The method of claim 3, wherein an http request header of the access validation message contains the client certificate.
5. The method of claim 4, wherein the http request header of the access validation message further comprises one or any combination of the following: method of request, URI, protocol version, customer information.
6. The method of claim 1, further comprising:
the effective time of the corresponding relation between each resource path and the client certificate allowing to access the resource path is stored in a back-end server in advance; and is
When the back-end server matches the client certificate contained in the access verification message and the resource path requested to access with the corresponding relation between the pre-stored resource path and the corresponding client certificate allowed to access the resource path, the back-end server also matches the current time with the effective time, and if the current time is not within the effective time, an error code is returned to the reverse proxy server.
7. The method of claim 1, wherein the correspondence between each resource path and client credentials that allow access to that resource path is stored in a database of the back-end server.
8. A multi-path mutual authentication device comprising:
the storage module is used for storing the corresponding relation between each different resource path under the same domain name and the client certificate allowing to access the resource path in the back-end server in advance;
a verification message sending module, configured to send an access verification message to the backend server when a client requests the reverse proxy server to access the resource path and passes bidirectional authentication with the reverse proxy server, where the access verification message includes the client certificate and the resource path requested to be accessed; and
and the matching module is used for matching the client certificate and the resource path requested to be accessed, which are contained in the access verification message, with the corresponding relationship between the pre-stored resource path and the corresponding client certificate allowed to access the resource path, and if the matching is successful, the different resource paths under the same domain name are managed in a distinguishing way through verification.
9. A multi-path mutual authentication device comprising:
a memory for storing computer executable instructions; and the number of the first and second groups,
a processor for implementing the steps in the method of any one of claims 1 to 7 when executing the computer-executable instructions.
10. A computer readable storage medium having stored thereon computer executable instructions which, when executed by a processor, implement the steps in the method of any one of claims 1 to 7.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN201911096818.7A CN112787986B (en) | 2019-11-11 | 2019-11-11 | Multi-path bidirectional authentication method and device |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN201911096818.7A CN112787986B (en) | 2019-11-11 | 2019-11-11 | Multi-path bidirectional authentication method and device |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| CN112787986A CN112787986A (en) | 2021-05-11 |
| CN112787986B true CN112787986B (en) | 2023-04-07 |
Family
ID=75749820
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN201911096818.7A Active CN112787986B (en) | 2019-11-11 | 2019-11-11 | Multi-path bidirectional authentication method and device |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN112787986B (en) |
Families Citing this family (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US11757635B2 (en) * | 2020-03-13 | 2023-09-12 | Mavenir Networks, Inc. | Client authentication and access token ownership validation |
| CN114466000B (en) * | 2021-12-22 | 2023-10-10 | 天翼云科技有限公司 | CDN gateway source returning method and device |
| CN114785629B (en) * | 2022-06-17 | 2022-09-02 | 天津市职业大学 | Intelligent gateway interaction method and system |
Citations (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN105359486A (en) * | 2013-05-03 | 2016-02-24 | 思杰系统有限公司 | Secured access to resources using a proxy |
| CN109040024A (en) * | 2018-07-06 | 2018-12-18 | 广东微云科技股份有限公司 | Resource access authority control method and system |
| CN109067803A (en) * | 2018-10-10 | 2018-12-21 | 深信服科技股份有限公司 | A kind of SSL/TLS encryption and decryption communication means, device and equipment |
Family Cites Families (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US7370351B1 (en) * | 2001-03-22 | 2008-05-06 | Novell, Inc. | Cross domain authentication and security services using proxies for HTTP access |
-
2019
- 2019-11-11 CN CN201911096818.7A patent/CN112787986B/en active Active
Patent Citations (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN105359486A (en) * | 2013-05-03 | 2016-02-24 | 思杰系统有限公司 | Secured access to resources using a proxy |
| CN109040024A (en) * | 2018-07-06 | 2018-12-18 | 广东微云科技股份有限公司 | Resource access authority control method and system |
| CN109067803A (en) * | 2018-10-10 | 2018-12-21 | 深信服科技股份有限公司 | A kind of SSL/TLS encryption and decryption communication means, device and equipment |
Also Published As
| Publication number | Publication date |
|---|---|
| CN112787986A (en) | 2021-05-11 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CN110268678B (en) | A PKI-Based Authentication Proxy User's Login Method and Its Server | |
| CN107483509B (en) | A kind of auth method, server and readable storage medium storing program for executing | |
| US9985968B2 (en) | Techniques to authenticate a client to a proxy through a domain name server intermediary | |
| US7680937B2 (en) | Content publication | |
| JP5658745B2 (en) | HTTP-based authentication | |
| US9648008B2 (en) | Terminal identification method, and method, system and apparatus of registering machine identification code | |
| CN110177124B (en) | Identity authentication method based on block chain and related equipment | |
| CN106452814B (en) | A kind of method and apparatus using external account operating resource | |
| CN112787986B (en) | Multi-path bidirectional authentication method and device | |
| US20060200424A1 (en) | Method and system for integrating multiple identities, identity mechanisms and identity providers in a single user paradigm | |
| US20180020008A1 (en) | Secure asynchronous communications | |
| CN105721418B (en) | Method and system for low-cost authentication signature delegation in content center network | |
| CN111031074A (en) | An authentication method, server and client | |
| CN111931199A (en) | Health authentication method, equipment and medium based on block chain and dynamic code | |
| CN114629713B (en) | Identity verification method, device and system | |
| CN111818088A (en) | Authorization mode management method and device, computer equipment and readable storage medium | |
| Riad et al. | A blockchain‐based key‐revocation access control for open banking | |
| CN110798322B (en) | Operation request method, device, storage medium and processor | |
| CN117118640A (en) | A data processing method, device, computer equipment and readable storage medium | |
| WO2020212784A1 (en) | Destination addressing associated with a distributed ledger | |
| US11394723B2 (en) | Validation of content delivery and verification of a delegation of delivery of a content | |
| CN111769949A (en) | Management/execution method/system, medium, management/agent terminal for mutual authentication | |
| CN119316144A (en) | Certificate issuance method, device, system, storage medium and computer program product | |
| CN116388998A (en) | A whitelist-based audit processing method and device | |
| TWI698113B (en) | Identification method and systerm of electronic device |
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 |