Single Page Application session management

Question

I have a Single Page Application which is fully HTML+JS+CSS (using frameworks such as jQuery and AngularJS) and a server side API using ASP.NET WebApi.

The SPA is served in a server similar to a CDN and also packaged using Cordova for use in smartphones.

The server side API has a lot of methods which needs authorization and authentication, hence I have to login and pass an identifier from the client side so the server would know who I am.

The problems I am facing:

1. Once authenticated, where should I store the access token \ session ID?

   currently I have built my own authentication method (not OAuth) which returns a session ID, which the client puts in every subsequent HTTP calls in the Authorization header. However, when a user decides to refresh the page, the header is now gone. Solutions are to either save the session ID in a sessionStorage which might be insecure (OWASP doesn't recommend so, but perhaps X-Frame-Options = SAMEORIGIN would be suffice?) or use a HttpOnly cookie for the session management, which brings me to the next point:

2. If I am using Cookies it's understood that I need to check for CSRF, but if i'm not? is there any reason to add a CSRF? it's in the same scope for the session ID.

3. I have my own user system and group management which has a robust access checks. Is there any advantage for me to use OAuth and OpenID if I already have a working authorization filter which checks what I need, and isn't roles-string-based? (i.e. Roles="Administrators" etc., but fully CanChangeResource(x))

I have failed to find similar questions which may answer my problems and would appreciate an informative answer.

Answer 1

Looking at the two options you presented, sessionStorage or HttpOnly cookies, there is a trade-off. You are correct that if you use cookies, you need a CSRF token, and if you use sessionStorage and use that as the source for your header, you do not.

However, what OWASP is concerned about with sessionStorage, is that an XSS vulnerability allows an attack to extract authenticated sessions. With an HttpOnly cookie, it does not. Given the prevalence of XSS on the web today, this is a threat to consider seriously.

So, while sessionStorage would be the simpler option, and may well work with little modification to code you currently have in place, the HttpOnly cookie plus an anti-CSRF token would be the more secure approach. You have to decide if the extra effort is worth it to you, for your application.