Hi @adw632

Thanks for the great feedback. I agree that AshAuthentication constrains folks in some unexpected ways. You’re right that it’s hard for a framework to get right - especially on the first try. Regardless, I’m going to try and address some of the feedback here.

insufficient escape hatches in handling of actions such as implementing password checks

Agreed. We do have this issue open to track changing/removing the password constraints, but if you have ideas for where you’d like to see other escape hatches I’d be keen to hear them.

No sign-in audit records or recording invalid signins, no account lock out after too many failed signins.

This is true, but I’m not 100% convinced that this should be AshAuthentication’s job as it would be fairly easy to implement. That could also be an argument for just doing it. I am definitely open to being convinced. Keen to hear more about what specifically you’d like to see.

Results in security flaws as users should not be able to brute force passwords or tokens unfettered.

Zach and I talked this over at length. There was some discussion of rate-limiting, denylisting, etc, but we couldn’t agree (he is for, I am against) building it into the library. Again this is something that would be fairly easy to implement, but maybe would be more useful as a separate extension?

Lack of control over controller flows, like confirmation and in your case redirects, it’s all concreted up and difficult to reason about.

I disagree on this point. I made the default auth controller/plug as flexible as possible to allow folks to implement the behaviour they want on top of it. As a general rule I didn’t want folks putting authentication in their app without understanding what it was doing, so I left the default behaviour as bare-bones as possible. Turns out I may have been wrong on that because the consistent feedback I’ve had is that people want it to do more for them by default.

Lack of customisation of the UI and view

It’s very customisable - but it turns out not in a very useful way. I expected folks to only use the default liveviews while bootstrapping and then move on to build their own afterwards maybe reusing some of our components. Turns out that’s not the case and they’re being pushed a lot further than I ever imagined. I’m keen to work on generators for these views and even for them to eventually to become the default behaviour.

Use of pow which does not yet officially support liveview sockets

We use assent (which is part of Pow) for our OAuth flows, but that’s it. No other part of Pow is used and OAuth cannot be performed within a liveview, so I’m not sure how this applies.

Inability to add TOTP

There is no inability to add it; just no one has done it yet. The ground work has been done and I can see it being relatively simple to add a new strategy/add-on to support it. See the custom strategy guide for a place to add it. PR’s definitely welcome.

Still requires a lot of touch points on the codebase to implement and what you’re left with is quite inflexible.

As above I don’t think the problem is that AshAuthentication is not flexible enough - it’s just not flexible in the right ways. I’m glad you found a solution that works for you and I’m sorry to read that I nearly scared you away from Ash entirely.

Over all I want to say thanks for the valuable feedback and that there are no sacred cows here. I want to encourage everyone to raise issues, open PR’s or otherwise engage with us to improve the state of the entire ecosystem.

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).

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