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