Absinthe authentication with JWT tokens

Questions / Help
, ,
1

Hello you all!

I’m developing an app with Phoenix + Absinthe with React on the front-end. I’m using Guardian to generate the JWT token and with the login mutation I return the token to the front, then I save the token into a cookie. Using Apollo, I include that token into the header and on the server I wrote a Context to check the value and authenticate the user.

I want to improve this solution in terms of where to store the token or even use another solution.

The solution is to store the token on a httpOnly cookie set up by the server ? How to do that ?

Thanks!

2

The following may not be applicable because I don’t know all the context for your use case… but one thing that’s worth remembering about signed JWTs is that they are self-validating. If you trust the signer of the token, then you can trust the token. This means that your Absinthe API doesn’t need to generate tokens at all (or keep them in sessions). It can simply accept a bearer token in the Authorization header of all requests and then you crack that open when you build your context and add a user, scopes, etc.

This is essentially what I’m doing for my project. I don’t know if there are hidden dangers here, but I like this because it means that the front end can generate and sign tokens at will and the back-end can validate those tokens, and nobody needs a session anywhere.

1 Like
3

httpOnly cookies cannot be accessed from Javascript, therefore you React app will not be able to use them.

I never coded in React, but if possible store the token returned from the backend in the some React internal state.

4

I work in API security and never heard this assertions that JWT tokens are self-validating. Do you mind to elaborate more on this?

5

If you sign a JWT with a private key, and include the corresponding public key inside the JWT in the iss field, then you know that the JWT was signed by whoever claims to have signed it (assuming you’re validating the signature). You can essentially use the issuer field like an API key - if you trust the issuer (e.g. your web UI) then you can simply accept the contents at face value and assume that the user (sub) in the JWT is correct. You can use aud to validate that the token is going to a specific URL and you can use the expiration field to make time-limited bearer tokens, etc.

This is why I said I don’t know if what I’m suggesting is appropriate for your use case - some scenarios don’t allow for this kind of security pattern.

1 Like
6

httpOnly cookies cannot be accessed from javascript, therefore you React app will not be able to use them

You can configure Apollo to include HttpOnly cookies when making HTTP requests. Where the option is passed to the browser API the cookies don’t need read by Javascript.

8

Now I know waht you are talking about :slight_smile: This is called signing the JWT with the RS256 asymmetric signing algorithm.

Are you saying that the JWT token will be signed with a private key stored in the browser and then the backend will validate it by using it’s public key? Or do you mean by Web UI the backend responsible to deliver it to the browser?

9

The JWT is signed at the web backend and stored in the client side (Usually as a cookie) as an opaque data. It is also tamper proof.
Two different server-side applications can share the same key to form a trusted domain, so one application can trust the JWT from another application. With Guardian it is the sharing of the Guardian key.

10

Sorry, auth tokens are generated on the front end? How does that work?

11

I was (perhaps incorrectly so) assuming that there were two Phoenix apps - a “front-end/UI” app and the Absinthe app, which is the GraphQL API. The flow I imagined was something like:

Phoenix/LiveView -> OAuth redir -> Phoenix/LiveView -> JWT -> Absinthe

This is obviously not a one-size-fits-all scenario and probably has more steps in it than most people need. But the general idea was that the UI web app would sign JWTs with its key which could then be verified by the Absinthe app via bearer token auth.

12

Thanks for the the explanation, and I already understood this flow, but by the way it was phrased I was left with the impression that would be the web app on the browser signing them.

13

The problem for me to understand you is that you use UI web app and I immediately assume something running in the browser, but I understand that you want to mean the web app backend and if so, then using the approach you suggest is possible, but calling them self-validating JWTs is a bit misleading in my opinion.

14

You’re quite right. Calling them self validating without providing the context of using ed25519 keys to sign the tokens didn’t give enough context. My apologies.

1 Like
15

I don’t know if you actually got a good answer here. Our setup is very similar React → Absinthe/Phoenix.

We set an httpOnly cookie like this and as someone else noted, it gets sent with the HTTP requests.

router.ex

  scope "/api/graphql" do
    pipe_through [
      :graphql,
      :api_version,
      :api_auth,
      :set_sentry_context,
      :inject_graphql_context
    ]

    forward(
      "/",
      Absinthe.Plug,
      schema: OurAppWeb.Graphql.Schema,
      analyze_complexity: true,
      max_complexity: 1000,
      pipeline: {OurAppWeb.Grapqhl.Schema.Pipeline, :pipeline},
      before_send: {OurAppWeb.Authentication.AbsintheCookieResponse, :absinthe_before_send}
    )
  end

absinthe_cookie_response.ex

defmodule OurAppWeb.Authentication.AbsintheCookieResponse do
  # Used by router like https://hexdocs.pm/absinthe_plug/Absinthe.Plug.html#module-before-send
  def absinthe_before_send(conn, %Absinthe.Blueprint{} = blueprint) do
    if Map.has_key?(blueprint.execution.context, :access_token) do
      access_token = blueprint.execution.context.access_token

      Plug.Conn.put_resp_cookie(
        conn,
        # This name matches what is expected by Guardian.Plug.VerifyCookie
        "guardian_default_token",
        access_token || "",
        # Setting expires in the past is the official way to delete a cookie
        # https://stackoverflow.com/a/53573622
        max_age: if(access_token, do: 25 * 365 * 24 * 60 * 60, else: -100_000),
        http_only: true,
        secure: Application.get_env(:our_app, :cookie_secure)
      )
    else
      conn
    end
  end

  def absinthe_before_send(conn, _) do
    conn
  end
end

in schema somewhere:

  object :user_mutations do
    field :login_with_password, type: :login_with_password_payload do
      arg :input, non_null(:login_with_password_input)

      resolve &UserResolver.login_with_password/2

      # Put the user and token in the context 
      middleware fn res, _ ->
        with %{value: %{user: user, token: token}} <- res do
          next_context =
            res.context
            |> Map.put(:current_user, user)
            |> Map.put(:access_token, token)

          %{res | context: next_context}
        end
      end
    end

We have a different token for websockets for subscriptions, which gets created by a simple graphql HTTP call, then passed on the websocket creation.

5 Likes