Authenticating Json Web Token and Redirect After Login

Question

I recently read Cookies vs Tokens for Angularjs and implemented the sign in and authentication piece to allow users to sign in from a sign in page. The app is setup to have the account module (responsible for sign in's, account registration, profile, etc) as a separate page which will redirect to the SPA for the main application.

After successful sign on the token is sent back to the sign in page client as a JWT and the sessionStorage / localStorage values are set via js. Finally the user is redirected (also via js) to the main application. The issue is since I am redirecting via js the header can not be set, which obviously fails the auth in the main app when loading the page (Since my auth middleware is higher than both static and auth api requests). If I attempt to redirect from the server after a form post rather than returning the token via JSON on success, the sessionStorage will not be set via js as described in the blog post.

I've come to a couple of ideas and wanted to get input on which if either is good for best practice.

1. From the server set a response authenication cookie 'http only' (all our browser requirements allow this) cookie which is read on the next request to the main application. The cookie would then be read by the server and allow the secured static assets to be served. My initial thought was setting a cookie defeats the purpose of using a Authorization header on every request since there is a time the cookie could then be read even if it's removed on the first api request.

2. Allow the previously mentioned static assets to load without authentication (html, css, application js) and on the first internal API request (which in the application is required almost immediately on load) which will then have access through Angular's $http interceptors to set the request Authorization header. The same interceptor can then redirect to the sign in page if a 401 is sent back.

I thought the second would be a simpler approach due to only needing to move the auth middleware under the static file middleware and then updating the http interceptor in Angular, but thought it might be bad practice to have static files be able to load and then redirect after the fact. Any input is appreciated.

Answer 1

In response to your point 1

... My initial thought was setting a cookie defeats the purpose of using a Authorization header on every request since there is a time the cookie could then be read even if it's removed on the first api request.

The use of the authorization header is not mearnt to be mutually exclusive to the use of cookies. The idea is to use it when it best suits the problem like in single page applications and native mobile applications. However since it does depend on some kind of client storage, preferably sessionStorage, it is recommended to even sometimes use cookies for the purpose of storing the token if there are issues with the usage of sessionStorage like in old browsers. Hence as long as you use the cookie for storing the token but NOT for authentication, you have not defeated the purpose. Refer to point 1 in the follow up article https://auth0.com/blog/2014/01/27/ten-things-you-should-know-about-tokens-and-cookies/

If you are wondering "but if I store the token in the cookie I'm back to square one". Not really, in this case you are using cookies as a storage mechanism, not as an authentication mechanism (i.e. the cookie won't be used by the web framework to authenticate a user, hence no XSRF attack)