Sending cookies for stateless SPA authentication using JWT

Yep, makes sense.

Your idea of making distinction between original and refreshed tokens is interesting, thank you for sharing it!

Don’t hesitate to poke me as needed or to share any other idea.

Would be interesting to see what the optimal solution would look like If the client side is a pure JS application then it is possible to send back to the client application at authentication time (sign in) along with the cookie the value of token expiration (e.g. {"expires_at": unix_time}). A script running at fixed intervals on the client-side or on page navigation checks if there is say less than 24 hours to expiration. If so, a background call to the server is made which triggers the sever to issue a new cookie with new expiration time. Good to make distinction between original token and refreshed tokens since some actions may require providing username and password again.

Hi @acrolink

I was out for a couple of days, hence the delay, I’m sorry.

To be honest, I haven’t yet decided how the session expiration will work for my app. What I’d like is for the session to expire after a week of inactivity for the account. At least, that’s what I think my customers will find appropriate.

Many options seem possible. One would be to refresh the token and overwrite the cookie at each request, which shouldn’t be too much of a drag for the server as this process seems very light. Another option would be to be less aggressive about it and go for daily refreshes (first request of the day refreshes the token and cookie).

Another more lazy way would be to set the expiration 2 weeks after cookie/token creation and refresh them when there’s less than one week remaining. The only way this option would make sense to go for is to save server load, which I think is not really an issue, so I most likely won’t go for this one.

I’d be interested to know our thoughts on the subject!

Ah, and yes, I think the cookie and token should have the same expiration value as the behavior is pretty much the same should either of them expire before the other anyway (user needing to log back in).

Cheers!

@jstlroot, glad to hear it is working now. I have already implemented your ideas (in regard to secure cookie storage for the token) using Phauxth library. I want to ask: what max_age do you use for the token/cookie expiration (should it be same value)? and do you implement some refresh token mechanism server or client side (for soon to get expired tokens)? Thank you.

Oh my god I found it…

I knew it was gonna be stupid.

put_resp_cookie(conn, key, value, opts \\ [])

Options

• :domain - the domain the cookie applies to
• :max_age - the cookie max-age, in seconds. Providing a value for this option will set both the max-age and expires cookie attributes
• :path - the path the cookie applies to
• :http_only - when false, the cookie is accessible beyond http
• :secure - if the cookie must be sent only over https. Defaults to true when the connection is https
• :extra - string to append to cookie. Use this to take advantage of non-standard cookie attributes.

I had :secure forced to true but I’m not using HTTPS in my dev environment.

I hope this discussion will help others determine how they want to implement token authentification with Phoenix and Vue.js

Thank you all again for your time and support <3

Very very true. Plus if you encode, say, a JWT token into a web page (as is common with ‘any’ token for phoenix websockets sadly) then a page can quite literally just read another page and parse out information from it using your auth’d user (there are hazards they have to work around to do that, but there are still ways).

Yes.

  def sign_in(conn, %{"user" => user_params}) do
    case Accounts.token_sign_in(conn, user_params["username"], user_params["password"]) do
      {:ok, token, user} ->
        conn
        |> Plug.Conn.put_resp_cookie("token", token, http_only: false, secure: true, max_age: 604800)
        |> render("signed_in.json", user: user)
      _ ->
        {:error, :unauthorized}
    end
  end

The access_secure_data gives me exactly the same output:

%Plug.Conn{
  adapter: {Plug.Adapters.Cowboy.Conn, :...},
  assigns: %{},
  before_send: [#Function<1.92707701/1 in Plug.Logger.call/2>],
  body_params: %{"withCredentials" => true},
  cookies: %{},
  halted: false,
  host: "localhost",
  method: "POST",
  owner: #PID<0.799.0>,
  params: %{"withCredentials" => true},
  path_info: ["api", "access_secure_data"],
  path_params: %{},
  peer: {{127, 0, 0, 1}, 47456},
  port: 4000,
  private: %{
    MyAppWeb.Router => {[], %{}},
    :phoenix_action => :access_secure_data,
    :phoenix_controller => MyAppWeb.UserController,
    :phoenix_endpoint => MyAppWeb.Endpoint,
    :phoenix_format => "json",
    :phoenix_layout => {MyAppWeb.LayoutView, :app},
    :phoenix_pipelines => [:api],
    :phoenix_router => MyAppWeb.Router,
    :phoenix_view => MyAppWeb.UserView,
    :plug_session_fetch => #Function<1.45862765/1 in Plug.Session.fetch_session/1>
  },
  query_params: %{},
  query_string: "",
  remote_ip: {127, 0, 0, 1},
  req_cookies: %{},
  req_headers: [
    {"host", "localhost:4000"},
    {"connection", "keep-alive"},
    {"content-length", "24"},
    {"accept", "application/json, text/plain, */*"},
    {"origin", "http://localhost:8080"},
    {"user-agent",
     "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/66.0.3359.139 Safari/537.36"},
    {"content-type", "application/json;charset=UTF-8"},
    {"referer", "http://localhost:8080/"},
    {"accept-encoding", "gzip, deflate, br"},
    {"accept-language", "en-US,en;q=0.9,fr;q=0.8"}
  ],
  request_path: "/api/access_secure_data",
  resp_body: nil,
  resp_cookies: %{},
  resp_headers: [
    {"cache-control", "max-age=0, private, must-revalidate"},
    {"vary", "Origin"},
    {"access-control-allow-origin", "http://localhost:8080"},
    {"access-control-expose-headers", ""},
    {"access-control-allow-credentials", "true"}
  ],
  scheme: :http,
  script_name: [],
  secret_key_base: "wEwpD63zVGtA3/JTdl5QBH6aZwE3FLD2gkAQWn6XD4Tfgk4lYlsDOoZHAREvfjoX",
  state: :unset,
  status: nil
}

Maybe something to add to the discussion, using Postman never helps either. i.e. In this case, it sees my cookie being set as expected on the sign_in call but the access_secure_data call is not sending back my cookie to the server even though I can see it in Postman…

Have you tried turning off HttpOnly (in this case not setting it to true) when setting the cookie?

Of course! I’m no expert but what I learned from reading articles and blog posts for 3 days is that giving javascript access to an authentication token (jwt or phoenix) is never a good idea because of cross-site scripting attacks.

To quote this article: Randall Degges - Please Stop Using Local Storage

If an attacker can run JavaScript on your website, they can retrieve all the data you’ve stored in local storage and send it off to their own domain. This means anything sensitive you’ve got in local storage (like a user’s session data) can be compromised.

If an attacker can get a copy of your JWT, they can make requests to the website on your behalf and you will never know. Treat your JWTs like you would a credit card number or password: don’t ever store them in local storage.

It seems like using the request header body to send the token also gives javascript access to it. There might be a way to avoid this that I don’t know of? If so, it could be a solution.

HttpOnly cookies are isolated from javascript and cannot be read by it, making authentication token stealing XSS attacks more complex, if not impossible. Cookies are open to other types of attacks but this is mitigated by the use of HTTPS all over. At least that’s what I understood.

Maybe there are some things I don’t quite understand yet and if you feel like it’s the case, please point it out so I can avoid doing dangerous mistakes.

@jstlroot, would you mind explaining how does using a cookie provide better security than sending the JWT token in the request header body?