Reputation: 354
We have a MVC application, in which we are making web api calls from browser to get the data and display it in browser. Since our application is Claims aware, the client need to pass AccessToken in order to access the web api. Since the browser is not a trusted client (server does not have much control over browser), is it advisable for clients (browser) to store AccessToken? are there any better design patterns here without compromising security?
Upvotes: 2
Views: 1818
Reputation: 57718
You'll have to trust the browser to some degree, otherwise your web application won't be of much use. Before tokens and API's, traditional server-side applications trusted that session identifiers could be stored by the browsers in cookies.
With tokens, the principle is the same, but the devil is on the details. First of all, assume HTTPS needs to be used, otherwise you might as well give up. Having HTTPS in-place, you can assume to some extent that sending the access token and/or cookies to the browser is secure.
After that, you need to worry about the characteristics of the storage the browser will use. For that I would recommend to read the Where to Store Tokens? section of the Cookies vs Tokens: The Definitive Guide article.
The real problem is that there are a sufficient number of other small details that is almost impossible to provide a definitive list and even though they are small details they can have very big impact on the overall security of the system. The only honest recommendation is that if you want to roll your own authentication system you need to be prepared so spend significant time and resources learning all these details.
Upvotes: 3