An upcoming authentication solution for Phoenix

I am uncertain how I feel about generators-to-roll-your-own being the “blessed” (mix phx.gen.auth) authentication solution for Phoenix.

As José covers, a library/framework solution for authentication that meets all needs is really hard to get right (and he would know far better than I), but the trade-off of not being able to easily update what was generated if there are vulnerabilities or improvements seems pretty huge.

I don’t have any better solution, and this looks like a perfectly reasonable approach to a tough problem, but I’m a little uncomfortable if the standard solution for the community becomes roll-your-own.

Interesting! Looking forward to see this in action.

Auth is so implementation specific that a scaffold makes sense, but I agree with @bennelsonweiss that rolling your own is risky if you are new to auth and security.

Even after years of dealing with this I still introduce vulnerabilities and miss things

Whoo hoo this is great!

An authentication system like this could be awesome for Phoenix, in fact it has been at the very top of my Phoenix wishlist for some time now!

My proposed solution is to provide generators to inject all relevant authentication code into your application.

I want to add a small remark on the “easily”. Updating on the library approach is not necessarily easy because the library may have moved to a new major version, it may have fixed bugs you were relying on, or it now depends on a dependency you are not ready to update yet.

When we did security releases with Devise, we had to provide patches/diffs for many versions back, because people were stuck on previous versions for many reasons. I would say applying a patch/diff is most likely the simplest way to fix a security issue, because you want to do the minimal change ASAP, and updating the package may bring unrelated changes unless you are running on the latest version and you just need to bump the patch release.

So from this particular perspective, I actually don’t worry about the generator approach. Especially because I expect the generators to be less prone to bugs due to the much smaller surface area.

My main concern with the generator approach is developers modifying the generated code in unsafe ways, which would be harder to do if the code is in a lib.

That’s very true, and good insight into the problems a library like Devise would have.

When I said “not being able to easily update what was generated” I intended to suggest you would be able to “update” what was generated but that it’ll have to be a more complicated process of communicating where a problem is and how to fix it rather than being able to actually fix the problem yourself.

However it being a complicated process is always true to some extent because even if you can fix the library/framework you need to communicate the need to upgrade to your users, and they need to actually upgrade (which as you point out can itself be complicated).

I didn’t mean to imply that library/framework upgrades- particularly around critical functionality like authentication- are ever easy.

I actually didn’t highlight that issue because any solution with hooks or other mechanisms of extensibility also seem to me like they would probably provide ample places for people to introduce vulnerabilities.

Do you think it would be a lot more of an issue with generators than in something like Devise?

Will this authentication work out-of-the-box with LiveView and Phoenix Channels or do we need to handle that ourselves?

You will have to do it yourselves. I am actually working on a LV app and the only view I felt necessary porting to LiveView was the setting pages. There isn’t much LV can do for things like login page.

Fantastic!
That’s greatly appreciated. My question was based on some discussions I saw ongoing reading existing authentication frameworks and LiveView and the need to adjust and make it work with LiveView. I must confess I still didn’t dig into this topic but I guess this is something worth to explain in documentation in a way that even a not experienced developer would understand clearly for some standard scenarios.
In fact, simplicity, or better, making things obvious, is one of the greatest advantages of the Elixir Ecosystem!
PS: I code as a hobby and Elixir ecosystem is being one of my best partners during this Corona virus times staying at home. Kudos for that!

Hello all
I don’t really know where to post this.
Some redirections of mix phx.gen.auth are done via |> redirect(to: "/")

In these functions:

MyApp.UserResetPasswordController.create/2
MyApp.UserResetPasswordController.get_user_by_reset_password_token/2
MyApp.UserAuth.log_in_user/3
MyApp.UserAuth.log_out_user/1

As I built a new Elixir app from scratch, my home page is located at Routes.page_path(conn, :index), which is not always “/”, as I configured my Endpoint with a subpath (using :static_url) to be behind a reverse proxy.

So I had to change in all mentioned functions
|> redirect(to: "/")
by
|> redirect(to: Routes.page_path(conn, :index))

I don’t know if makes sense to scaffold with Routes.page_path(conn, :index) from the beginning.

Awesome work besides that. As the rest of Elixir of course