Do I want Ueberauth, Guardian, or both?

Hey folks,

I’ve been out of Elixir for quite some time, but recently was green-lit to rewrite a project in Phoenix. I’m trying to start out with authentication, but am a bit confused about whether I need Ueberauth, Guardian or both.

For the moment we’re a pure web app with no API requirement, and given that we’re trying to massively reduce complexity, I don’t want to build an API or associated plumbing if I don’t have to. It seems like Ueberauth should be enough for us, but I also want a plug of some sort to block access to controllers that require authentication, and I’m not sure Ueberauth provides that.

Do I need Guardian for this? Or is Guardian only needed for API use cases? Looking at the README, it seems to perform redirects and such, but maybe those are more for SPAs working with tokens, and not for more traditional templates/views.

And yes, I’m aware I can probably put together a plug very simply, but authentication is one of those things I really would prefer to be robust and correct, even if I need another dependency where someone maintains that plug for me. I’m just not sure if Guardian is that dependency and, if so, how to make it play nicely with Ueberauth in Phoenix templates. Seems like there are plugs in Guardian to block access, but there’s also overlap with Ueberauth’s auth controller.

Thanks a bunch.

Check out Pow.

4 Likes

Hmm, I’m a little bit worried about that one because it seems to bake in
a bit more magic than I’d like. We’ve got a legacy database we’re trying
to work with, so something that wants to install its own
fields/migrations is probably going to present some challenges. I’ll
investigate it further, though.

You can easily bake your own session based auth also. The steps are described in at least a couple of books: Programming Phoenix and Phoenix in Action. However you would still need some kind of users table in your database.

1 Like

If you want a unified authentication layer between multiple things like supporting google and facebook, then use ueberauth, else just use something singular and specific for the service, or Pow if it is all built-in.

If you need to communicate to remote servers via JWT then Guardian can be useful. If you will only connect to the same server even on DB-less API style paths then use Phoenix.Token, not Guardian, as Phoenix.Token is significantly faster, smaller, and just as encrypted.

Ueberauth is useful for supporting pluggable auth providers, otherwise you don’t need it.

Guardian I’m almost certain you will absolutely not need.

8 Likes

GOt it, thanks. We definitely need social login, so I think I’ll just go
with Ueberauth. Also looks like all I need to do is check whether
current_user is in the session, provided I set it in my controller, so
a custom plug should be easier than I thought. We’re not using
passwords, and may want an API in the future, so I’m not sure I’m ready
to pull in something that implies or hinders either. Ueberauth and a
custom plug for auth checks seems sensible for now.

1 Like

Just to be clear, Pow is built to be really flexible, and will work with legacy databases. The migrations are only there if you start from scratch. Here’s an example on how migrating from Coherence is done: https://hexdocs.pm/pow/1.0.14/coherence_migration.html#content

But sounds like Ueberauth is what makes sense for you. Assent may be another option though it’s low level so you would have to manually set up routes and controller logic: https://github.com/pow-auth/assent

6 Likes

Hey @ndarilek thanks for posting this question. It was exactly the thinking I was going through because most of the content I found in the internet about adding authentication with ueberauth was also using guardian. Example: Authentication in Elixir Web Applications with Ueberauth and Guardian: Part 2

I found out later that in the endpoint.ex file, there are some @session_options there there were generated with my project. Sounds like the cookie is auto signed and verified. In addition to that, if I pass a encryption_salt, it encrypts the cookie as well.

So it sounds like it’s secure enough to just use the cookie in the session to authenticate and verify if the user is authenticated for more traditional template/view apps, which is also my case. Thank you