How to hide or protect token when switching from javascript to web api 2

I am using javascript (angularjs) on a site / project UI and web API 2 and another site / project

User Interface Project: localhost / 12345
Web API: localhost / 98777

The UI project calls the Web API (C #) project, passing the token from the user interface to WebAPI for CRUD requests.

I created a token in the ServerSide project - WEB API2 (localhost / 98777), 1- username / password 2- then url localhost: / 98777 / Token , passing username + password + token

wit This way, it returns the token if you call it in the violin: with the content type: application / x-www-form-urlencoded. Like this token is generated and written to localDB, later this generated token can be used in your UI application to call using javascript (ajax / angular) passed to the WebAPI project.

I have implemented a carrier token that calls the GET / POST / PUT methods on my client site.

localhost/12345 defined in Client site to get employee records via token: ---------------------------------------------- method: 'GET' contenttype: 'application/json, charset=utf-8', authorization: "Bearer 040jdU6ry....." url: localhost/98777/api/employees/ 

it returns me the data of all employees ... it works.

 localhost/98777 defined in server site web.config: --------------------------------- <httpProtocol> <customHEaders> <remove name="Access-Control-Allow-Origin" /> <add name="Access-Control-Alllow-Origin" value ="*"/> <customHeaders> </httpProtocol> 

PROBLEM? The problem is that people can do and open developer tools in IE / Chrome / FF and view javascript sources and look at the token. and then execute the code in Fiddler / composer and add the entries: (.

so why do i need a token ????

Can someone advise which part I am missing? Is it normal that people can see the token?

This application will be used on the intranet and used by developers, so I need to provide maximum protection ...

+6
source share
2 answers

Is it normal that people can see the token?

Yes, it is normal. As far as I know, the token simply contains identification information, as well as some claims that the client cannot change. This is the only thing you can trust in him: Identity.

On the server side, you should check (roles / rights / business rules) that the user corresponding to the token ID has the right to perform the requested action.

Never rely on following the business rules of your client interface. Always check the server side and you will be safe.

+4
source

You may think about the next steps,

  • Use public key
  • Encrypt the key using a timestamp
  • Send an encrypted key with a timestamp in the header
  • Encrypt key in API with same timestamp
  • Compare both keys.
  • Check the timestamp with the system time.
0
source

Source: https://habr.com/ru/post/984047/


All Articles