lud

Ash authentication on mobile

Hello,

I’m trying out the Ash framework for the first time. I am building an API for a mobile app and I want to implement user authentication.

We are in a first-party app and server configuration, so after reading this I’m wondering if the following could be enough:

An API endpoint accepting email/password and sending a token
An API endpoint using Ash Token features

It’s the first time I’m doing a mobile app so I am not sure. But to me it looks like I do not need to implement OAuth2 or OID Connect.

What do you think?

Thanks!

23 comments

/phoenix /ash #authentication

2 2854 23

2023-05-05 01:49:50 UTC

Marked As Solved

zachdaniel

Creator of Ash

Correct. You’d want to implement the password strategy. That strategy will add all the actions that you need to your resources. I don’t think that a JSON endpoint is created for you for signing in, but if not it is something you should be able to do with a phoenix controller.

use Phoenix.Controller

def sign_in(conn, %{"username" => username, "password" => password}) do
  YourUserResource
  |> Ash.Query.for_read(:sign_in_with_password, %{username: username, password: password})
  |> YourApi.read_one()
  |> case do
    {:ok, user} ->
      conn |> put_status(200) |> json(%{token: user.__metadata__.token})
   {:error, error} ->
     # handle errors. You should get back an `Ash.Error.Forbidden` 
     # error with a nested error you can use to provide an error message
  end
end

Post #7

Also Liked

D4no0

Usually if there is mobile involved, there is the google/ios authentication involved. They basically send you a JWT token instead of username/password that you can check for validity against their public certificates.

Post #1

zachdaniel

Creator of Ash

Got a couple things:

The set_actor plug puts the actor in an idiomatic place on the conn. But it doesn’t call Ash.set_actor/1, that is an “opt-in” tool for storing the actor in the process dictionary.

What I would generally suggest (and will be default in Ash 3.0) is to set this in your api:

authorization do
  authorize :by_default
end

Then authorization will always be running unless you explicitly pass authorize?: false. Not passing an actor is equivalent to actor: nil, but in the default setup, not passing an actor is equivalent to authorize?: false.

If there is a “current actor” then I’d set it as the actor. If its an authentication action, then you can do things like authorize_unless actor_present() to only allow calling it without an actor. You could also add forbid_if always() to make it so that it can only be called with authorize?: false. That is a good way to make something internal only (because api clients and things like that can’t pass authorize?: false.

Post #11

zachdaniel

Creator of Ash

Not that you need to, though. You can pretty easily create an endpoint that calls the sign_in_with_password action and extracts the token.

Post #3

Last Post!

lud

Ok so I got it working like you said by putting the logic in the “after”:

    read :by_id do
      argument(:id, :uuid, allow_nil?: false)
      get?(true)
      filter(expr(id == ^arg(:id)))

      prepare(fn query, %{actor: actor} ->
        Ash.Query.after_action(query, fn
          _, [] ->
            {:ok, []}

          _, [single] ->
            case single.owner_id == actor.id do
              true -> {:ok, [single]}
              false -> {:error, Ash.Error.Forbidden.exception([])}
            end
        end)
      end)
    end

Next step will be to look in the “allowances” table if there is a record for that inventory and that actor, to also allow