mauric
Absinthe authentication with JWT tokens
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!
Marked As Solved
amcvitty
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.
Also Liked
autodidaddict
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.
autodidaddict
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.
autodidaddict
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.
Popular in Questions
Other popular topics
Categories:
Sub Categories:
Forums
Popular Tags
- #ecto
- #liveview
- #troubleshooting
- #learning-elixir
- #deployment
- #library
- #erlang
- #testing
- #genserver
- #mix
- #absinthe
- #remote-other
- #otp
- #plug
- #how-to-question
- #macros
- #postgres
- #channels
- #elixirconf
- #exunit
- #discussion
- #code-sync
- #javascript
- #podcasts
- #onsite
- #dialyzer
- #docker
- #authentication
- #umbrella
- #full-time-contract
- #podcasts-by-brainlid
- #ecto-query
- #elixir-ls
- #phoenix_html
- #iex
- #blog-post
- #graphql
- #genstage
- #ai
- #websockets
- #supervisor
- #advent-of-code
- #elixirconf-us
- #distillery
- #processes
- #forms
- #api
- #metaprogramming
- #security
- #performance








