Pow: Robust, modular, extendable user authentication and management system

Your Libraries & OS Mentoring Libraries
, , , ,
1

None of the current solutions worked well for me, so I went ahead and built a user management system from scratch.

This project took far longer than I initially thought, and I would love to get some help to iron out everything. So please try it out and let me know what you think!

https://github.com/danschultzer/pow
https://hexdocs.pm/pow/

The latest release is a pre release version, but it is running in a production environment (we went away from a Coherence setup).

So what does Pow do (differently)?

Functional configuration

A huge issue with most libraries is the dependency on a global environment configuration. It becomes especially messy when dealing with umbrella apps. Pow handles configuration by passing it as an argument to all method calls (and with plug it’s passed in a private key). There’s also fallback to app-specific environment configuration by using :otp_app like Ecto/Phoenix.

Plug n’ play

Pow exposes only necessary files. It means that even views and templates for Phoenix aren’t generated unless required for customization.

Modular

Pow has been build with clear separation between Ecto, Plug, and Phoenix modules, so if/when deep customization is necessary, you can pull out any part and work with it.

Extendable

Out of the box, Pow does basic user and session management. But Pow has been made to be easy to extend. A reset password, email confirmation and remember me extension ships with it! Extensions are built as a separate system to keep the core of Pow lean and easy to understand.

Security

When working with user authentication, there can be many pitfalls. That’s why your user authentication library should do as much of the work as possible, so you don’t have to think about it. Pow is built with care for recommended best practice, and detailed in the readme.

Transparent

Pow attempts to give the developer full control and understanding of the API for Pow. For example, when you install pow, you’ll have to enable extension support yourself, so you understand the working parts. This it to remove as much “magic” as possible.

And a whole lot more

  • Mnesia cache for distributed systems (and in general for production run)
  • Near zero dependencies (:ecto, :phoenix and :phoenix_html are currently required to compile, but I plan to make them optional)
  • Simple migration from Coherence
  • Multi provider support with https://github.com/danschultzer/pow_assent
  • Alright! Go read the documentation already: https://hexdocs.pm/pow/
66 Likes
2

This looks very very promising.

How does it compare with Established Auth-Servers like KeyCloak or identity-server ?

We are also looking to create an Auth app but couldn’t find anything that can provide OAuth, JWT, QR-Code, Magic Login etc. KeyCloak is not the ultimate solution but it’s good. It would be great if we can have something like that in Elixir-Land. And by far this project along with your phoenix_oauth2_provider seems the closet to it.

1 Like
3

That’s great! I’ve never used KeyCloak or identity-server so I can’t say how Pow compares with them.

However, Pow is built to be very flexible upon the basic user authentication and session handling setup it provides. PowAssent gives multi-provider support (OAuth, et al). You can use Guardian with Pow for JWT. Magic/QR code login could be easily supported with an extension. My philosophy with Pow is to provide a solid and flexible foundation that you could build your app upon, and when needed, you can extract and modify any parts of Pow and add in whatever you need (e.g. maybe you only want to have magic login for your app, or you would like to add two factor authentication).

I got three extensions built into Pow that shows how Pow can be modified: https://github.com/danschultzer/pow/tree/master/lib/extensions

If you got any ideas or suggestions for how Pow can improved, please let me know!

5 Likes
4

Thanks a lot for amazing work @danschultzer.
It would be really sweet to see an app/tutorial with ex_oauth2_provider + pow + pow_assent.

3 Likes
5

Given the volume of provider options with Ueberauth, how difficult would it be to utilize the existing options with Pow Assent?

I like what I see and I’m going to test out Pow, but in my opinion where Coherence and Ueberauth both suffer is the lack of combining the two. If Pow can be made to work with the Ueberauth strategies then I think there is a strong chance for it to become “the” main auth library for Elixir/Phoenix.

4 Likes
6

Seconded! Was thinking the same thing.

1 Like
7

That would be really cool, and after some brief testing, it’s definitely doable to use ueberauth strategies with PowAssent. However I think you will be much better off just using PowAssent strategies exclusively.

Ueberauth would break separation of app configuration built into Pow. Also, PowAssent takes a different approach than Ueberauth, and pushes for removing as much logic as possible from the individual strategies themselves.

The vast majority of strategies in Ueberauth are using the OAuth 1.0 or 2.0 protocol, and it would be much easier (and less code) to build the strategy module than integrating them.

4 Likes
8

Just took the basic setup from the Readme for a test drive and it worked like a charm.

When I got to the extension portion of the setup it gets easy to get sidetracked configuring Swoosh (swoosh, phoenix_swoosh, gen_smtp…the assorted configuration, etc). Personally, I would suggest moving that to a wiki page and simplify the mailer example in the README to the function call printing to the log.

From there, users who are getting setup will be able to see that the extensions work and how they work while knowing that they can plug the parts into any email system they want. Along those lines, it would be beneficial to demonstrate accessing the data parts like the confirmation url or reset link.

If you’re using an external transactional email system where the templates themselves live with the providers (like SendWithUs or systems that exist with the providers themselves or just sending the parts to a queue) that example would be beneficial.

So short version: Don’t tie the onboarding experience of Pow to Swoosh.

3 Likes
9

Thanks, I’ve just updated the docs with a simple mailer that only outputs the mail, and it’s much better!

6 Likes
10

Great!

Stepping through it from there, if I follow this part of the docs now it doesn’t actually generate the files.

Now generate the view and template files:

mix pow.extension.phoenix.mailer.gen.templates

This will generate view files in WEB_PATH/views/mailer/ , and html and text templates in WEB_PATH/templates/mailer directory.

It’s also not really clear where this belongs:

Add web_mailer_module: MyAppWeb to the configuration, and you’re set!

It works fine without those though. Leftover documentation?

11

I didn’t write that clearly, but that’s fixed now: https://github.com/danschultzer/pow#modify-mailer-templates

TLDR: The configuration is the config :my_app, :pow environment, and you need to add the extensions as arguments to generate email templates in the mix task.

I’ll see if it make sense to rework the mix tasks so it can just pick up the extensions configuration variable instead of you having to explicitly state what extensions you want to generate views/templates for.

3 Likes
12

Sounds good. Happy to test it out for you because I really like what I see.

1 Like
13

I tested some basic usages everything works very well. Well designed nice project for elixir community

5 Likes
14

I’ll try it out as well. Since I’m a complete n00b, I’m not sure if I’ll be able to make it work (due to lack of knowledge), but I’ll give it a go and report back on my fumble and stumble :smile:

2 Likes
15

Thanks, that’s an excellent use case, and I would love to hear how easy or difficult it was for you! While there’s a lot of configuration options, Pow (almost) works out of the box, so you aren’t required to do more than just the first section of the readme to have it working. It’s definitely one of my goals that you can get Pow running in no time with minimal experience required.

1 Like
16

Very cool—Thanks for putting so much work into the library and documentation.

I’m building an app as an Elixir demo/proof-of-concept at work, where we use Azure AD/Single Sign-On. I must be able to prove that it’s “easy” to integrate with existing infrastructure. Just started trying to make it work with Ueberauth, but stumbled upon some issues. I’ll try Pow instead :slight_smile:

2 Likes
17

So I picked some of the more popular Ueberauth strategies, and implemented them in PowAssent to see how easy it would be. It took half an hour to add in Discord, Slack and Instagram support, so this is definitely the way to go :slight_smile:

7 Likes
18

Oooo, and that is an immediate attention grab. ^.^

5 Likes
19

This seems to me like one of the more needed an useful libraries out there and I’m thankful that you’re putting time into it, @danschultzer. After getting more familiar with Elixir and Phoenix and some more hands-on practice, I would like to contribute to your library. I saw that you also implemented support for Azure and added a comment to my GitHub issue—thank you for that as well! :purple_heart:

2 Likes
20

Playing around with Pow and Google OAuth now. Been meaning to put together a prototype internal site for a while. Everything has been easy to setup and get working so far!

4 Likes