search

pow-auth / pow

Robust, modular, and extendable user authentication system
https://powauth.com
MIT License
1.61k stars 160 forks source link

How will Pow adapt to the Auth initiative? #508

Open joepstender opened 4 years ago

joepstender commented 4 years ago

I'm gonna throw the bat into the henhouse here.

Pow was mentioned in the "upcoming authentication solution for Phoenix" article by José Valim 5 weeks ago. A lot of input has been given to it from the community since then.

Although Pow is a lot more mature at the moment, the Auth initiative surely can't be ignored. But what has been created in Pow shouldn't be either. Could the two merge somehow? Can they coexist?

I'm curious to hear your thoughts about the matter. It would be great if the forces could be combined somehow...

danschultzer commented 4 years ago

Yup, I have been thinking about this.

My current roadmap for Pow is this:

  1. Pow.Phoenix.Socket for easy socket and liveview integration
  2. telemetry with session lifecycles for audit, and you can track session stats in LiveDashboard
  3. Blog post about mix phx.gen.auth and Pow
  4. Now that mix phx.gen.auth paved the road for code injection, make a toolbox for generators to install Pow and configure it to any guide in just one step, replicating what's seen here: https://github.com/pow-auth/pow_demo (potentially installing Pow is also only one step with automatic code injection like mix phx.gen.auth)
  5. Make a migration mix task that helps migrating from mix phx.gen.auth to Pow and potentially from Pow to mix phx.gen.auth (no lock-in!)

I'm going through it in this order, working on the first three at the moment. I've gotten a full time position recently so I've a fraction of the time I used to have to deal with this, but I'm definitely trying to stay on top. Any help is of course very much welcomed.

I think Pow and mix phx.gen.auth solves two different problems. Jose is working from a consulting perspective where having all the pieces on the board makes most sense, whereas I'm working from a startup perspective with constraints that makes IdP a far more attractive option. I’ve tried to make Pow hit the sweet spot, while following Elixir/Phoenix conventions as close as possible. It should potentially work as both a scaffold with clear ownership, and framework with abstraction. You should be able to see and control all the moving parts, as well as hide them when necessary. I feel I’ve gotten most of the way there with Pow, though not all successful.

mix phx.gen.auth goes for full ownership right out of the door, making it a one step generator. I feel that many of the early Elixir developers have been burned one too many times with auth framework constraints (I sure have been burned plenty myself), so they would be very happy to just have a generator to kickstart things, and take full ownership. I fear that this approach is highly susceptible to insecure practices, especially for less experienced devs. I believe the better approach for the majority is to only expose what the developer is comfortable with taking ownership of, and deal with anything else as abstraction that you won’t have to think about.

IMO mix phx.gen.auth is likely to become the default auth option due to the involvement of the core Elixir/Phoenix team, but I do think there’s a place for both to co-exist. If developers can easily try out both they can decide what is appropriate for their project. I don't know if the forces can be combined, but if nothing else, I definitely would like to hear more of the cons of Pow vs mix phx.gen.auth so I can close the gap.

morgz commented 4 years ago

Thanks for the update @danschultzer - Really glad you see the two projects living side-by-side. Would it be possible to give a rough timeline attached to the roadmap?

In particular the LiveView integration. I see this as a big missing piece in both POW and the Auth initiative, now that LiveView is included in 1.5.

The issue thread for sockets is quite alive with suggestions, but I don't think any of them have solved it properly yet. Happy to help out where possible, I even found your description of what you think you'd need to do useful, to help guide some draft implementations. I think some guidance from you, could help us contribute back.

Congrats on your full time position, hopefully it's worthy of your talents!

danschultzer commented 4 years ago

@morgz thanks!

I agree, socket/liveview integration is high priority. I've a general idea of how session renewal should work, based on how LiveView deals with flash messages. I hope the Pow.Phoenix.Socket module that I'm working on will make LiveView integration much easier as well.

I will be very grateful for any help you can offer. Currently I'm knee-deep in work to reach a milestone for beginning next week. So let me get back to you when I've got a clearer head to outline my current idea for socket/liveview handling as well as roadmap/timeline. There's also a lot of pending PR's I would like to catch up on ASAP.

In the meanwhile I recommend looking up how others are dealing with sessions in WebSockets. I haven't found much information, and it doesn't seem there is any best practice for how sessions are dealt with in WebSockets. There's also some tricky things about how channels and LiveView are handled in Phoenix, e.g. no easy way to set plugs.

joepstender commented 4 years ago

Updated the issue title. I must say after having a quick try with phx.gen.auth I do appreciate the fact that all code it generates is right there within my project. What I want to do with it is up to me. As a learning dev that is a big advantage. If you look at the issues within the Pow project a lot of them are about how to implement app specific authentication requirements. Most of the times this means creating project specific views, controllers and templates.

Comparing: User Invitation seems to be the only extra feature Pow offers right now?

danschultzer commented 4 years ago

As a learning dev that is a big advantage.

Yup, I agree. It's the big advantage of phx.gen.auth, but it's a double edged sword as you also get all the downsides of having to maintain a secure implementation. I do think it would be good if it's possible to generate all business logic with Pow though, rather than having to follow the guides.

It was something I thought a lot about when I began working on Pow, but there was no code injection in any of the phoenix/ecto/elixir mix tasks, so I thought it would be bad practice to introduce that. However, with phx.gen.auth paving the road, there's nothing holding it back now. It would be amazing if you can set up Pow with everything in just one mix task 😄

If you look at the issues within the Pow project a lot of them are about how to implement app specific authentication requirements.

True. I think the mix tasks will be a great way to reduce this. Instead of having to manually set up everything, you can just run a mix task that does all the work for you.

User Invitation seems to be the only extra feature Pow offers right now?

There are a lot of subtle differences, but yeah, invitation and PowAssent are big ones.

When you dig more into it, you will also see that Pow keeps your implementation more secure as your implementation will depend on the dependency (so you can also receive security advisories) rather than just having a scaffold generated once and done.

Here's a few other things I noticed, going through the generator, that Pow does and phx.gen.auth doesn't handle for you:

phx.gen.auth covers a vast majority of use cases, and as long as you don't really need anything more, or need any complex setup, then I think it's a pretty good solution.

Pow on the other hand is built to follow all the OWASP and NIST guidelines. I do think it's a better approach for Pow to have the added friction that requires it to be a conscious effort breaking best practice.

BryanJBryce commented 4 years ago

@joepstender Auth doesn't address API tokens and won't in the future, it's not a goal of the generator.

jaimeiniesta commented 3 years ago

Has anyone worked on migrating from Pow to phx.gen.auth? I love Pow and it's still powering authentication in my apps, but I'm planning to move to phx.gen.auth to have less dependencies.

Does anyone know of a guide on how to do this migration?