Ash Authentication Phoenix: displaying authentication error

Thankyou @danschultzer for taking to time to chime in with your careful and considered explanation on Pow Assent vs Pow.

I agree with your position and taking a conservative approach with these things before we can have confidence all the edge cases have been worked through.

Thanks.

I agree that pow assent is not involved as a plug, and it is therfore agnostic to routes, controllers or liveviews.

Unlike the (unrelated) pow which is a plug based solution and does have outstanding issues, and which I thought you were saying my claim was incorrect, but actually what you were saying is that my claim that Ash used pow was incorrect and I fully agree that I was 100% wrong on this point.

The plug/router/liveview integration that AshAuthentication provides is similar to what phx.gen.auth does, where Ash uses the (confusingly) named pow assent for authentication strategies.

Yeah, to iterate what has already been said, Assent is not Pow. It does have the same maintainer (me) and was grouped with Pow as it first was part of CoherenceAssent and later part of PowAssent.

Assent is a multi-provider framework that abstracts away OAuth/OIDC integration, and normalizes the user format. It is up to you how you want to implement that into your app. Assent doesn’t have any notion of controllers, sessions, plug, or phoenix. Assent’s only concern is communicating with the provider, being RFC compliant, and returning necessary data so you can redirect the end-user with the right params with whatever request handler you have implemented in your app (e.g. phoenix).

I feel confident that Assent can be used in any circumstances with no issues. AshAuthentication using that won’t become an issue down the road. And even if for some reason Assent becomes an issue it should be pretty straight-forward to replace it with another provider library.

Now, Pow is a full feature auth library for Phoenix that deals with session management and everything else, completely taking over the request handling. It is fair to be cautious with the lack of LiveView support. I will eventually resolve that, but for different reasons it is not trivial (which you can read more on in the issues). I’m also the lone maintainer of Pow, which is another reason to be cautious.

Everyone should definitely consider that, and evaluate whether Pow, AshAuthentication, another auth library, or code gen with phx.gen.auth is the best choice for their project. Pow is still maintained, and I would say well suited for REST applications. LiveView auth support with Pow can be implemented in many ways depending on what your requirements are.

Also I think it did take a bit, but authorization and session handling in Phoenix WebSocket seems mostly settled in LiveView now. I’m implementing Pow with LiveView currently in a larger financial platform with strict security requirements. This is my ideal use case for Pow, and I plan to implement support upstream once I have enough confidence in the setup (and time!).

I could write a lot more on auth, Pow, code gen, my current work, etc, but I think this is more than enough off-topic discussion. I do hope this shed some light

Pow != assent. Those issues have no bearing on AshAuthentication. AshAuthentication uses assent, for which there is no web socket related issues (because there is no web socket related functionality).

You’ve linked pow and pow_assent several times and those libraries are not used by Ash.

Those aren’t assent issues. Assent works just fine and there’s nothing in it that requires work arounds.

Edit: never mind I got confused about your reply. Thought your new links were still related.

My reason for this conclusion is the open issues on how to best support liveview are still not resolved.

I am not saying it cannot be made to work with sufficient consideration of all the edge cases (many of which are captured in those issues), but there is no canonical or official documented approach that succinctly describes what is required to support liveview.

My point is, if was so easy and everyone is confident all the edge case are resolved then why is it not simply documented instead of sitting open and still unresolved?

The following issues were raised in April 2019, and Sep 2022 with still no settled position.

https://github.com/pow-auth/pow/issues/271

https://github.com/pow-auth/pow/issues/663

To reiterate: using Assent has nothing to do with Pow (its maintained by the same team, but its a very specific subset of the functionality) , and bears no relationship to whether or not Pow supports liveview. So Pow or Pow Assent don’t have any bearing on AshAuthentication and

• Use of pow which does not yet officially support liveview sockets

is not correct.

That may be the case and I don’t really care how pow is carved up, official liveview support is a current gap.

Until liveview is supported officially it is a risk using the Pow or Pow Assent ecosystem within a liveview app.

Assent, Pow and Pow Assent are different projects.

Pow is the full blown authentication library.

Assent only handles SSO/OAuth request/callback phases and has no dependency on Pow.

Pow Assent glues everything together.

Assent has nothing to do with LiveViews or Controllers etc. Pow’s not full integration with LiveView has no effect on one’s ability to securely use Assent.

Thanks @jimsynz for considering the feedback.

I think part of the experience of using Ash Authentication is that it is often one of the first things we need to think about when building out an app so we come into Ash not knowing it in detail and it’s not obvious how we would change or customise the Authentication view or the controller or replace with our own without digging into the internals of Ash itself. I did see the class overrides for the Ash view but I didn’t see how I could change the layout, order of elements in the view, even add additional elements (like TOTP) along with the password strategy.

I’m glad to hear that a generator approach for liveviews is being considered.

With Pow/Assent I refer to the issue not officially supporting liveview yet, which IMO is not ideal given liveview has been around for some time, it begs the question of that projects ongoing relevance to modern Phoenix apps.

This may sound harsh but having a dependency that is unable to keep up the Phoenix releases is something we have to be very wary about, it’s one of the biggest risks we face that a library is no longer maintained. I’m not saying in this case that Pow Assent isn’t maintained but clearly it’s fallen behind and no-one should indulge a security component that does not officially support liveview if you’re building a liveview app as there can be many edge case that need to be considered.

Happy to provide further advice in respect of handling failed auth attempts, account lock out and recovery and fail2ban type of behaviour for IPs that are attempting brute forcing on auth endpoints be they tokens or passwords.