CN109831433B - Third-party-based request encryption method and system between user and server - Google Patents
Third-party-based request encryption method and system between user and server Download PDFInfo
- Publication number
- CN109831433B CN109831433B CN201910092708.7A CN201910092708A CN109831433B CN 109831433 B CN109831433 B CN 109831433B CN 201910092708 A CN201910092708 A CN 201910092708A CN 109831433 B CN109831433 B CN 109831433B
- Authority
- CN
- China
- Prior art keywords
- service provider
- party
- request
- access key
- gateway 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
Images
Landscapes
- Information Transfer Between Computers (AREA)
- Computer And Data Communications (AREA)
Abstract
The invention discloses a request encryption method and a request encryption system between a user and a server based on a third party, which comprise a third party back end, a service provider H5 end and a service provider gateway server end, wherein each end comprises the following steps: a user of a client of a third party clicks an entrance to request to enter a service application provided by a service provider; the third party back end initiates a request for generating an access key AT to the service provider through the service provider gateway server, and the service provider generates the access key AT and transmits the access key AT back to the third party back end through the service provider gateway server. The invention solves the problems of data leakage, uncontrollable data use, increased third party APP size, long access period, complex flow and higher development cost when a service provider accesses a third party service in the prior art, provides a request encryption method and a request encryption system between a user and a service provider based on the third party, and improves the encryption safety by a public key and private key encryption and decryption method when the user requests during application.
Description
Technical Field
The invention relates to a computer network security verification access technology, in particular to a request encryption method and a request encryption system between a user and a server based on a third party.
Background
Existing third party access service provider service methods can be roughly divided into two categories: (1) an interface access method. The service provider provides an interface, and a third party submits a request and acquires return data through a background request server interface; (2) and (3) an SDK access method. And the third party introduces the SDK of the service provider to join the own APP, and requests to call the service party interface to submit the request and acquire the returned data through a method provided by the SDK.
The interface access method is characterized in that a request is initiated by a background service of a third party, but not a direct request of a front-end code of a foreground, a service provider interface is not exposed at the front end, and a back-end agreed encryption authentication flow is accessed at the back end, so that the interface safety of the service provider is guaranteed, even if an abnormal condition occurs, the service provider can timely limit the current or cut off the service to a certain third party, and great loss is avoided. However, this access method has a drawback that only the provided interface unconditionally returns a corresponding result as long as the third party initiates a request for passing authentication, but there is no restriction on the third party, and the third party can retain data to establish its second local library, modify and modify the data and return the modified data to the front-end user, and the service provider cannot control and identify such actions, which may bring a certain reputation risk to the service provider, especially in the financial industry, such a risk is particularly prominent in terms of competition in the same industry and financial compliance.
For example, an APP with the name of a certain bank provides the service of opening two types of accounts on line, and is really cooperative with a certain bank, a certain bank provides two types of account opening interfaces, but the three-party APP retains sensitive information provided by the user registering the second class of users before requesting the interface, such as name, ID card, mobile phone number, and even the image data of the front and back sides of ID card, and the image data of hand-held ID card, the important information is retained by the third party but certain bank cannot be judged, because the information is sent by the third party, as for what certain bank can not be controlled before, the user also considers that the information of the user is given to certain bank, the important information which is not known to the user is also retained to the third party, the risk brought in the follow-up process is difficult to estimate, and if the information is leaked by the third party or utilized to do some illegal events, the reputation risk can be generated in certain bank.
The SDK access method is divided into two types, one is the SDK without the front end page, and the other is the SDK with the front end page.
The principle of the access method without the front-end page SDK is that a service provider provides a native SDK to be added into a third-party APP, the third-party development front end calls a method in the SDK to carry out an encryption authentication process, the interface of the service provider is requested to acquire data through the authenticated interface request method provided by the SDK, the authentication is only put at a primary end but not at a back end, so that the interface of the service provider and the encryption and decryption authentication method can be found only by decompiling and cracking the APP of a third party and the primary SDK of the service provider in terms of safety, the conventional APP is generally reinforced and shelled, therefore, the security is still harder to break, but is slightly less secure than the interface access method, because the difficulty of breaking the decompilation of an APP is still smaller than the difficulty of breaking a back-end server, this method also risks third parties to retain data and modify data, as does the interface access method.
The principle of the access method including the front-end page SDK is that the SDK provided by the service provider not only provides an authentication and request method, but also provides the front-end page in the SDK, the third party only needs to call up a starting method of the SDK, the subsequent pages and the data interaction of the pages are all self-owned by the service provider, the third party has no relation at all, and only one result is returned to the third party after the service flow of the service provider is completed, in this way, the self-help service system can be regarded as an independent service supply by the self, thereby avoiding the risk of three parties retaining data and modifying data in an interface access method and an access method without a front-end page SDK, because the third party does not know how you are interacting at all, the entire process is a black box for the third party unless the third party is going to crack the SDK provided by the decompiling service provider. The development amount is very small when the third party accesses, the access is fast, the third party is happy, and certainly, as with the access method without the front-end page SDK, if someone cracks the APP of the decompiling third party and further cracks the SDK of the service provider, the interface and the encryption and decryption authentication method of the service provider can be found out.
However, the SDK access mode in the market at present has no interface access mode, and there are three points to the reason.
First, what many third parties are not well able to accept is that joining the SDK can increase the size of their APP, because the APP is too large, can directly result in the user not being able to download the APP in time (apple APP store exceeds 150M and cannot be downloaded with traffic, many mainstream android application markets also have similar settings), meet a service and add an SDK, whichever APP now certainly does not meet a service provider more than, if each family is the mode that the SDK accesses, the size of this APP can certainly not be small, except for platform restriction, the APP too large user also is not willing to spend traffic and memory space to download, this can directly influence the installation rate and the rate of usage of this APP, influence its propagation and marketing.
Second, issue the version problem, after the third party adds the SDK, APP will be updated after, new function just can be opened, will go to once to send the version flow, goes apple shop and android application market to go to upload the package again, wants the user to go to update this APP of installation on his cell-phone, and whole cycle is very long uncontrollable, and the flow is loaded down with trivial details, and the transmission conversion rate is lower, experiences also than the poor to the user.
Third, many service providers are also reluctant to use SDK access because, in addition to being less acceptable by third parties, development and maintenance costs, one version of IOS, one version of Android, and the costs of maintaining and developing both versions are relatively large.
Therefore, although the access method comprising the front page SDK looks good, more service providers are willing to select a third party which believes cooperation and are not willing to use the method, the service providers sell own services after all, the third parties are clients of the service providers, and the clients are enabled to more conveniently access own services on the premise of safety by taking the benefits of the clients as starting points. Although the interface access method used by the third party has a small development amount, the data can be stored, the third party can master the data, and the third party can accept the data.
Disclosure of Invention
The invention solves the problems of data leakage, uncontrollable data use, increased third party APP size, long access period, complex flow and higher development cost when a service provider accesses a third party service in the prior art, provides a request encryption method and a request encryption system between a user and a service provider based on the third party, and improves the encryption safety by a public key and private key encryption and decryption method when the user requests during application.
The invention is realized by the following technical scheme:
the request encryption method between the user and the server based on the third party comprises a third party back end, a service provider H5 end and a service provider gateway server end, and the interaction of the ends comprises the following steps:
A. a user of a client of a third party clicks an entrance request to enter a service application provided by a service provider and notifies a message to the back end of the third party;
B. the third party back end initiates a request for generating an access key AT to the service provider through the service provider gateway server, and the service provider generates the access key AT and transmits the access key AT back to the third party back end through the service provider gateway server;
C. after receiving the encrypted AT, the third party back end decrypts the AT, and the reverse AT obtains the AK, wherein the AK is an asymmetric encrypted public key of a gateway server of the service provider, the URL address of the H5 end of the service provider is opened in the webView of the third party with the parameters AT and AK, and the H5 end of the service provider temporarily stores the AT and the AK in a sessionStorage of an embedded APP browser of the third party.
Further, based on the request encryption method between the user of the third party and the server, in step B, the back end of the third party initiates a request for generating the access key AT to the service provider through the gateway server of the service provider, and the transfer parameters of the request include a registered account siteld of the third party on the service provider, an account appId of the service provider H5, and a three-party account userId of the client of the third party.
Further, based on the request encryption method between the user of the third party and the service provider, the specific process in the step B in which the service provider generates the access key AT and transmits the access key AT back to the back end of the third party through the gateway server of the service provider is as follows: and the service provider authentication end decrypts the check label and verifies the registered account siteId of the third party AT the service provider and the account appId of the service provider H5, and then returns the encrypted access key AT.
Further, the access key AT is reversible based on the request encryption method between the user of the third party and the service party.
Further, based on the request encryption method between the user of the third party and the server, the access key AT in the step B includes an asymmetrically encrypted public key AK of the gateway server of the service provider, and the service provider stores the asymmetrically encrypted private key SK.
The request encryption system based on the third party between the user and the server comprises a third party back end, a service provider H5 end and a service provider gateway server end, wherein:
the third-party back end is used for receiving a message that a user of a third-party client clicks an entrance to request to enter a service application provided by a service provider, initiating a request for generating an access key AT to the service provider through a gateway server of the service provider, decrypting the AT after receiving the encrypted AT, obtaining AK through a reverse AT, and opening a URL address of an H5 end of the service provider in a third-party webView through parameters AT and AK;
and the service provider H5 end is used for the service provider to generate an access key AT and transmit the access key AT back to the third party back end through the service provider gateway server end, and is also used for temporarily storing the AT and AK in the sessionStorage of the embedded browser of the third party APP.
Further, based on a request encryption system between a user of a third party and a server, the AK is a public key of asymmetric encryption of a gateway server of the service provider.
Compared with the prior art, the invention has the following advantages and beneficial effects:
1. the invention improves the encryption safety by the public key and private key encryption and decryption method when the user requests.
2. When the method is applied, the whole process is developed by a service provider, data cannot be leaked to any third party, the problems that the size of the APP of the third party is increased and the edition needs to be re-issued do not exist, only one skip needs to be configured in the background of the third party, and the whole development cost is controllable.
Drawings
The accompanying drawings, which are included to provide a further understanding of the embodiments of the invention and are incorporated in and constitute a part of this application, illustrate embodiment(s) of the invention and together with the description serve to explain the principles of the invention. In the drawings:
FIG. 1 is a schematic structural view of the present invention;
fig. 2 is a timing chart of the external output according to the present invention.
Detailed Description
In order to make the objects, technical solutions and advantages of the present invention more apparent, the present invention is further described in detail below with reference to examples and accompanying drawings, and the exemplary embodiments and descriptions thereof are only used for explaining the present invention and are not meant to limit the present invention.
Example 1
As shown in fig. 1 to fig. 2, the third party secure access method in the form of the application of the service provider H5 includes a third party backend, a service provider H5 terminal, a service provider gateway server terminal, a service provider authentication terminal, and a service provider backend, and each terminal interactively includes the following steps:
A. a user of a client of a third party clicks an entrance request to enter a service application provided by a service provider and notifies a message to the back end of the third party;
B. the third party back end initiates a request (Access Token, AT for short) for generating an Access key AT to the service provider through the gateway server of the service provider, and the service provider generates the Access key AT and transmits the Access key AT back to the third party back end through the gateway server of the service provider;
C. after receiving the encrypted AT, the third party back end decrypts the AT, and the reverse AT obtains an AK (AppKey, AK for short), wherein the AK is an asymmetric encrypted public key of a gateway server of a service provider, the URL address of the H5 end of the service provider is opened in the webView of the third party with parameters of the AT and the AK, and the H5 end of the service provider temporarily stores the AT and the AK in a sessionStorage of an embedded browser of the APP of the third party.
And in the step B, the third party back end initiates a request for generating the access key AT to the service provider through the gateway server of the service provider, wherein the transfer parameters of the request comprise a registration account siteId of the third party on the service provider, an account appId of the H5 of the service provider and a three-party account userId of a client of the third party.
The specific process that the service provider generates the access key AT and transmits the access key AT back to the third party back end through the gateway server of the service provider in the step B is as follows: and the service provider authentication end decrypts the check label and verifies the registered account siteId of the third party AT the service provider and the account appId of the service provider H5, and then returns the encrypted access key AT. The access key AT is reversible.
The access key AT in the step B includes an asymmetrically encrypted public key AK of the gateway server of the service provider, and a secretekey (SK for short) stored in the authentication side of the service provider.
The invention overcomes the defects of data leakage, uncontrollable data use, increased third party APP size, long access period, complex flow and higher development cost existing in the prior art when the service of the service provider is accessed to the third party, the whole H5 application is developed by the service provider, the third party only needs to initiate a request by the background to take a key to transmit to the H5 home page of the service provider, the rest processes are unrelated to the third party, data cannot be leaked to any third party, the problems of increasing the size of the APP of the third party and needing to be re-published do not exist due to the application of H5, only a jump needs to be configured at the background of the third party, the whole development cost is controllable, one set of H5 can be accessed to the IOS, Android and H5 terminals, all access parties are modified and synchronized together every time, no perception updating is performed, the online speed is high, the reusability is strong, flow control can be achieved, and flow limitation and rejection can be performed according to the key classification request party. The cracking cost of the whole method is very high.
In the invention, AT consumes once, and becomes invalid after VT is generated; all data cached in sessionStorage of webview of the three-party APP AT the service provider H5 side are encrypted by using AT as key and then cached.
Example 2
The request encryption system based on the third party between the user and the server comprises a third party back end, a service provider H5 end and a service provider gateway server end, wherein:
the third-party back end is used for receiving a message that a user of a third-party client clicks an entrance to request to enter a service application provided by a service provider, initiating a request for generating an access key AT to the service provider through a gateway server of the service provider, decrypting the AT after receiving the encrypted AT, obtaining AK through a reverse AT, and opening a URL address of an H5 end of the service provider in a third-party webView through parameters AT and AK;
and the service provider H5 end is used for the service provider to generate an access key AT and transmit the access key AT back to the third party back end through the service provider gateway server end, and is also used for temporarily storing the AT and AK in the sessionStorage of the embedded browser of the third party APP.
The AK is an asymmetric encrypted public key of a gateway server side of the service provider.
The above-mentioned embodiments are intended to illustrate the objects, technical solutions and advantages of the present invention in further detail, and it should be understood that the above-mentioned embodiments are merely exemplary embodiments of the present invention, and are not intended to limit the scope of the present invention, and any modifications, equivalent substitutions, improvements and the like made within the spirit and principle of the present invention should be included in the scope of the present invention.
Claims (5)
1. The method for encrypting the request between the user and the server based on the third party is characterized by comprising a third party back end, a service provider H5 end and a service provider gateway server end, wherein the interaction of the third party back end, the service provider H5 end and the service provider gateway server end comprises the following steps:
A. a user of a client of a third party clicks an entrance request to enter a service application provided by a service provider and notifies a message to the back end of the third party;
B. the third party back end initiates a request for generating an access key AT to the service provider through the service provider gateway server, the service provider generates the access key AT and transmits the access key AT back to the third party back end through the service provider gateway server, the transmission parameters of the request comprise a registration account siteId of the third party AT the service provider, an account appId of the service provider H5 and a three-party account userId of a client of the third party, and the specific process of the service provider generating the access key AT and transmitting the access key AT back to the third party back end through the service provider gateway server in the step B is as follows: the service provider authentication end decrypts the verification signature and verifies the registration account siteId of the third party in the service provider and the account appId of the service provider H5 end, and then the encrypted access key AT is returned;
C. after receiving the encrypted AT, the third party back end decrypts the AT, and the reverse AT obtains the AK, wherein the AK is an asymmetric encrypted public key of a gateway server of the service provider, the URL address of the H5 end of the service provider is opened in the webView of the third party with the parameters AT and AK, and the H5 end of the service provider temporarily stores the AT and the AK in a sessionStorage of an embedded APP browser of the third party.
2. The method of claim 1, wherein the access key AT is reversible.
3. The method as claimed in claim 1, wherein the access key AT in step B includes a public key AK asymmetrically encrypted by the service provider gateway server, and the private key SK asymmetrically encrypted by the service provider authentication server is stored in the service provider authentication server.
4. The request encryption system based on the third party between the user and the server is characterized by comprising a third party back end, a service provider H5 end and a service provider gateway server end, wherein:
the third-party back end is used for receiving a message that a user of a third-party client clicks an entrance to request to enter a service application provided by a service provider, initiating a request for generating an access key AT to the service provider through a gateway server of the service provider, decrypting the AT after receiving the encrypted AT, obtaining AK through a reverse AT, and opening a URL address of an H5 end of the service provider in a third-party webView through parameters AT and AK; the transfer parameters of the request comprise a registered account siteId of the third party at the service provider, an account appId at the H5 end of the service provider, and a three-party account userId of a client of the third party,
the service provider H5 end is used for the service provider to generate an access key AT and transmit the access key AT back to the third party back end through the service provider gateway server end, and is also used for temporarily storing the AT and AK in the sessionStorage of the embedded browser of the third party APP; the specific process that the service provider generates the access key AT and transmits the access key AT back to the third party back end through the gateway server of the service provider is as follows: and the service provider authentication end decrypts the check label and verifies the registered account siteId of the third party AT the service provider and the account appId of the service provider H5, and then returns the encrypted access key AT.
5. The system of claim 4, wherein the AK is a public key for asymmetric encryption of the service provider gateway server.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN201910092708.7A CN109831433B (en) | 2019-01-30 | 2019-01-30 | Third-party-based request encryption method and system between user and server |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN201910092708.7A CN109831433B (en) | 2019-01-30 | 2019-01-30 | Third-party-based request encryption method and system between user and server |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| CN109831433A CN109831433A (en) | 2019-05-31 |
| CN109831433B true CN109831433B (en) | 2021-05-11 |
Family
ID=66863103
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN201910092708.7A Active CN109831433B (en) | 2019-01-30 | 2019-01-30 | Third-party-based request encryption method and system between user and server |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN109831433B (en) |
Citations (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN101197027A (en) * | 2006-12-04 | 2008-06-11 | 深圳市星渡科技有限公司 | Internet service paying method and system based on common terminal |
| CN109040161A (en) * | 2017-10-26 | 2018-12-18 | 北京航天智造科技发展有限公司 | Cloud manufacturing service management system and device, method |
| CN109274646A (en) * | 2018-08-22 | 2019-01-25 | 华东计算技术研究所（中国电子科技集团公司第三十二研究所） | Key management client server side method, system and medium based on KMIP protocol |
Family Cites Families (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US20090106251A1 (en) * | 2001-10-24 | 2009-04-23 | Harris Scott C | Web based communication of information with reconfigurable format |
-
2019
- 2019-01-30 CN CN201910092708.7A patent/CN109831433B/en active Active
Patent Citations (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN101197027A (en) * | 2006-12-04 | 2008-06-11 | 深圳市星渡科技有限公司 | Internet service paying method and system based on common terminal |
| CN109040161A (en) * | 2017-10-26 | 2018-12-18 | 北京航天智造科技发展有限公司 | Cloud manufacturing service management system and device, method |
| CN109274646A (en) * | 2018-08-22 | 2019-01-25 | 华东计算技术研究所（中国电子科技集团公司第三十二研究所） | Key management client server side method, system and medium based on KMIP protocol |
Non-Patent Citations (1)
| Title |
|---|
| 《多服务器架构下认证与密钥协商协议》;万涛;《计算机研究与发展》;20161130;全文 * |
Also Published As
| Publication number | Publication date |
|---|---|
| CN109831433A (en) | 2019-05-31 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CN109889510B (en) | Multiple encryption method for service provider transmitting service message | |
| EP2859488B1 (en) | Enterprise triggered 2chk association | |
| EP2859489B1 (en) | Enhanced 2chk authentication security with query transactions | |
| US11658963B2 (en) | Cooperative communication validation | |
| JP2007089200A (en) | Third party access gateway for communication service | |
| JP2007089199A (en) | Third party access gateway for communication service | |
| JP2019503533A5 (en) | ||
| CN106953831A (en) | A kind of authorization method of user resources, apparatus and system | |
| CN109977703A (en) | A kind of encryption method of safety keyboard, storage medium and terminal device | |
| CN109831431B (en) | Random number encryption method for service provider to initiate generation of access request | |
| TW201123808A (en) | Provider management method, provider management system and machine-readable storage medium | |
| CN109831432B (en) | Third-party secure access method in application form of service provider H5 | |
| CN106664535A (en) | Information sending method and apparatus, terminal device, and system | |
| CN109831433B (en) | Third-party-based request encryption method and system between user and server | |
| US11290878B2 (en) | Components, system, platform and methodologies for mediating and provisioning services and product delivery and orchestrating, mediating and authenticating transactions and interactions | |
| CN114157425A (en) | Method and device for responding service request | |
| KR102350463B1 (en) | Information display method and apparatus, storage medium and electronic device | |
| CN106534047A (en) | Information transmitting method and apparatus based on Trust application | |
| CN111832055A (en) | Authority verification system and method | |
| CN110035116A (en) | The method and apparatus of user-association | |
| WO2024082866A1 (en) | Two-dimensional code anti-counterfeiting system and method, and related device | |
| US11902266B1 (en) | Systems and methods for generating and using secure sharded onboarding user interfaces | |
| WO2024066749A1 (en) | Blockchain transaction execution method and apparatus, program product, device, and medium | |
| CN116028120A (en) | Application calling method and device | |
| CN116384991A (en) | Transfer payment method, device, equipment, medium and product |
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 |