Using Pow for simple API authentication?

Phoenix Forum Questions / Help
, , ,
1

I’m creating a Phoenix API backend that will be used with a Vue frontend app. I have experience building a traditional server-rendered app that uses Pow for authentication, but have never built a SPA before.

I’ve gone through https://hexdocs.pm/pow/api.html, which makes me question if Pow is the right choice for my case. Our app is an internal management system used by at most a dozen users, so stateless token authentication shouldn’t be a requirement (i.e. we can afford to check the DB on every request), and introducing the refresh token & access token distinction seems to introduce a lot of unnecessary complexity.

Would it be reasonable in my case to hand-roll something like this?

  • Authenticate against a users table
  • Store sever-side sessions in a sessions table in say Postgres, with roughly the following schema: id, user_id, inserted_at, updated_at. The updated_at column can be used to implement a TTL, say 2 weeks, and can be updated every time an authenticated user sends a request.
  • The token sent to the frontend app is simply a signed session ID.
  • (I’m not sure what to do if I want to access additional information, say user permissions, in the frontend app though. In a server-rendered Pow app, I would just consult a permissions field on the current_user assign set by Pow. Any suggestion is appreciated!)
1 Like
2

You don’t have to do that at all if the only consumer for your API is the Vue app ; you can just use the default authentication mechanism from Pow. All you have to do is to ensure that the credentials (i.e. cookies) are enabled in Vue resource (if you use this library).

To access informations such as permissions I would simply add an API route to fetch the info.

2 Likes
3

You do not need Pow for that. I would just use Plug.Session with proper Plug.Session.Store.

4

Is there anything wrong if I do what @lud suggested and just use the normal session-based approach with Pow?

5

You do not need Pow in that case. Plug.Session is built in feature into plug, so you have that already.

6

I’m not sure I follow. That’s just the session part though, I’ll still need to actually do the authentication somehow, either with Pow or hand-roll my own solution.

7

Create your custom store (untested, written from memory):

defmodule Plug.Session.PostgreSQL do
  @behaviour Plug.Session.Store

  @impl true
  def init(opts), do: opts

  @impl true
  def get(conn, cookie, %{repo: repo, table: table, salt: salt}) do
    with {:ok, sid} <- Phoenix.Token.verify(conn, salt, cookie),
         session when not is_nil(session) <- repo.get(table, sid)
    do
      {sid, session.data}
    else
      _ -> {nil, %{}}
    end
  end

  @impl true
  def put(conn, sid, data, %{repo: repo, table: table, salt: salt}) do
    session = %{id: sid, data: data}

    with {1, [session]} <- repo.insert_all(table, [session], on_conflict: {:replace, [:data]}, returning: true) do
      Phoenix.Token.sign(conn, salt, session.id)
    else
      _ -> ""
    end
  end

  @impl true
  def delete(_conn, sid, %{repo: repo, table: table}) do
    repo.delete_all(from(s in table, where: s.id == ^sid))
    :ok
  end
end

And then in your controller:

  • Create session: put_session(conn, :user_id, uid)
  • Get session: get_session(conn, :user_id)
  • Destroy session: delete_session(conn, :user_id)
8

If Pow id used for registration, password recovery and all other features, there is no need to implement your own session solution.

1 Like
9

If - this is important part, if it is not used, then you can implement most of it’s features quite quickly without all that fuss.

1 Like
10

Yeah, @lud’s recommendation is the best approach. You won’t have to do any additional work and you’ll have session renewal out of the box.

The API guide, though being a simple generic way of setting up API auth, is more useful for mobile apps, and third party integration.

2 Likes