Main differences between Pow and the upcoming Phoenix Auth?

dimitarvp

As has been announced relatively soon (start of April) Phoenix is going to get its own built-in authentication solution, injected in the project through generators.

I’ve used Pow twice and liked it.

Can somebody give me a breakdown on what are the main pros and cons of the upcoming Phoenix auth compared to Pow?

15 comments

/phoenix #authentication #pow

10 5615 15

2020-05-25 16:10:39 UTC

Most Liked

Show Best Posts
Show All (oldest first)
Show All (newest first)

tme_317

There is some discussion about this here: How will Pow adapt to the Auth initiative? · Issue #508 · pow-auth/pow · GitHub

Post #1

dimitarvp

Actually extremely helpful discussion there.

I think I’d go with Pow in this case. Even though mix phx.gen.auth seems like it’s giving you a full control, currently it’t not clear how security practice upgrades (and bugfixes, and new features) would even make their way into that once-and-done generated code that now lives directly inside the sources of your project. @josevalim, or anybody else working on it, do you have a plan for that?

So I definitely agree with @danschultzer more at the moment. We should however closely monitor how does the officially-blessed auth library fares with time.

Post #2

DiodonHystrix

Doesn’t seem like a big deal to update a few lines of code in your own repo after changes are introduced into phx.gen.auth.

Actually, a lot of companies build their own auth, because libs are bloated and it’s much easier to tailor your own code to your own, sometimes very complex, needs.

From my point of view mix.gen.auth gives you a minimum that suits a lot of simple apps. You can even check hex.pm auth, which is very similar to the one generated by mix phx.gen.auth.

Libraries like Pow (or devise) have that disadvantage that they have to cover most of the cases, which is pretty much impossible, right? Thus, when you hit a roadblock, you have to fork or create a feature request. At that point you start to regret using a lib for auth, because you could do it by yourself the way you need it with much less code to play with.

Obviously it depends on what you build, but in 98% cases Pow or Phx Auth are most likely both valid choices and the only difference is tinkering with options vs writing code.

Post #3

Last Post!

thojanssens1

If we mention once the hobbyist, then the junior programmer, then the company in full agile mode with strict deadlines, … there will always be some argument.
The tool is optional. Developers can evaluate the trade-offs according to the environment they work in, the type of programmers they have, the time/money they can invest, their skills,…; trade-offs are obvious, the generated code becomes application code and should then preferably be understood; if one can’t afford it – don’t generate the code.

A reverse-engineering tool for detecting flaws from the once generated code? Nope. Will not happen. As you can change the generated completely to your needs.

Most generated code is trivial MVC stuff. I don’t need to understand how argon2 and :crypto work. That indeed, I leave to security experts. The generated code does not perform low-level security-related operations.

Reasons are too obvious to mention why Jose went for this approach. A developer can evaluate the trade-offs; you consider you prefer to delegate that code to a library, that’s also a choice.
For many (and I believe most), that will be a better trade-off than a lib that affects every layer.

I’m going in circles, so I’m off and leave place for other participants