JWT: how to handle GET requests when user opens a new tab?

Question

There is a lot of advantages when using JWT over Cookies on API-centric apps and I understand that you can store the token on sessionStorage when accessing the app via a browser. You can set an interceptor on your JS code to inject the JWT token on Authorization header for GET requests -- as long as these GET requests are being made from the same code that authenticated the user.

But what happens when the user is authenticated, then opens a new tab and tries to access a different restricted area (or even the same area) of the app/site? In this case, there is no interceptor to inject the token on the Authorization header on the new tab. I suppose the server will receive the GET request, look for a JWT token on the Authorization header and will not find it, rejecting the request.

When you are using Cookies, they are always sent by the browser natively and you don't have to worry about new tabs and authentication.

Is there a way to set up the Authorization header globally for the domain on the browser the moment the user authenticates in the first tab? What are the usual solutions for this matter, if any?

Answer 1

Upon accessing a protected URL without the right credentials (like a JWT) the browser would be redirected to a specific endpoint (e.g. on the Authorization Server) where it can get a new JWT.

This happens for example in the OpenID Connect Implicit flow: http://openid.net/specs/openid-connect-implicit-1_0.html

But it would also be possible to store the JWT in a cookie. That's just not a standardized way of presenting JWTs so it would be specific to your client/browser and the protected application.

Answer 2

I decided to add an update to this question due to new findings. I will not change the original answer.

First, according to my comments on the original answer:

I ended up using a cookie to hold the JWT, but it is set by the client using github.com/js-cookie/js-cookie after first authentication. My server code checks for the JWT in the request in this order: header, body, cookie. So any time the user opens a new tab, the local-set cookie is used. Other in-page requests inject the JWT in a header. This way, the operation is API-oriented, falling back to a cookie in last case.

However, I also had a concern about the security of a cookie generated on the browser. This is because, since it is generated by a client JavaScript, you cannot use HttpOnly, leaving it open for XSS.

Solution

Since I am using Sails, I just decided to create a cookie on the server with the JWT token, and send it with the response, which also contains the JWT token on an object on the body.

http://sailsjs.com/documentation/reference/response-res/res-cookie

res.cookie()

Sets a cookie with name (name) and value (value) to be sent along with the response.

      res.cookie('x-access-token', token, {
        expires: expire,
        httpOnly: true
      });
      return res.status(200).json({
        "x-access-token" : token
      });

This cookie doesn't require session enabled on the server, so it fulfills the "sessionless" advantage of using JWT.

If the client is a browser, it will store and reuse the token on subsequent requests, including on new tabs with help of the HttpOnly cookie.

If it is another type of client, it has the JWT token on the response body.