Where to store access and refresh tokens on ASP.NET client web app - calling a REST API

Question

I've made a Web API in ASP.NET that acts as the entry point into a SQL Server database for report data. This service has a "token" endpoint that authenticates a user via ASP Identity and return a 20-minute access and 2-week refresh token.

This API should only be accessible via our own apps and products. We'll be writing an Android app, iOS app, and ASP.NET web application that will authenticate with and get data from this Web API described above. I'll be responsible for the ASP.NET client web application and the API. We are building these apps all internally for our customers to login to and use. No 3rd parties outside of my company will be calling our API through any of their own apps.

For my client ASP.NET web app, I'm writing it in ASP.NET MVC and it doesn't really have a database as of now since it communicates with the API for everything.

I've started with this as a base, and it works...but now I need to convert this HTML file to an ASP.NET web app in MVC and figure out where and how to store the access token and refresh tokens. http://blog.rfaisal.com/2014/01/14/building-your-own-api-and-securing-it-with-oauth-2-0-in-asp-net-webapi-2/

My questions are:

1. I understand I'll need to pass the access token in subsequent calls to the API to do CRUD operations. Where should I make my web request to authenticate the user on the web app when logging in...from the C# code behind or JavaScript as in the tutorial referenced above? I ask because I realize that I'll need the access token in my JS Ajax calls, but I've heard that the refresh token needs to be more "secure" and calling from the server code might give me more secure options of doing so??

2. Where do I store the access token? In a cookie created in JavaScript or the server? In JavaScript local storage? In a session variable that I can pass to the JavaScript maybe?

3. Where do I store the refresh token? I'll need this for renewing the access token before it's about to expire. I've Googled this to death, but cannot find a good ASP.NET solution online that tells me where or how to store this from the perspective of my consuming web application. A cookie created from the server, saved in a SQL DB that the web app uses, in a session variable?

I'm in desperate need of help, and this is driving me insane and keeping me awake at night. Hope someone can provide a full, simple example and describe fully what I need to do.

Answer 1

1. Where to authenticate the user?

If it is a user who needs to authenticate, then you need something in your front-end. From your front-end, you can just do a POST to your back-end, with the user credentials. You verify the user credentials, and issue an accesstoken/refreshtoken pair in case the credentials are known. You will ALWAYS have to go via the back-end to authenticate a user. You mention that the tutorial does it in JS, but it does not. It POSTS to a login form. The POST is initiated in JS, but it goes to the back-end.

2. Where do I store the accesstoken?

The accesstoken can be stored the same way as normal authentication cookies are stored. You have various options (secure http-only cookie, localstorage, session storage, etc.). In the most simple scenario, you just store it in a cookie so that it is sent along with each request. However, for a mobile app, it is probably easier to store it in LocalStorage.

3. Where do I store the refreshtoken?

This highly depends on your application. I asked the same question a while ago, for mobile apps (be sure to read the comments as well). You should store the refreshtoken in a secure place. For the apps that you will develop, you can follow the suggestions from the answer I linked to, that is:

• Store the refreshtoken in LocalStorage
• Store the encrypted refreshtoken somewhere on the file system, using an API provided by Android/IOS. Store the encryption key in localstorage. (or the other way around).

For other kind of apps, other possibilities exist. Storing both the accesstoken and refreshtoken in LocalStorage might feel wrong from a security viewpoint, but an attacker will probably have more luck intercepting the token when it is in transit, than gaining access to the localstorage. Other, sometimes more exotic suggestions are given here (e.g. IOS secure storage).

Extra information

• I personally like this series of blogposts very much. Be aware, they might start to become a little bit outdated, but they contain a wealth of information regarding a REST-OWIN set-up.
• Please do not forget to implement all other security controls, which I have not mentioned as this would cloud the answer. HTTPS, http-only cookies, secure cookies, XSS preventions etc. should be implemented, or your token will be stolen much faster than the time you need to read this answer.