Method, device and system for carrying out service access control on third-party application

[0052] Example one

[0053] In the first embodiment, the technical solution of the present application is introduced from the perspective of the first server, that is, in the method involved, the execution subject of each step is the first server, and the first server is still in the form of a JS component Expose some features to third-party applications. See figure 1 , The method can include the following steps:

[0054] S101: After receiving the service access request, determine whether the sender of the service access request is the preset JS software development kit JSSDK; wherein, the JSSDK is provided by the first server and is added by the third-party application. The component code automatically downloads the JSSDK to the local third-party application;

[0055] The first thing to note is that if a third-party application adds a JS component exposed by the first server, the corresponding interface can be displayed on the webpage of the third-party application. For example, a third-party website adds the "shopping" in Taobao. The JS component corresponding to the "car" function, the user can view the product information link in Taobao on the third-party website, and there are also operation buttons such as "add to shopping cart" on the page. If the user is interested in a product, then You can press the operation button of the product to issue an operation instruction to add the product to the shopping cart.

[0056] On the other hand, after a JS component is added to the third-party application, the code of the JS component can automatically download the JSSDK from the first server, which is equivalent to integrating the JSSDK in the browser. The JSSDK can monitor the user's related operations. If it is found that the user performs an operation related to the JS component (such as the aforementioned operation of adding a product to the shopping cart, etc.), it can generate a service access request and send it to the first server Send it.

[0057] Among them, in actual applications, third-party applications generally use the method of calling the API of the first server to obtain the service information of the first server. Therefore, in specific implementation, when the JSSDK generates a service access request, it can specifically determine the need to call API and assemble API parameters. Among them, the so-called assembling API parameters refers to assembling the information used to verify the security of the service access request into the API parameters, so that the service access request can carry this information and send it to the first server for security check.

[0058] There may be multiple types of specific information used for security verification. For example, one of them may be identification information of a third-party application. This kind of identification information is issued by the first server for the third-party application. Specifically, it can be used to issue unique identification information for the third-party application (generally called APPkey) when the third-party application registers with the first server to obtain the JS component. ), so that third-party applications can use this identification information to distinguish each third-party application.

[0059] Of course, in actual applications, there may also be cases where the identification information of third-party applications is leaked, causing other third-party applications to use the identification information of a third-party application to send service access requests. Therefore, in order to be able to verify service access requests Whether it comes from a legitimate third-party application, the first server can also record the correspondence between the refer address of each third-party application and the issued identification information. Since the refer address of the third-party application is unique, the refer address is There is a one-to-one correspondence between the identification information; when the JSSDK sends a service access request, it can also carry the information of the referral address of the third-party application, so that the first server side can also verify when the security is verified. Whether the correspondence between the referral address and the identification information is correct. If it is incorrect, the identification information may be stolen by other third-party applications. Therefore, the service access request can be discarded to avoid the threat of user information being leaked.

[0060] In addition, in addition to verifying the identity of third-party applications, in actual applications, you can also determine whether a service access request was issued with user authorization. If so, a response message will be returned, otherwise, if Without user authorization, the request can also be discarded. In specific implementation, when the user starts to use the function corresponding to the JS component in a third-party application, the third-party application can first initiate an authorization request to the first server, and accordingly, the first server can return the authorization confirmation interface. The confirmation interface shows the specific operation of the third-party application requesting authorization (for example, viewing user information, etc.). When the third-party application registers with the first server, it can apply for operation permissions. The first server is based on the third-party application application. If the third-party application is allowed to perform these operations after viewing the authorization confirmation interface, the user can click the button marked "Confirm" to authorize the operation of the third-party application. After the first server receives the user's confirmation authorization instruction, it can generate a string of encrypted characters and save it, for example, save it in cookies, which is equivalent to issuing a service access token to a third-party application. In this way, when JSSDK sends a service access request, the service access token can also be read from cookies, and it can also be assembled into API parameters, carried in the service access request and sent together. In this way, when verifying on the side of the first server, it is found that it carries the service access token issued by the first server, and then it can be determined that the service access request is issued with the authorization of the user, and then the access is allowed to The service access request returns a response message.

[0061] It should be noted that after a user authorization is performed and the service access token is saved in cookies, every time JSSDK sends a service access request, it can directly serve the service access token in cookies. However, without special settings, the information written in cookies will be deleted when the browser is closed. Therefore, each time the browser is reopened, the above user authorization is re-executed and the service access is generated. The token process. Of course, in actual applications, if it is a third-party application with relatively high credibility, it does not have to be re-authorization and service access token acquisition every time the browser is opened. The specifics can be determined according to the needs of the actual application. .

[0062] In addition, the user's account information can also be assembled into API parameters so as to be carried in the service access request and sent to the first server for verification. The user's account information can be read from the cookies of the main business platform when the user logs in to the main business platform.

[0063] S102: If yes, send the service access request to a preset proxy server, so that the proxy server performs a security check on the service access request according to the information carried in the service access request. Pass, then resend the service access request to the first server;

[0064] In the embodiment of this application, for the service access request sent to the first server, the first server does not directly perform security verification, but first determines the source of the service access request. If it is found to come from JSSDK, it will send it to a pre- The configured proxy server performs security verification. Wherein, the proxy server is a server set on the first server side for performing security verification on service access requests, and there may be multiple ones, and the first server may pre-store the IP address of each proxy server.

[0065] After receiving the service access request, the proxy server can perform security verification on the service access request according to the information carried therein. For example, if the service access request carries the refer address and identification information of the third-party application, it can be determined whether the correspondence between the two is correct. If it carries a service access token, it can also be judged whether the service access token is correct, and so on. It should be noted that the verification of the service access token may also be performed in the first server.

[0066] In addition, in order to further ensure security, in the embodiments of the present application, API permission groups can also be determined in advance for each third-party application, and the correspondence between the identification information of the third-party application and the API permission group can be stored in advance to indicate The third-party application only has the permission to call these APIs. In other words, for a third-party application, the third-party application does not have the right to call APIs outside the API permission group. Therefore, after receiving the service access request, the proxy server can also first obtain the identification information of the third-party application, and retrieve the API permission group corresponding to the identification information of the third-party application, and determine whether the API requested in the current service access request is called It is located in the API permission group of the third-party application. If it is and all other verification information is correct, the verification can be passed. Otherwise, if the currently requested API does not appear in the API permission group of the third-party application, even if other verification information is correct, the request will be discarded, or information such as request failure will be directly returned.

[0067] That is to say, in the embodiment of this application, for each third-party application, only a part of the API is allowed to be called. In this way, even if the service access request is faked, only a small part of the API can be called. API, so that most of the user's information is safe.

[0068] After the proxy server completes the security check of the service access request, if the check passes, it can re-send the service access request to the first server.

[0069] S103: After receiving the service access request again, determine whether the sender of the service access request is a proxy server, and if so, perform step S104;

[0070] In the embodiment of this application, for the first server, at least two service access requests will be received. One is the service access request from JSSDK. For this kind of access request, the first server will forward it to the proxy server for security. The other is the service access request from the proxy server. In this case, the first server will regard it as a service access request that has passed the security check. Therefore, it will respond according to the requested content. That is to say, whether it is a JSSDK or a proxy server, when sending a service access request to the first server, the URL of the first server used is the same, but when sent to the first server, the specific processing logic will be The first server will treat the difference differently.

[0071] What needs to be explained here is that after the first server receives a service access request, in order to determine whether it comes from a real proxy server, a whitelist of IP addresses can be set in advance, and the IP address of each proxy server is stored in the whitelist; After receiving a service access request, first extract the sender's IP address, and then determine whether it appears in the IP address whitelist, if it is, it proves to be from a authentic and trusted proxy server, otherwise, it can still be received The incoming service access request is discarded.

[0072] In addition, it should be noted that this way of using a proxy server for security verification can also achieve controllability of the frequency of each API call. That is to say, for an API, if it is called too many times in a short time, it may affect the performance of the system. Therefore, in the embodiment of the present application, the frequency of calling each API by the proxy server Perform statistics (for example, every time a request to call an API is received, add one to the number of requests to the API, and then calculate the frequency within a certain period of time), if a request to call an API is received, the call is found If the frequency of the API has exceeded a certain threshold, the request can be discarded.

[0073] S104: Return a response message according to the return address specified in the service access request.

[0074] After the first server receives the service access request sent by the proxy server, it can treat it as a secure service access request. Of course, the service access token and other information carried in the service access request can be checked in the first server. After verification, a response message can be made. Wherein, the return address is generally specified in the service access request, therefore, the first server only needs to return a response message according to the return address. After that, JSSDK can receive the response message and provide it to third-party applications for subsequent display and other processing.

[0075] That is to say, for the first server, the service access request it receives has two sources, which have always been from JSSDK. For this kind of service access request, it needs to be sent to the proxy server for security verification first, and the other One is from the proxy server. For this service access request, the first server can be treated as a secure request, and it can directly obtain the corresponding data and return a response message.

[0076] In short, in the embodiment of this application, the third-party application sends service access requests through the JSSDK integrated in the browser. In this way, if other third-party applications want to forge the service access request, they need to know the HTTP protocol in the browser. All parameters, therefore, increase the difficulty of forgery. For the first server, after receiving the service access request sent by JSSDK, it also needs to be sent to the proxy server for security verification. Therefore, the first server only receives the service access request sent by the proxy server again. Will respond, so safety is guaranteed. Among them, it is also possible to restrict the APIs that each third-party application can call, so that a third-party application can only call a limited number of APIs. In this way, even if the service access request is forged, the forger can only obtain Part of the information in the API permission group ensures that most of the user's information is safe.

[0077] It should be noted that in the prior art, in order to prevent other third-party applications from impersonating, generally the identification information of the third-party application (provided by the first server when the third-party application is registered), the user's account information (the user The account information registered in the first server) is assembled in the API parameters, and then the private key of the third-party application is used for digital signature, and then sent to the first server, the first server receives the digital signature After the service access request, the third-party application is authenticated through the signature information, and then the information carried in it is used for security verification.

[0078] However, the above-mentioned security verification method has at least the following problems: because the service access request needs to be digitally signed, it is required to perform the operation of writing cookies after sending a service access request. If it is in the embodiment of this application, since it is a service access request sent by JSSDK, JSSDK needs to perform the operation of writing cookies. However, in actual applications, although the first server is generally part of the main business platform (such as an e-commerce transaction platform, etc.), the cookies of the first server and the cookies of the main business platform are independent of each other. Therefore, if JSSDK performs cross-application write operations on the cookies of the main business platform, which may make cookies insecure.

[0079] In order to prevent the JSSDK from writing to the cookies of the main service platform, in this embodiment of the application, the signature-free policy can be implemented, that is, after the JSSDK has assembled the service access request, it can directly send the service access request to the first server. For the first server, after receiving the service access request, it first determines the source of the request, that is, whether the sender of the request is JSSDK, and if so, sends the service access request to a proxy server for security verification If the proxy server passes the verification, the service access request is sent to the first server again. Since the proxy server can verify the security of the service access request, and the first server only trusts the service access request re-sent by the proxy server, this series of measures can replace the digital signature to ensure security.

[0080] Example two

[0081] The first embodiment above introduced the technical solutions provided by the embodiments of the present application from the perspective of the first server. In the second embodiment, the technical solutions provided by the embodiments of the present application were introduced from the perspective of the proxy server. See figure 2 , The method of service access control to third-party applications from the perspective of the proxy server may include the following steps:

[0082] S201: Receive a service access request sent by the first server; the service access request is a service access request sent by a third-party application to the first server through the JSSDK; wherein, the JSSDK is provided by the first server and in the third-party application The added JS component code automatically downloads the JSSDK to the local third-party application;

[0083] S202: Perform security verification on the service access request according to the information carried in the service access request;

[0084] Among them, the service access request can be a request to call a specified API. Specifically, the service access request can carry the identification information of the third-party application. In this case, the specific security verification can be based on the identification of the third-party application. Information and the corresponding relationship between the preset third-party application and the callable API, determine whether the third-party application has the permission to call the currently specified API, if so, the verification is passed, otherwise, the request can be discarded .

[0085] In addition, the service access request can also carry the refer address of the third-party application. When performing security verification, you can determine the current service access request based on the correspondence between the refer address of each third-party application and the identification information. Whether the correspondence between the refer address and identification information of the third-party application carried is correct.

[0086] S203: If the verification is passed, resend the service access request to the first server, so that the first server returns a response message according to the return address specified in the service access request.

[0087] If all checks for a service access request are passed, it can be resent to the first server, and the first server can treat the server request sent by the proxy server as a secure request and return a response message according to the specified return address That's it.

[0088] Example three

[0089] The third embodiment introduces the technical solutions provided by the embodiments of the present application from the perspective of JSSDK. Among them, the JS component corresponding to the specific function in the first server is added to the third-party application, and the code of the JS component automatically downloads the JSSDK provided by the first server to the local third-party application, see image 3 , The method of service access control to third-party applications from the perspective of JSSDK may include the following steps:

[0090] S301: Monitoring operation instructions related to the specific function issued by the user;

[0091] S302: After receiving the operation instruction, generate a service access request;

[0092] When specifically generating a service access request, it can be to determine the API that needs to be called, and assemble the API parameters to generate a request for calling the API. Among them, when assembling API parameters, information used for security verification can be assembled into the API parameters. For example, the identification information issued by the first server to the third-party application can be included, so that the proxy server can determine whether the third-party application has the corresponding relationship between the third-party application and the callable API based on the identification information of the third-party application Permission to call the specified API.

[0093] You can also assemble the refer address of a third-party application into the API parameters, so that the proxy server can determine the refer address of the third-party application carried in the service access request based on the one-to-one correspondence between the refer address of each third-party application and the identification information And whether the corresponding relationship between the identification information is correct.

[0094] In addition, the service access token issued by the first server for the third-party application can be assembled into the API parameters, so that the first server can determine whether the third-party application is sent with the permission of the user according to the service access token. The service access request.

[0095] S303: Send the service access request to the first server, so that the first server sends the service access request to a preset proxy server after determining that the service access request is sent by JSSDK Perform security verification and return a response message after the verification is passed;

[0096] After the service access request is assembled, the JSSDK can send the service access request to the first server according to the URL of the first server without signing. The signature process is replaced by a series of processes such as subsequent verification by the proxy server to ensure security.

[0097] S304: Receive a response message returned by the first server, and provide it to the third-party application for processing.

[0098] Finally, JSSDK can receive the response message returned by the first server and provide it to the third-party application for subsequent interface display and other processing.

[0099] It should be noted that, compared with the first embodiment, the second embodiment and the third embodiment above are only described from a different perspective, and the specific implementation schemes are the same. Therefore, related technical details can be referred to each other, and the details are not repeated here.

[0100] In order to better understand the technical solutions provided by the embodiments of the present application, the following uses a specific example to introduce the embodiments of the present application.

[0101] Assuming that a third-party website adds a JS component corresponding to the "shopping cart" function in an e-commerce trading platform, the user can select the product he likes on the third-party website and perform the "add to shopping cart" operation.

[0102] At this point, JSSDK can determine whether the user has logged in to the e-commerce trading platform, if not logged in, you can jump to the login interface to prompt the user to log in; if you are logged in, you can read from the session parameters of the e-commerce trading platform Take out some information, including the user’s account information, the service access token issued by the first server, etc., assemble this information together with the third-party website’s APPkey, refer address and other information into the API parameters, and send the API call request to The first server. Of course, the request to call the API will also carry specific business data, such as information about the product selected by the user, and so on.

[0103] After receiving the service access request, the first server finds that it was sent by the JSSDK, and can forward the request to the proxy server.

[0104] After the proxy server receives the service access request, it can perform security verification based on the information contained therein, including verification of the API permission group corresponding to the third-party website, the correspondence between the refer address and the APPkey, etc., and the verification passes After that, the service access request can be sent to the first server again. If the verification fails, you can return the message that adding the shopping cart failed.

[0105] After the first server receives the service access request again, it can compare the request sender’s IP address with the preset IP address whitelist. If it appears in the IP address whitelist, it proves to be a service access request from the proxy server Therefore, it can be handled as a safe and reliable service access request, and the operation of adding the specified product to the specified user’s shopping cart is performed according to the business information carried in the request, and the response message is returned according to the return address specified in the request.

[0106] The JSSDK provides the response message to the JS component corresponding to the shopping cart function in the third-party application, and in turn, can display information such as "adding a shopping cart successfully" on the third-party website.

[0107] Corresponding to the service access control method for third-party applications provided in the first embodiment of this application, this embodiment also provides a service access control system for third-party applications, see Figure 4 , The system can include:

[0108] The first judging unit 401 is configured to judge whether the sender of the service access request is the preset JS software development kit JSSDK after receiving the service access request; wherein, the JSSDK is provided by the first server and is provided by the first server. The JS component code added in the third-party application automatically downloads the JSSDK to the local third-party application;

[0109] The sending unit 402 is configured to send the service access request to a preset proxy server if the judgment result of the first judging unit 401 is yes, so that the proxy server can check the service according to the information carried in the service access request. Perform security verification on the service access request, and if the verification passes, then resend the service access request to the first server;

[0110] The second determining unit 403 is configured to determine whether the sender of the service access request is a proxy server after receiving the service access request again;

[0111] The response unit 404 is configured to, if the judgment result of the second judgment unit 403 is yes, return a response message according to the return address specified in the service access request.

[0112] Wherein, the service access request is a request to call a specified application programming interface API, and the service access request carries identification information of a third-party application; the identification information is an identification issued by the first server for the third-party application Correspondingly, the proxy server can determine whether the third-party application has the authority to call the specified API according to the identification information of the third-party application and the preset correspondence between the third-party application and the callable API.

[0113] In a preferred embodiment, the service access request may also carry the refer address of the third-party application, and the refer address corresponds to the identification information issued by the first server; in this case, the proxy server may also The correspondence between the refer address of each third-party application and the identification information is determined, and it is determined whether the correspondence between the refer address of the third-party application and the identification information carried in the service access request is correct.

[0114] During specific implementation, the second determining unit 403 may be specifically used for:

[0115] It is determined whether the IP address of the sender of the request is in the preset IP address white list; wherein, the preset IP address white list stores the IP addresses of each proxy server.

[0116] In practical applications, the system can also include:

[0117] The authorization unit is configured to receive an authorization request from a third-party application, generate an authorization interface according to the authorization requested by the third-party application during registration, and return it, so that the user can authorize the third-party application according to the authorization interface.

[0118] In addition, in order to facilitate the first server to determine whether a service access request was issued with the user's permission, the system may further include:

[0119] The token generating unit is configured to generate a service access token and write it into cookies after receiving the user’s authorization confirmation message, so as to carry the service access token in the service access request, the first server Determine, according to the service access token, whether the third-party application is the service access request sent with the permission of the user.

[0120] Among them, in this embodiment of the application, the service access request has not been signed, so as to avoid the JSSDK from writing to the cookies of the main service platform.

[0121] Corresponding to the method provided in the second embodiment of this application, the embodiment of this application also provides a proxy server that performs service access control on third-party applications, see Figure 5 , The proxy server can include:

[0122] The request receiving unit 501 is configured to receive a service access request sent by the first server; the service access request is a service access request sent by a third-party application to the first server through JSSDK; wherein, the JSSDK is provided by the first server, and The JS component code added in the third-party application automatically downloads the JSSDK to the local third-party application;

[0123] The verification unit 502 is configured to perform security verification on the service access request according to the information carried in the service access request;

[0124] The request sending unit 503 is configured to resend the service access request to the first server if the verification is passed, so that the first server returns a response message according to the return address specified in the service access request.

[0125] Wherein, the service access request is a request to call a specified application programming interface API, and the service access request carries identification information of a third-party application; the identification information is an identification issued by the first server for the third-party application information;

[0126] The checking unit 502 may specifically include:

[0127] The first check subunit is used for judging whether the third-party application has the authority to call the specified API according to the identification information of the third-party application and the preset correspondence between the third-party application and the callable API.

[0128] Wherein, the service access request may also carry a refer address of the third-party application, and the refer address corresponds to the identification information issued by the first server in a one-to-one correspondence;

[0129] The checking unit 502 may further include:

[0130] The second check subunit is used for judging whether the corresponding relationship between the refer address and the identification information of the third-party application carried in the service access request is based on the correspondence between the refer address of each third-party application and the identification information correct.

[0131] In practical applications, the proxy server can also include:

[0132] Call frequency statistics unit, used to count the frequency of each API call;

[0133] The control unit is used for judging whether the frequency of calling an API reaches a preset threshold when receiving a request to call an API, and if so, discarding the request.

[0134] Corresponding to the method provided in the third embodiment of the present application, the embodiment of the present application also provides a service access control device for a third-party application, wherein the third-party application adds JS corresponding to a specific function in the first server. Component, the code of the JS component automatically downloads the JSSDK provided by the first server to the local third-party application, the device may correspond to the JSSDK, see Image 6 , The device may specifically include:

[0135] The monitoring unit 601 is used to monitor operation instructions related to the specific function issued by the user;

[0136] The request generating unit 602 is configured to generate a service access request after receiving the operation instruction;

[0137] The request sending unit 603 is configured to send the service access request to the first server, so that the first server sends the service access request to the first server after determining that the service access request is sent by JSSDK The preset proxy server performs security verification and returns a response message after the verification is passed;

[0138] The response receiving unit 604 is configured to receive the response message returned by the first server and provide it to the third-party application for processing.

[0139] Wherein, the request generating unit 602 may be specifically used for:

[0140] After receiving the operation instruction, determine the API to be called, assemble the API parameters, and generate a request for calling the API.

[0141] Wherein, the API parameters include the identification information issued by the first server to the third-party application, so that the proxy server can determine the third-party application based on the identification information of the third-party application and the preset correspondence between the third-party application and the callable API Whether it has the authority to call the specified API.

[0142] The API parameters may also include the refer address of the third-party application, so that the proxy server can determine the refer address of the third-party application carried in the service access request according to the one-to-one correspondence between the refer address of each third-party application and the identification information. And whether the corresponding relationship between the identification information is correct.

[0143] In addition, the API parameters may also include a service access token issued by the first server for the third-party application, so that the first server can determine whether the third-party application is sent with the permission of the user according to the service access token. Service access request.

[0144] In short, in the embodiment of this application, the third-party application sends service access requests through the JSSDK integrated in the browser. In this way, if other third-party applications want to forge the service access request, they need to know the HTTP protocol in the browser. All parameters, therefore, increase the difficulty of forgery. For the first server, after receiving the service access request sent by JSSDK, it also needs to be sent to the proxy server for security verification. Therefore, the first server only receives the service access request sent by the proxy server again. Will respond, so safety is guaranteed. Among them, it is also possible to restrict the APIs that each third-party application can call, so that a third-party application can only call a limited number of APIs. In this way, even if the service access request is forged, the forger can only obtain Part of the information in the API permission group ensures that most of the user's information is safe.

[0145] From the description of the foregoing implementation manners, it can be known that those skilled in the art can clearly understand that this application can be implemented by means of software plus a necessary general hardware platform. Based on this understanding, the technical solution of this application essentially or the part that contributes to the existing technology can be embodied in the form of a software product, and the computer software product can be stored in a storage medium, such as ROM/RAM, magnetic disk , CD-ROM, etc., including several instructions to enable a computer device (which may be a personal computer, a server, or a network device, etc.) to execute the method described in each embodiment or some parts of the embodiment of this application.