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.

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: pow/lib/extensions at main · pow-auth/pow · GitHub

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

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

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.

Seconded! Was thinking the same thing.

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.

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.

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

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?

I didn’t write that clearly, but that’s fixed now: GitHub - pow-auth/pow: Robust, modular, and extendable user authentication system · GitHub

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.