JWT Auth using cookies

[Simon Gemmell]

Hiya, 

I am just looking into swapping over to use the vertx JWT auth module from my own copy of yoke middleware. Some "best practice" articles (e.g. here) indicate that for webapps the best place to put a JWT authorisation token is in a Secure; HttpOnly cookie and let the client side send it over with every request. Is there a way to make the vertx JWT auth check in cookies rather than the Authorization header?  

// now for any request to protected resources you should pass this string in the HTTP header Authorization as: // Authorization: Bearer <token>

I realise I can put in some middleware that takes the cookie and puts it in the Authorization header, but thought perhaps it would make vertx JWT auth a more useful module if it handles this scenario.

~Simon

[Paulo Lopes]

No the JWT handler only reads from the header.

If you store the token in a cookie you need to know that it can probably be read by all javascript from your domain, so if you have something like a SaaS app your tenants can probably read each other cookies...

I would recommend not to store it at all :) just get one using HTTPS a keep it in the client memory until the browser tab is closed.

You can however add a handler right before the auth handler that copies the cookie value to the header multimap and make it work as you like...

[Simon Gemmell]

Correct me if wrong, but from the article:

Cookies, when used with the HttpOnly cookie flag, are not accessible through JavaScript, and are immune to XSS. You can also set the Secure cookie flag to guarantee the cookie is only sent over HTTPS. 

I believe so long as you don't set a expiry it'll also be deleted when the tab is deleted. The article prefers Cookies over HTML5 storage (and I guess by extension local memory of the JS) primarily because you can't get to cookies (with the HttpOnly flag) via javascript...

[Paulo Lopes]

Hi Simon,

I've read the article and I cannot agree 100% with it because say that you want to have a micro service architecture where 1 component does all the security (issues tokens) and other component does some action if the token has been granted some authority.

Now in a microservice architecture it is all about decoupling, so if you have say:

* https://api.server.com/token  to issue tokens
* https://app.server.com/perform-action to do some action

As you can see this will not work with cookies you run into the Cross Domain / CORS issues

Now say that you have lots of static content so you will add a CDN

* https://app.mycdn-privder.com

Again the same issue the CDN will not be able to validate because of CORS

Now keeping the assumption that you have this distributed app relying on cookies then you need to do CSRF protection for your APIs since anyone could inject a iframe to hijack your cookie.

And finally if you are using frameworks such as angular you can enable an existing app to support JWT like this:

myApp.factory('authInterceptor', function ($rootScope, $q, $window) {
  return {
    request: function (config) {
      config.headers = config.headers || {};
      if ($window.sessionStorage.token) {
        config.headers.Authorization = 'Bearer ' + $window.sessionStorage.token;
      }
      return config;
    },
    response: function (response) {
      if (response.status === 401) {
        // handle the case where the user is not authenticated
      }
      return response || $q.when(response);
    }
  };
});

myApp.config(function ($httpProvider) {
  $httpProvider.interceptors.push('authInterceptor');
});

So as you can see because i used the sessionStore, only the current tab can access that memory value and once the tab is closed the token is gone from memory (and it should have never been written to disk) so you can be safe that no code either from other tabs or external to the browser has access to the token.


Now if you have just a single app that you can use cookies if you like.

[Simon Gemmell]

Hiya Paulo,

Thank you for taking the time to put all that in writing, it's very insightful. For the moment our app is just a single app but that is likely to change in the near future, so I have taken all you have said onboard. Hopefully others will also find it useful too. 

Thanks

Simon