CN114297594A - Method for identity authentication in web application - Google Patents
Method for identity authentication in web application Download PDFInfo
- Publication number
- CN114297594A CN114297594A CN202111631354.2A CN202111631354A CN114297594A CN 114297594 A CN114297594 A CN 114297594A CN 202111631354 A CN202111631354 A CN 202111631354A CN 114297594 A CN114297594 A CN 114297594A
- Authority
- CN
- China
- Prior art keywords
- request
- parameter
- assigning
- parameters
- signature
- 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.)
- Pending
Links
- 238000000034 method Methods 0.000 title claims abstract description 36
- 238000013475 authorization Methods 0.000 claims abstract description 6
- 238000006243 chemical reaction Methods 0.000 claims description 9
- 230000008676 import Effects 0.000 claims description 6
- 238000012545 processing Methods 0.000 claims description 6
- FGUUSXIOTUKUDN-IBGZPJMESA-N C1(=CC=CC=C1)N1C2=C(NC([C@H](C1)NC=1OC(=NN=1)C1=CC=CC=C1)=O)C=CC=C2 Chemical compound C1(=CC=CC=C1)N1C2=C(NC([C@H](C1)NC=1OC(=NN=1)C1=CC=CC=C1)=O)C=CC=C2 FGUUSXIOTUKUDN-IBGZPJMESA-N 0.000 claims description 4
- 238000012795 verification Methods 0.000 abstract description 8
- 230000007547 defect Effects 0.000 abstract description 2
- 230000002708 enhancing effect Effects 0.000 abstract 1
- 235000014510 cooky Nutrition 0.000 description 8
- 238000006467 substitution reaction Methods 0.000 description 2
- 239000008186 active pharmaceutical agent Substances 0.000 description 1
- 238000013459 approach Methods 0.000 description 1
- 230000009286 beneficial effect Effects 0.000 description 1
- 238000004364 calculation method Methods 0.000 description 1
- 238000011161 development Methods 0.000 description 1
- 238000010586 diagram Methods 0.000 description 1
- 238000005516 engineering process Methods 0.000 description 1
- 230000000977 initiatory effect Effects 0.000 description 1
- 230000002452 interceptive effect Effects 0.000 description 1
Images
Landscapes
- Storage Device Security (AREA)
Abstract
The invention discloses a method for identity authentication in web application, which realizes authentication by calculating an Authorization field required in a header to fill in a signature value, and adds the signature value in the header when each request is required, thereby avoiding the defect caused by the fact that each request needs to carry a token, improving the verification efficiency and enhancing the safety.
Description
Technical Field
The invention relates to the technical field of web applications, in particular to a method for performing identity authentication in web applications.
Background
At the beginning of the birth of the internet, the Web is basically just a browsing of documents. Since browsing, as a server, there is no need to record what documents a user browses for a certain period of time, and each request is a new HTTP protocol, i.e. request plus response.
However, with the rise of interactive Web applications, such as online shopping websites, websites needing to be logged in, and the like, a problem is faced, that is, to manage sessions, it is necessary to remember which users log in the system, which users put goods in their shopping carts, that is, each user needs to be distinguished, which is a challenge, because HTTP requests are stateless, a method is devised to send a session identifier (session id), that is, a random string, to each user, which is different, and each time an HTTP request is initiated, the string is sent to the server together, and the server can distinguish which user initiated the request.
This approach, while enabling identification of the user, increases the pressure on the server. Although each user only needs to save its session id, the server needs to save all users' session ids. If there are many access servers, there will be thousands, even hundreds of thousands, of session ids. Therefore, with the development of web technologies, in order to verify the validity of a request, checking is generally performed through three ways, namely cookie, session and token.
The cookie is generated by the server and sent to the browser, the browser stores the cookie into a text file in a certain directory in the form of key and value, and the cookie is sent to the server when the same website is requested next time. Since cookies are present on the client, the number of cookies per domain is limited because the browser adds some restrictions to ensure that cookies are not used maliciously, while not taking up too much disk space.
The server uses the session to temporarily store the information of the user on the server, and the session is destroyed after the user leaves the website. This way of storing user information is more secure than cookies, however, session has a drawback: if the web server performs load balancing, the session is lost when the next operation request arrives at another server; and if the verification information exists in the session, the pressure stored by the server side is increased.
In most internet companies using Web APIs, tokens are the best way to handle authentication under multiple users, and there are several characteristics in using tokens for identity verification: 1. stateless, extensible 2. support mobile device 3. cross-program call; but also has the disadvantages that if the verification information exists in the database, the user id is searched according to the token every time, and the expense of the database is increased; token, once intercepted, is easily subject to cross-site request forgery.
Disclosure of Invention
The invention aims to provide a method for identity authentication in web application to solve the problem, and the essence of the method for solving the problem is how to calculate the Authorization field required to be filled in the header so as to realize authentication. The method adds the request in the header every time, thereby avoiding the defect brought by the fact that each request needs to carry a token. Therefore, the verification efficiency is improved, and the safety is enhanced. The core of the invention is how to calculate the signature value, and once the calculation is completed, the signature value is assigned to Authorization for use.
The invention realizes the purpose through the following technical scheme:
a method of identity authentication in a web application, comprising the steps of:
the method comprises the following steps: generating request line parameters:
step two: introduce app _ secret:
storing app _ secret locally using Store;
introducing a Store in the file, and introducing app _ secret by using a getStr function of the Store;
step three: introducing CryptoJS:
install third party library using npm package manager: crypto-js/crypto-js;
then import into the file using import;
step four: encryption:
transferring two parameters to the HmacSHA256 function of CryptoJS, wherein the two parameters are apiRequestLineString obtained in the first step f and app _ secret introduced in the second step f respectively, and then assigning values to signInitialValue;
step five: and (3) encoding:
performing base64 encoding on the signInitalValue obtained in the step four by using a CryptoJS.enc.Base64.string function, and assigning a value to base64 String;
step six: and (3) carrying out urlcode coding:
and (4) carrying out urlcode coding on the base64String obtained in the step five by using js built-in encodericomponent function, and assigning to the signature.
Further, the specific method in the step 1 is as follows:
a. acquiring the current time of the browser by using a js time object new Date (), performing format conversion by using toutCString, and generating a current time character string currentDateString;
b. acquiring a current path; processing the url in the config parameter in the interceptor to obtain currentPath;
c. judging what request the current method belongs to according to the method parameter value in the config; if the request is a get request or a delete request, converting the get request or the delete request into an upper case assignment to be given to a variable apiRequestMethod;
d. define a request line variable: apiRequestLine; if the request method has parameters, the parameters are processed firstly, and are connected by using the symbols, and the paramsArrays is assigned with values;
e. is currentPath and paramsArrays used in step b? The numbers are concatenated and then assigned to the apiRequestLine defined in step 3. If there are no parameter values, then apiRequestLine is directly equal to currentPath;
f. adding \ n to currentDateString in the step a, then adding apiRequestMethod in the step c, splicing apiRequestLine and http in the step e together to form a character string, and then assigning to a variable apiRequestLineString.
The method further comprises the following steps: string conversion is carried out on data in config by using a JSON.
And performing character string conversion on the encryption result.
The method further comprises the following steps: splicing the signature calculated in the step six into
"hmacaccessekey" $ { accesskey } ", algorithm ═ HMAC _ SHA256", heads ═ x-date request-line ", signature $ { signature }", in a character string;
adding an Authorization parameter into the header, and assigning the character string obtained in the step one to the parameter;
adding an x-date parameter into the header, and assigning the time obtained in the step b in the step one to the parameter;
according to different request modes of get, post, put, patch and delete, different processing is respectively carried out.
If the request is the get request, the body does not need to be encrypted, and the request _ line is directly signed;
if the request is post, put, patch, delete, these several request modes are processed together, the Digest parameter is added to the header, and the parameter is assigned with' SHA _256 $ { post _ body _ to _ url }.
The invention has the beneficial effects that:
the token is not required to be transmitted in the header every time the front-end application initiates a request to the server;
the method and the device improve the security of the front-end application for initiating the request to the server, avoid the possibility of intercepting the token and improve the security.
The pressure of the server side on the validity verification of the request initiated by the front-end application is relieved, each interface request is not required to be verified, but the identity authentication is already carried out before, and the verification efficiency is improved.
Drawings
In order to more clearly illustrate the technical solutions in the embodiments of the present invention, the following briefly introduces the embodiments or the drawings needed to be practical in the prior art description, and obviously, the drawings in the following description are only some embodiments of the present invention, and other drawings can be obtained by those skilled in the art without creative efforts.
FIG. 1 is a flow chart of the present invention for authentication using a token.
FIG. 2 is an architecture diagram of the present invention for using signature for identity verification.
FIG. 3 is a flow chart of the present invention for computing a signature.
Detailed Description
In order to make the objects, technical solutions and advantages of the present invention more apparent, the technical solutions of the present invention will be described in detail below. It is to be understood that the described embodiments are merely exemplary of the invention, and not restrictive of the full scope of the invention. All other embodiments, which can be derived by a person skilled in the art from the examples given herein without any inventive step, are within the scope of the present invention.
In any embodiment, as shown in fig. 1 to 3, a method for performing identity authentication in a web application of the present invention first introduces a case if it is a get or delete request:
the method comprises the following steps: generating request line parameters:
1. acquiring the current time of the browser by using a js time object new Date (), performing format conversion by using toutCString, and generating a current time character string currentDateString;
2. and acquiring the current path. The currentPath is obtained by processing url in config parameter in the interceptor.
3. And judging what request is requested by the current method according to the parameter value of the method in the config. If it is a get request or delete request,
firstly, converting the upper case into an upper case assignment to be given to a variable apiRequestMethod;
4. define a request line variable: apiRequestLine. If the request method has parameters, the parameters are processed firstly, and are connected by using the symbols, and the paramsArrays is assigned with values;
5. is currentPath and paramsArrays used in step 2? The numbers are concatenated and then assigned to the apiRequestLine defined in step 3. If there are no parameter values, then apiRequestLine is directly equal to currentPath;
6. adding \ n to currentDateString in the step 1, then adding apiRequestMethod in the step 3, adding apiRequestLine and http in the step 5, splicing together into a character string, and then assigning to a variable apiRequestLineString.
Step two: introduce app _ secret:
1. firstly, storing app _ secret locally by using Store;
2. store is introduced in the file, and app _ secret is introduced using the getStr function of Store.
Step three: introducing CryptoJS:
1. the third party library is first installed using the npm package manager: Crypto-js/Crypto-js.
2. Then import into the file using import;
step four: encryption:
and (3) transmitting two parameters to the HmacSHA256 function of CryptoJS, wherein the two parameters are apiRequestLineString obtained in the first step 6 and app _ secret introduced in the second step, and then assigning values to signInitialValue.
Step five: and (3) encoding:
and B, performing base64 encoding on the signInitialValue obtained in the step four by using a CryptoJS.enc.Base64.string function, and assigning a value to base64 String.
Step six: and (3) carrying out urlcode coding:
and (4) carrying out urlcode coding on the base64String obtained in the step five by using js built-in encodericomponent function, and assigning to the signature.
The above is the case of a get or delete request, and the case of a post request is described next. They differ mainly in that post requests require encryption of the body request body:
the method comprises the following steps: firstly, using JSON.stringiness function to perform character string conversion on data in config;
step two: as with the get method, only string conversion of the encrypted result is required.
The following steps are the same as the get method.
Through the above steps, the value of signature has already been obtained. After deriving the signature, how to use the signature result will be described in detail as follows:
the method comprises the following steps: splicing the signature calculated in the step 4 into
"hmacaccessekey" $ { accesskey } ", algorithm ═ HMAC _ SHA256", heads ═ x-date request-line ", signature $ { signature }", in a character string;
step two: adding an Authorization parameter into the header, and assigning the character string obtained in the step one to the parameter;
step three: and adding an x-date parameter to the header, and assigning the time obtained in the step two of the step 1 to the parameter. Note that:
the date parameter cannot be directly added, otherwise the browser reports an error;
step four: according to different request modes of get, post, put, patch and delete, different processing is respectively carried out.
If the request is the get request, the body does not need to be encrypted, and the request _ line is directly signed; if the request is post, put, patch, delete, the 4-clock request modes can be processed together, a Digest parameter needs to be added to the header, and the parameter is assigned with' SHA _256 $ { post _ body _ to _ url }.
The above description is only for the specific embodiments of the present invention, but the scope of the present invention is not limited thereto, and any person skilled in the art can easily conceive of the changes or substitutions within the technical scope of the present invention, and all the changes or substitutions should be covered within the scope of the present invention. Therefore, the protection scope of the present invention shall be subject to the protection scope of the appended claims. It should be noted that the various technical features described in the above embodiments can be combined in any suitable manner without contradiction, and the invention is not described in any way for the possible combinations in order to avoid unnecessary repetition. In addition, any combination of the various embodiments of the present invention is also possible, and the same should be considered as the disclosure of the present invention as long as it does not depart from the spirit of the present invention.
Claims (5)
1. A method of identity authentication in a web application, comprising the steps of:
the method comprises the following steps: generating request line parameters:
step two: introduce app _ secret:
storing app _ secret locally using Store;
introducing a Store in the file, and introducing app _ secret by using a getStr function of the Store;
step three: introducing CryptoJS:
install third party library using npm package manager: crypto-js/crypto-js;
then import into the file using import;
step four: encryption:
transferring two parameters to the HmacSHA256 function of CryptoJS, wherein the two parameters are apiRequestLineString obtained in the first step f and app _ secret introduced in the second step f respectively, and then assigning values to signInitialValue;
step five: and (3) encoding:
performing base64 encoding on the signInitalValue obtained in the step four by using a CryptoJS.enc.Base64.string function, and assigning a value to base64 String;
step six: and (3) carrying out urlcode coding:
and (4) carrying out urlcode coding on the base64String obtained in the step five by using js built-in encodericomponent function, and assigning to the signature.
2. The method for identity authentication in a web application according to claim 1, wherein the specific method in step 1 is as follows:
a. acquiring the current time of the browser by using a js time object new Date (), performing format conversion by using toutCString, and generating a current time character string currentDateString;
b. acquiring a current path; processing the url in the config parameter in the interceptor to obtain currentPath;
c. judging what request the current method belongs to according to the method parameter value in the config; if the request is a get request or a delete request, converting the get request or the delete request into an upper case assignment to be given to a variable apiRequestMethod;
d. define a request line variable: apiRequestLine; if the request method has parameters, the parameters are processed firstly, and are connected by using the symbols, and the paramsArrays is assigned with values;
e. is currentPath and paramsArrays used in step b? The numbers are concatenated and then assigned to the apiRequestLine defined in step 3. If there are no parameter values, then apiRequestLine is directly equal to currentPath;
f. adding \ n to currentDateString in the step a, then adding apiRequestMethod in the step c, splicing apiRequestLine and http in the step e together to form a character string, and then assigning to a variable apiRequestLineString.
3. The method of identity authentication in a web application of claim 1, further comprising the steps of: string conversion is carried out on data in config by using a JSON.
And performing character string conversion on the encryption result.
4. The method of identity authentication in a web application of claim 1, further comprising the steps of: splicing the signature calculated in the step six into
"hmacaccessekey" $ { accesskey } ", algorithm ═ HMAC _ SHA256", heads ═ x-date request-line ", signature $ { signature }", in a character string;
adding an Authorization parameter into the header, and assigning the character string obtained in the step one to the parameter;
adding an x-date parameter into the header, and assigning the time obtained in the step b in the step one to the parameter;
according to different request modes of get, post, put, patch and delete, different processing is respectively carried out.
5. The method of claim 1, wherein if the request is a get request, the request _ line is directly signed without encrypting the body;
if the request is post, put, patch, delete, these several request modes are processed together, the Digest parameter is added to the header, and the parameter is assigned with' SHA _256 $ { post _ body _ to _ url }.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202111631354.2A CN114297594A (en) | 2021-12-28 | 2021-12-28 | Method for identity authentication in web application |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202111631354.2A CN114297594A (en) | 2021-12-28 | 2021-12-28 | Method for identity authentication in web application |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| CN114297594A true CN114297594A (en) | 2022-04-08 |
Family
ID=80971329
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN202111631354.2A Pending CN114297594A (en) | 2021-12-28 | 2021-12-28 | Method for identity authentication in web application |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN114297594A (en) |
Citations (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US20170208151A1 (en) * | 2014-10-02 | 2017-07-20 | Reylabs Inc. | Systems and methods involving diagnostic monitoring, aggregation, classification, analysis and visual insights |
| CN110933084A (en) * | 2019-11-29 | 2020-03-27 | 深圳乐信软件技术有限公司 | Cross-domain shared login state method, device, terminal and storage medium |
| CN112600817A (en) * | 2020-12-08 | 2021-04-02 | 四川长虹电器股份有限公司 | Signature authentication method during interface request of front-end application |
-
2021
- 2021-12-28 CN CN202111631354.2A patent/CN114297594A/en active Pending
Patent Citations (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US20170208151A1 (en) * | 2014-10-02 | 2017-07-20 | Reylabs Inc. | Systems and methods involving diagnostic monitoring, aggregation, classification, analysis and visual insights |
| CN110933084A (en) * | 2019-11-29 | 2020-03-27 | 深圳乐信软件技术有限公司 | Cross-domain shared login state method, device, terminal and storage medium |
| CN112600817A (en) * | 2020-12-08 | 2021-04-02 | 四川长虹电器股份有限公司 | Signature authentication method during interface request of front-end application |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| WO2017028804A1 (en) | Web real-time communication platform authentication and access method and device | |
| CN109922077B (en) | Identity authentication method and system based on block chain | |
| CN106209749B (en) | Single sign-on method and device, and related equipment and application processing method and device | |
| CN101938473B (en) | Single-point login system and single-point login method | |
| CN102201915B (en) | Terminal authentication method and device based on single sign-on | |
| US8527762B2 (en) | Method for realizing an authentication center and an authentication system thereof | |
| CN112671720B (en) | Token construction method, device and equipment for cloud platform resource access control | |
| CN101651666A (en) | Method and device for identity authentication and single sign-on based on virtual private network | |
| CN107295011A (en) | The safety certifying method and device of webpage | |
| US20150149530A1 (en) | Redirecting Access Requests to an Authorized Server System for a Cloud Service | |
| CN108322416B (en) | Security authentication implementation method, device and system | |
| CN110430065B (en) | Application service calling method, device and system | |
| CN111062023B (en) | Method and device for realizing single sign-on of multi-application system | |
| CN103139200A (en) | Single sign-on method of web service | |
| CN106685973A (en) | Method and device for remembering log in information, log in control method and device | |
| US20170070486A1 (en) | Server public key pinning by url | |
| CN111818088A (en) | Authorization mode management method and device, computer equipment and readable storage medium | |
| CN102143131A (en) | User logout method and authentication server | |
| CN114157434A (en) | Login verification method and device, electronic equipment and storage medium | |
| CN116527341A (en) | Client-side calling rear-end interface authentication authorization security method | |
| CN113783867B (en) | Authentication request method and terminal | |
| CN112560003A (en) | User authority management method and device | |
| CN112600817A (en) | Signature authentication method during interface request of front-end application | |
| CN109495458A (en) | A kind of method, system and the associated component of data transmission | |
| Lee et al. | Secure and efficient protection for HTTP cookies with self‐verification |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| PB01 | Publication | ||
| PB01 | Publication | ||
| SE01 | Entry into force of request for substantive examination | ||
| SE01 | Entry into force of request for substantive examination |