Main differences between Pow and the upcoming Phoenix Auth?

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

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.

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.

José with his unique perspective (after having worked on Devise for years) has a great and detailed explanation of the tradeoffs of mix phx.gen.auth compared to other solutions like Pow on this blog post: An upcoming authentication solution for Phoenix - Dashbit Blog

I think integrating changes made to the phx.gen.auth generators would be similar to how you can integrate boilerplate changes in Phoenix generators like when upgrading from 1.4 to 1.5.. creating a same named project with the new generators then using a merge tool. Not as easy as bumping a dep but not too bad and with different tradeoffs.

I feel this grossly exaggerates the willingness of your average programmer to do that. I do that, you do that, but most people I ever worked with won’t even guess that they should be doing it. Sad but true, at least in my bubble (which has been negative for most of my career, I admit).

Absolutely, this is true. It’s just that any smaller business or a hobbyist initiative would like to go for the lowest maintenance solution while still having access to the latest security best practices. Having the auth code injected inside your app definitely makes this harder.

Disagreed here. It’s unbelievably easy to make a very rookie security mistake when rolling auth by yourself. I don’t trust myself doing it, at all. Plus Pow has showed that it’s easy to customise its parts, should the need arise. Its customisations are opt-in which has the slight disadvantage of believing that magic drives your auth but I think it’s worth it.

I imagine the same but I’ve known many people who can’t be trusted with a delicate operation like that. (Not to sound too negative, I also met fantastic individuals like in my last job)

I believe it’s high-time for our community to invent tools that not only can generate (and thus inject) code but also reverse-engineer it, analyse it, “recognise” it, a la Java bytecode instrumentation, maybe.

We should have a tool that says “you have phx.gen.auth in your project with 10 lines of code in it customised and different than the current latest version”.

We should have a tool that says “your Phoenix project’s ModelCase lacks Ecto imports” (soft-linting?).

I might try and start working on something like this in the future after things in my life calm down a bit (and after I close a few important open-source efforts).

But does Pow give you really more security though, and at what cost.

I’d like to remind that the generation tool relies on secured libraries/components that are independently updated. The hashing (argon2, pbkdf2, bcrypt, :crypto, …), Phoenix Token/Plug Session, …

I haven’t use Pow, but browsing through the docs, if you need the functionalities that the generation tool provides, you need to add pow-specific code in many layers of your application, and often through code injection.

Why? Because this auth code is not only about authenticating a user against an email and password, or verifying a token for email confirmation. It’s far more than that: actually most of the code is about providing form validation (changesets), controllers receiving auth-related requests, routes … it manages the flow of the request from the template or a link in an email, to routes, controllers, context, shema/changesets and the DB. And most code is actually not security-related. And comes with many possible customizations.
Just the amount of code injection (use) to make pow achieve what the generation tool provides shows that.

Say we don’t trust our junior developers too much, what will prevent the developer to remove some pow changeset in the code? It’s not that if you’re using pow your code can never be compromised.

Maybe it’s interesting to evaluate precisely where things might mess up before arriving to the conclusion that generating that code in the codebase is not worth the risks – concretely which risks? For almost every generated context function, you have to provide a user, and in every query generated, we link the query with that user; as long as you provide the right user, I don’t see right now how one can mess it up.

The generation tool also allows the developers to know exactly how the authentication system works. I would prefer to work with developers that know what they’re doing instead of developers that use such a black-box, but only because this black-box is spread throughout all the layers of your application.

Browsing pow’s documentation, I don’t understand how to revoke a particular session in a running system. For example, the code generated by the tool stores a token for every session in the database. I can delete such a token to revoke one specific session; and I clearly see in which table/field as I have total control; how do I do that with pow? (maybe I missed something, but it’s to express my last point; not only the flow of the requests is highly custom, but even the authentication mechanism itself can come in many different shapes).

For me it’s mix phx.gen.auth all the way.

Btw sorry if I sound harsh; while I believe changesets/context/controller/template/route/… all of this should be generated instead of injected with use and all possible configs, I would still use a library that manages the cookies, provide different plugs to extract a token from a header/cookie, plugs for Absinthe, etc. there’s a lot of stuff (more specialized) one can build around the generated code. I’d also rather see more tutorials to educate devs, helping understanding and customizing the auth code, rather than relying on tools that inject code in an obscure way, in every layer.

PS: sorry if there are mistakes; again, I didn’t use Pow, I only judge to what I read quite quickly through the docs, and understand why jose took the other approach of generating code. I personally use the generation tool for my project as it makes more sense to me and just seems the most logical way, as to my understanding expressed above.

I actually agree with this. I like all my code to be visible – obviously not the dependency libraries but everything else should be visible, inspectable, and changeable.

But we have to take trade-offs into account. We don’t have good tools that recognise the previously generated code and are able to upgrade it when a bugfix is issued upstream. Maintainability is a huge boon of the more invisible code.

We should be able to do something with time about this. Stuff like module / function attributes shoud allow us to instrument the project’s bytecode – or, even better, just have something that parses the source code to AST and manipulate that (and then put it back in the source).

Until we have a much better tooling for manipulating generated code after the fact, then “invisible” code hiding in the library code is still the lesser evil.

My two cents: I think it’s a very reasonable choice to have auth as part of the framework but as a generator that creates code in your application.

I worked with few kinds of auth and I can tell that unless the app is really simple, it’s always complex, so it’s about having this complexity as part of your app or as some kind of super extendable “one size fits all” solution inside of the framework. The problem with latter is that sooner or later you will have to go in and extend it and then you will have to deal with all the complexity anyway and since it’s a more general / abstract solution, there will be more complexity to deal with then if you have one specific to your app.

The way generators work would be the same as the code we have when we generate CRUD things, simplest most basic scenario that you can build upon according to your logic.

I’d argue it will be easier, not harder in the long run. If we want to make life easier for users with very standard solutions then we are better off with some ready made CMS for making standard websites, but it’s not what Phoenix is supposed to solve.

That is correct for low level things, nobody should invent their own logic of hashing or storing passwords and such, but as for higher level abstractions - it’s different. Trying to create an abstract enough solution so that it covers every use case will probably fail in that people will abuse it. Letting every app do what it wants but giving it a good starting point is the way to go in my opinion.

In the end it’s about the kind of users that you wish to serve, I’d argue that Phoenix’ user base will appreciate the generators way.

Well the point is that you change the generated code as much as you want, to your needs. After you generated the code, it’s now your application code.

If you do need a tool to somehow keep track of that code that you are likely to change, then the generation tool is just not a good fit for you, to my opinion.

But yes, if there is a security hole found, how am I now warned? Well, it will never happen:-D because this code has been tested thoroughly, and reviewed by expert programmers.
And it is also your responsibility to thoroughly understand the code, as it’s part of your application and not a third-party code.

Then I want to add something: say that someone introduces a bug in the generation tool, how fast will that be noticed?
Compare that to a bug in the library you are using, how fast will anyone notice? Pow for example relies on how many active developers with a thorough understanding of its code?

I’d bet that a bug introduced in the generation tool will be detected much faster, as 1. it will be integrated into Phoenix which has a lot of contributors and top developers are working on it and 2. every developer using the tool will forcibly have to study the code.

I agree that you won’t be able to update your code automatically, but you will hopefully be notified very fast for any bug VS a bug that might go unnoticed for a very, very long time, but with automatic code update.