Detailed Description
Exemplary embodiments of the present invention will now be described with reference to the accompanying drawings, in which various details of the embodiments of the present invention are included to facilitate understanding, and are to be considered merely exemplary. Accordingly, those of ordinary skill in the art will recognize that various changes and modifications of the embodiments described herein can be made without departing from the scope and spirit of the invention. Also, descriptions of well-known functions and constructions are omitted in the following description for clarity and conciseness.
Currently, there are many external authentications to micro-service systems, most of which are performed by the hypertext transfer protocol (HTTP) protocol, which includes OAuth, SAML, openID Connect, etc. Some of the authentication methods described above are mature, such as OAuth, and there are also more complex SAML.
But in general, this is the authentication of external calls by the internal system, here external including a browser or Application Programming Interface (API), but there are currently few general approaches to authentication of micro-service internal interfaces based on remote procedure calls (Remote Procedure Call, RPC).
RPC is a remote procedure call, which is a protocol that requests services from a remote computer program over a network without requiring knowledge of the underlying network technology. RPC makes it easier to develop applications including network distributed multiprogramming.
For example, the default internal part of small and medium enterprises is safe, mutual authentication is not needed between departments, but for large enterprises with multiple institutions, the business lines are numerous, the requirements of system stability, safety, monitoring and statistics are met, and authentication is needed between the internal departments.
For authentication requirements in the above scenario, the current solutions mainly have the following ways:
The first mode is that the authentication is not verified.
The framework used, whether it be the commercially popular dubbo or the service invocation framework developed by each individual, is by default inside a secure network, since the outer layer has a secure boundary where the services within the boundary are trusted to each other and thus do not require authentication.
Aiming at the mode one:
default is within the safety margin and no verification is done, the main drawbacks are the following.
First, if an attacker invades the internal network outside the boundary, it means that all interfaces are exposed to the attacker, so that it can do any operation, which is a huge security risk.
Second, for the inside of the boundary, some important interfaces, such as modification involving finance, password, etc., need to control the scope of access, or control the source of access. The above mentioned important interfaces obviously cannot be opened to all internal applications either.
In addition, in some scenarios, statistics of access sources and information such as access times and frequencies of different sources are required, and these needs to be distinguished and authenticated for RPC clients.
And setting a token.
A common token is agreed between the server side and the client side of the RPC. If a new client wants to invoke this service, the token must be requested from the server and then carried as an implicit parameter when the service is invoked.
After the RPC framework receives the call request, the implicit parameters carried by the client are checked, the token in the implicit parameters is taken out, and the implicit parameters are compared with the token of the call service. If the service is the same token, the service is called, otherwise, the service is refused, and the related information is returned to the client.
Aiming at the second mode:
the RPC client and the server use the same token, and the method can achieve preliminary authentication, so that an external invader still cannot call internal services after entering an internal network. However, there is a great disadvantage that different clients cannot be distinguished, and because token cannot be dynamically allocated one-to-one to different clients, misuse is possible, and distinguishing statistics cannot be performed according to the source of the clients.
Mode three, API key.
There are various implementations of API keys, and how they are used in particular, depending on the particular technical scheme used by the system. Not only can the service caller be identified, but it can be subject to various restrictions, including access to specific resources, speed limits of the interface, etc. Many systems use a pattern of shared API keys that are verified using a hash operation message authentication code (HMAC). There are also some systems that employ public-key private key pairs.
Aiming at a mode III:
While satisfying the secure call, the complexity of dynamically assigning, dynamically managing keys or certificates is attendant. Especially in a distributed scenario, the client is itself a cluster, and a multiparty service needs to be invoked, which requires a complex set of management mechanisms. The same is true for the management of the service end, and the RPC is possibly called at high frequency, and the frequent encryption and decryption process with large operation amount also has tired service performance in the interior, so the scheme is not suitable for the situation of calling in the RPC framework.
In micro services, the client can call the service based on the call request, however, for the internal call of the RPC framework, the encryption and decryption process causes a large operand, thus affecting the internal service performance.
In summary, under the condition that the internal service performance is not affected, there is a technical problem that clients cannot be distinguished, so that any access terminal can call services, and service security is difficult to guarantee.
In order to solve the technical problem that different clients cannot be distinguished, the following technical scheme in the embodiment of the present invention may be adopted.
Referring to fig. 1, fig. 1 is a schematic diagram of a main flow of an interface authentication method according to an embodiment of the present invention, where a server obtains an authorized client token, so that a call request can be authenticated. As shown in fig. 1, the method specifically comprises the following steps:
S101, in a remote procedure call framework, a client needing a call interface sends a call request for calling a service interface to a server, wherein the call request comprises a client token, and the client token is distributed to the client by an authentication server.
An RPC framework is an architecture that employs an RPC-related protocol. Referring to fig. 2, fig. 2 is a schematic diagram of a remote procedure call framework according to an embodiment of the present invention, and fig. 2 includes 3 servers, namely, server a, server B, and server C.
The server A is deployed with an application, and the server B and the server C respectively provide services which can be used by the application.
An application deployed on server a needs to call a service used by an application on server B or server C, and because the application cannot be directly called without being in the same memory space, the application needs to express the semantics of the call and convey the data of the call through a network. That is, the application in server a invokes the service used by the application on server B or server C through the RPC.
In an embodiment of the invention, interface authentication involves a client invoking an interface, a service provider of the interface, a server and an authentication server.
It is understood that a server is a device that provides multiple services in an application to a client.
The specific procedure of registering a service and assigning a token is exemplarily described below. It can be understood that the service end obtains the service token, and the client end calling the interface distributes and obtains the client token.
Referring to fig. 3, fig. 3 is an interaction schematic diagram of an authentication server according to an embodiment of the present invention, which specifically includes:
s301, registering the service.
In one embodiment of the invention, the service provider of the interface registers for services. In particular, the service provider of the interface registers its own services on the authentication server.
It will be appreciated that one interface may provide one or more services. That is, in the case where the interface provides one service, the client calling the interface can call one service through the interface, and in the case where the interface provides a plurality of services, the client calling the interface can call a plurality of services through the interface.
S302, feeding back a configuration identifier.
The authentication server is used for verifying whether the server side has the right to acquire the authorized client token or not and verifying whether the client side has the right to call the interface or not.
In the embodiment of the invention, both the service provider of the interface and the client needing to call the interface need to register in the authentication server.
After the authentication server sends a request for registering the service to the service provider of the interface, the authentication server applies for the configuration identifier for the interface or configures the configuration identifier for the service application corresponding to the interface.
S303, applying for a service token.
The service provider of the interface sends a request for a service token to the authentication server.
S304, feeding back the service token.
The authentication server generates a service token which is used as a basis for the service end to access the authentication server. The configuration identifier and the service token can be provided for the service end by the service provider of the interface, so that the service end can conveniently provide the service for calling the interface for the client for calling the interface.
The above S301 to S304 are specific procedures in which the service provider of the interface registers with the authentication server and obtains the configuration identification and the service token.
S305, applying for a client token.
Before the interface is called, the server of the calling interface needs to register in the authentication server to acquire the client token. The client of the calling interface applies for the calling authority of the service through the authentication server.
S306, waiting for application.
The authentication server sends a message to be approved to a service provider of the interface, and the service provider of the interface determines whether the client is allowed to call the interface.
S307, approval passes.
And the service provider of the interface does not allow the client for calling the interface to call the interface, and the feedback approval does not pass.
S308, feeding back the client token.
In case of approval passing, the authentication server assigns a client token to the client. In this way, the client is facilitated to invoke the interface described above.
The specific procedure of the client calling the interface is to register with the authentication server and obtain the client token in S305 to S308.
It will be appreciated that the above-described registration steps of the server and the client invoking the interface may be summarized as follows.
Referring to fig. 4, fig. 4 is a schematic flow chart of registration at an authentication server according to an embodiment of the present invention, which specifically includes:
s401, the service provider of the interface registers the interface service in the authentication server to obtain the configuration identification.
In the embodiment of the invention, the configuration identifier is a parameter for distinguishing different RPC services accessed to the authentication server, and when the service provider of the interface accesses the authentication server, various configuration data under the service are acquired by using the configuration identifier.
S402, the client applies for the calling of the interface through the authentication server.
The client applies for the invocation of the interface by sending a request for applying for a client token to the authentication server.
S403, after the service provider of the interface authorizes the client to call the interface, the authentication server distributes a client token for the client.
After being authorized by the service provider of the interface, the authentication server distributes a client token to the client.
It will be appreciated that the client corresponds to a client token and the service provider of the interface corresponds to a service token. The above-mentioned tokens are two different tokens. The client accesses the interface through the client token, and the server uses the service token as the basis for accessing the authentication system.
It will be appreciated that the service token is obtained after the service provider of the interface registers with the authentication server.
After both the service provider and the client of the interface are registered with the authentication server, the client may initiate interface authentication to invoke the interface.
It can be understood that the technical solution in the embodiment of the present invention is applicable to the RPC framework in fig. 2. The client requiring the RPC sends a call request to the server to invoke the service interface.
In one embodiment of the invention, upon remote procedure call, the client is activated in the filter call chain, retrieving the assigned client token from the authentication server.
The filter call chain is a filter chain formed by a plurality of filters, can sequentially process a request, transmits the request to the next filter, and finally distributes the request to the control layer for service processing.
After the client token is obtained from the authentication server, a call request for calling the service interface can be sent to the server, and after the authentication is passed, the service interface can be called. Wherein the call request includes a client token. It will be appreciated that the client token is assigned to the client by the authentication server.
According to S305 to S308, the authentication server assigns a client token to each client that needs to invoke an interface. Because the clients are different, the client tokens for the clients are also different. That is, the client is in one-to-one correspondence with the client token, and the client can be known based on the client token.
S102, the server acquires the authorized client token of the interface from the authentication server according to the configuration identification.
In the embodiment of the invention, a filter call chain is called before RPC call of a server side. The filter call chain adds an authentication server filter in addition to the standard universal filter. The authentication server filter is essentially a client that acts as an authentication server.
In an embodiment of the invention, the authentication server filter is one of a plurality of sequentially executed filters.
Referring to fig. 5, fig. 5 is a schematic flow chart of acquiring an authorized client token of an interface according to an embodiment of the present invention, specifically including:
S501, the server starts an authentication server filter in a filter call chain.
The filter call chain comprises a plurality of filters, and after the server receives the call request and acquires the client token in the call request, the authentication server filter in the filter call chain is started.
S502, the filter calls an authentication server filter in the chain, and an authorized client token of the interface is obtained from the authentication server based on the configuration identification and the server token.
The authentication server filter connects the server and the authentication server, and is an adhesive for two large systems. The authentication server filter is equivalent to a client for the authentication server, and when the filter call chain goes to the node, the authentication server filter carries the configuration identifier and the server token of the server, and a specific network protocol is adopted to the authentication server to acquire the authorized client token of the interface. Illustratively, the authorized client tokens include a set of client tokens of a list of clients authorized by the interface.
An authorized client token for the interface is stored in the authentication server. An authorized client token, i.e., a client token that applies for the interface or method and has been approved.
Wherein the server token of the server is pre-allocated to the server by the authentication server.
In one embodiment of the invention, an authorized client token for a predefined method of interfacing is obtained from an authentication server. There are many ways in an interface that an authorized client token of a predefined method can be sent to the server. The predefined method may be one method or a plurality of methods.
And S103, the server authenticates the call request according to the client token and the authorized client token in the call request, and feeds back an authentication result to the client.
The server may authenticate the invocation request based on the client token and the authorized client token in the invocation request.
Referring to fig. 6, fig. 6 is a schematic flow chart of an authentication call request according to an embodiment of the present invention, specifically including:
s601, the server judges that the client token in the call request belongs to the authorized client token, and the call request authentication is successful.
Based on the client token and the authorized client token in the call request, the server judges that the client token in the call request belongs to the authorized client token, and the call request authentication is successful.
S602, feeding back authentication success to the client.
And if the authentication of the call request is successful, feeding back the authentication success to the client, and calling the service to continue to process the next node of the filter call chain.
In the RPC framework, the client receives the feedback result and performs subsequent processing based on the filter call chain.
In the embodiment of fig. 6, the server authenticates based on the client token and the authorized client token and feeds back the authentication result, thereby determining that the service can be invoked.
Referring to fig. 7, fig. 7 is a schematic flow chart of another authentication call request according to an embodiment of the present invention, specifically including:
S701, the server judges that the client token in the call request does not belong to the authorized client token, and the call request fails to authenticate.
Based on the client token and the authorized client token in the call request, the server side judges that the client token in the call request does not belong to the authorized client token, and the authentication of the call request fails.
S702, feeding back a response of rejecting the service to the client.
And if the call request authentication fails, feeding back a response of rejecting the service to the client.
In the embodiment of fig. 7, the server authenticates based on the client token and the authorized client token and feeds back authentication failure, thereby determining that the service cannot be invoked.
In the embodiment, in the remote procedure call framework, a client needing to call an interface sends a call request for calling a service interface to a server, the call request comprises a client token, the client token is distributed to the client by an authentication server, the server acquires an authorized client token of the interface from the authentication server according to a configuration identifier, and the server authenticates the call request and feeds back an authentication result to the client according to the client token and the authorized client token in the call request. Different access terminals can be distinguished based on the client token, so that the safety of the service is guaranteed.
Referring to fig. 8, fig. 8 is a schematic flow chart of interaction between a server and an authentication server according to an embodiment of the present invention, which specifically includes:
S801, acquiring an authorized client token according to the configuration identification.
And the server acquires the authorized client token from the authentication server according to the configuration identifier.
S802, feeding back an authorized client token.
The authentication server feeds back the authorized client token to the server.
S803, judging whether the client token belongs to an authorized client token.
The server judges that the client token belongs to the authorized client token, the authentication is successful, and the server judges that the client token does not belong to the authorized client token, the authentication is failed.
S804, feeding back the authentication result.
The server feeds back the authentication result to the client.
In the embodiment of the invention, the client is skillfully fused into a filter call chain of the RPC server, and the client is activated in the call chain to acquire the client token and the configuration identifier from the server of the authentication server when the RPC service is called each time, so that the authentication is performed on the client.
Referring to fig. 9, fig. 9 is a schematic diagram of a main structure of an interface authentication device according to an embodiment of the present invention, where the interface authentication device may implement an interface authentication method, as shown in fig. 9, where the interface authentication device specifically includes:
The sending module 901 is configured to send, in the remote procedure call framework, a call request for calling the service interface to the server by using a client that needs to call the interface, where the call request includes a client token, and the client token is allocated to the client by using the authentication server.
And the obtaining module 902 is configured to control the server to obtain the authorized client token of the interface from the authentication server according to the configuration identifier.
The authentication module 903 is configured to control the server to authenticate the call request according to the client token and the authorized client token in the call request, and feed back an authentication result to the client.
In one embodiment of the present invention, the obtaining module 902 is specifically configured to control the server to obtain, from the authentication server, the authorized client token of the interface through the authentication server filter based on the configuration identifier and the service token.
In one embodiment of the invention, the authentication server filter is one of a plurality of sequentially executed filters.
In one embodiment of the invention, the obtaining module 902 is specifically configured to obtain an authorized client token of a predefined method of interfacing from an authentication server.
In one embodiment of the invention, the service token is obtained after the service provider of the interface registers with the authentication server.
In one embodiment of the present invention, the authentication module 903 is specifically configured to control a service provider of an interface to register an interface service on an authentication server, and obtain a configuration identifier;
the control client applies for calling of the interface to the service provider of the interface through the authentication server;
After the service provider of the interface authorizes the client to call the interface, the authentication server is received to distribute a client token for the client.
Referring to fig. 10, fig. 10 is a schematic diagram of main flow of an interface authentication method according to another embodiment of the present invention, and an execution subject of the technical solution in fig. 10 is an authentication server, which specifically includes:
S1001, receiving an authentication request sent by an interface authentication server, wherein the authentication request comprises a configuration identifier and a service token.
In one embodiment of the invention, the service provider of the interface needs to register in the authentication server to obtain the configuration identification and the service token.
Specifically, the authentication server receives a registration of a service provider of the interface and sends a configuration identification to the service provider of the interface.
The authentication server receives a service application from the service provider of the interface and sends a service token to the service provider of the interface.
In one embodiment of the invention, the client that needs to invoke the interface needs to register in the authentication server to obtain the service token.
The authentication server receives a service application of a client needing to call an interface and sends an approval message to a service provider of the interface;
The authentication server receives an approval passing message sent by a service provider of the interface, and sends a feedback configuration identifier of a client needing to call the interface to a client token of the corresponding interface, wherein the client token belongs to an authorized client token.
The authentication server receives an authentication request sent by a server for interface authentication, and the server sends the authentication request to acquire an authorized client token of the interface corresponding to the configuration identifier so as to authenticate a call request sent by a client needing to call the interface. Wherein the authentication request includes a configuration identification and a service token.
In one embodiment of the invention, an authentication request sent by an interface authenticated server is received through an authentication server filter.
The authentication server filter is one of a plurality of sequentially executed filters. The filter call chain adds an authentication server filter in addition to the standard generic filter. The authentication server filter is essentially a client that acts as an authentication server.
S1002, determining that the interface authenticated service end passes authentication according to the service token, and feeding back an authorized client token with a configuration identifier corresponding to the interface authenticated service end.
The authentication server may determine, based on the service token, whether the interface-authenticated server may pass authentication. As an example, the authentication server searches the received service token in the stored authorized service tokens, and determines that the interface authenticated service end passes authentication.
And if the interface authentication server passes the authentication, the authentication server feeds back an authorized client token for configuring the corresponding interface to the interface authentication server.
In the embodiment of fig. 10, the authentication request sent by the server is received, and the authorized client token of the interface is fed back, so that the security of the service is ensured because different access terminals can be distinguished based on the client token.
Referring to fig. 11, fig. 11 is a schematic view of the main structure of an interface authentication apparatus according to another embodiment of the present invention;
the receiving module 1101 is configured to receive an authentication request sent by an interface authenticated service end, where the authentication request includes a configuration identifier and a service token.
And the authentication module 1102 is configured to determine that the service end authenticated by the interface passes authentication according to the service token, and feed back an authorized client token configured with a configuration identifier corresponding to the interface to the service end authenticated by the interface.
In one embodiment of the present invention, the receiving module 1101 is specifically configured to receive, through an authentication server filter, an authentication request sent by an interface authenticated server.
In one embodiment of the present invention, the authentication module 1102 is further configured to receive a registration of a service provider of the interface and send a configuration identifier to the service provider of the interface;
a service application of a service provider of the interface is received and a service token is sent to the service provider of the interface.
In one embodiment of the present invention, the authentication module 1102 is further configured to receive a service application of a client that needs to invoke an interface, and send an approval message to a service provider of the interface;
And receiving an approval passing message sent by a service provider of the interface, and identifying a client token of the corresponding interface to the feedback configuration of the client needing to call the interface, wherein the client token belongs to an authorized client token.
Fig. 12 illustrates an exemplary system architecture 1200 of a method of interface authentication or apparatus of interface authentication to which embodiments of the present invention may be applied.
As shown in fig. 12, the system architecture 1200 may include terminal devices 1201, 1202, 1203, a network 1204, and a server 1205. The network 1204 serves as a medium for providing communications links between the terminal devices 1201, 1202, 1203 and the server 1205. The network 1204 may include various connection types, such as wired, wireless communication links, or fiber optic cables, among others.
A user may interact with the server 1205 through the network 1204 using the terminal devices 1201, 1202, 1203 to receive or transmit messages or the like. The terminal devices 1201, 1202, 1203 may have various communication client applications installed thereon, such as a shopping class application, a web browser application, a search class application, an instant messaging tool, a mailbox client, social server software, and the like (by way of example only).
The terminal devices 1201, 1202, 1203 may be various electronic devices having a display screen and supporting web browsing, including, but not limited to, smartphones, tablets, laptop and desktop computers, and the like.
The server 1205 may be a server providing various services, such as a background management server (by way of example only) that provides support for shopping-type websites browsed by users using terminal devices 1201, 1202, 1203. The background management server may analyze and process the received data such as the product information query request, and feedback the processing result (e.g., the target push information, the product information—only an example) to the terminal device.
It should be noted that, the method for interface authentication provided in the embodiment of the present invention is generally executed by the server 1205, and accordingly, the device for interface authentication is generally disposed in the server 1205.
It should be understood that the number of terminal devices, networks and servers in fig. 12 is merely illustrative. There may be any number of terminal devices, networks, and servers, as desired for implementation.
Referring now to FIG. 13, there is illustrated a schematic diagram of a computer system 1300 suitable for use in implementing an embodiment of the present invention. The terminal device shown in fig. 13 is only an example, and should not impose any limitation on the functions and the scope of use of the embodiment of the present invention.
As shown in fig. 13, the computer system 1300 includes a Central Processing Unit (CPU) 1301, which can execute various appropriate actions and processes according to a program stored in a Read Only Memory (ROM) 1302 or a program loaded from a storage section 1308 into a Random Access Memory (RAM) 1303. In the RAM 1303, various programs and data necessary for the operation of the system 1300 are also stored. The CPU 1301, ROM 1302, and RAM 1303 are connected to each other through a bus 1304. An input/output (I/O) interface 1305 is also connected to bus 1304.
Connected to the I/O interface 1305 are an input portion 1306 including a keyboard, a mouse, and the like, an output portion 1307 including a Cathode Ray Tube (CRT), a Liquid Crystal Display (LCD), and the like, a speaker, and the like, a storage portion 1308 including a hard disk, and the like, and a communication portion 1309 including a network interface card such as a LAN card, a modem, and the like. The communication section 1309 performs a communication process via a network such as the internet. The drive 1310 is also connected to the I/O interface 1305 as needed. Removable media 1313, such as magnetic disks, optical disks, magneto-optical disks, semiconductor memory, and the like, is mounted on drive 1310 as needed so that a computer program read therefrom is mounted into storage portion 1308 as needed.
In particular, according to embodiments of the present disclosure, the processes described above with reference to flowcharts may be implemented as computer software programs. For example, embodiments of the present disclosure include a computer program product comprising a computer program embodied on a computer readable medium, the computer program comprising program code for performing the method shown in the flow chart. In such embodiments, the computer program may be downloaded and installed from a network via the communication portion 1309 and/or installed from the removable medium 1313. The above-described functions defined in the system of the present invention are performed when the computer program is executed by a Central Processing Unit (CPU) 1301.
The computer readable medium shown in the present invention may be a computer readable signal medium or a computer readable storage medium, or any combination of the two. The computer readable storage medium can be, for example, but not limited to, an electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or a combination of any of the foregoing. More specific examples of a 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 or 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 context of this document, a computer readable storage medium may be any tangible medium that can contain, or store a program for use by or in connection with an instruction execution system, apparatus, or device. In the present invention, however, the computer-readable signal medium may include a data signal propagated in baseband or as part of a carrier wave, with the computer-readable program code embodied therein. 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 of the foregoing. 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. Program code embodied on a computer readable medium may be transmitted using any appropriate medium, including but not limited to wireless, wireline, optical fiber cable, RF, etc., or any suitable combination of the foregoing.
The flowcharts 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 invention. In this regard, 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 modules involved in the embodiments of the present invention may be implemented in software or in hardware. The described modules may also be provided in a processor, which may be described as, for example, a processor comprising a sending unit, an obtaining unit, a determining unit and a first processing unit. The names of these units do not constitute a limitation on the unit itself in some cases, and for example, the transmitting unit may also be described as "a unit that transmits a picture acquisition request to a connected server".
As a further aspect, the invention also provides a computer readable medium which may be comprised in the device described in the above embodiments or may be present alone without being fitted into the device. The computer readable medium carries one or more programs which, when executed by a device, cause the device to include:
In a remote procedure call framework, a client needing a call interface sends a call request for calling a service interface to a server, wherein the call request comprises a client token, and the client token is distributed to the client by an authentication server;
the server acquires an authorized client token of the interface from the authentication server according to the configuration identifier;
And the server authenticates the call request according to the client token in the call request and the authorized client token, and feeds back an authentication result to the client.
According to the technical scheme of the embodiment of the invention, in a remote procedure call framework, a client needing to call an interface sends a call request for calling a service interface to a server, the call request comprises a client token, the client token is distributed to the client by an authentication server, the server acquires an authorized client token of the interface from the authentication server according to a configuration identifier, and the server authenticates the call request and feeds back an authentication result to the client according to the client token and the authorized client token in the call request. Different access terminals can be distinguished based on the client token, so that the safety of the service is guaranteed.
The above embodiments do not limit the scope of the present invention. It will be apparent to those skilled in the art that various modifications, combinations, sub-combinations and alternatives can occur depending upon design requirements and other factors. Any modifications, equivalent substitutions and improvements made within the spirit and principles of the present invention should be included in the scope of the present invention.