support other oauth providers

[cdepillabout]

It would be nice to support other OAuth providers. I'm not sure if we want to do this for the MVP, but eventually we should add it.

Currently we support logging-in via Twitter, but here are a few services that seem to be popular as well:

• Google
• Github

There is also a separate issue for supporting Facebook oauth login at #20. Supporting Facebook OAuth is higher priority than the services above.

[arowM]

It would be better to handle supporting Facebook as an independent issue.
Our next product uses Facebook OAuth, so only supporting Facebook is "MVP" and other providers could be "after MVP".

[cdepillabout]

You're right, I added a new issue #20 about adding Facebook OAuth. I will change the milestone of this to "after MVP".

[alexanderkjeldaas]

It would be great to handle non-social providers such as auth0 and firebase.

[arowM]

Thank you, @alexanderkjeldaas. I've never heard of auth0. It is interesting!
It seems that auth0 is a sort of competitor of Goat Guardian, so I wonder developers should use auth0 directly rather than Goat Guardian support it.

Do you have any concrete use cases that indicate why Goat Guardian should support it instead of just using auth0 directly?
I also not familiar with firebase, so could you tell me docs about authentication flow using firebase?

[alexanderkjeldaas]

I don't think there's much competition actually. I've used both, but I'd prefer something like Goat Guardian.

auth0 has the lock library, but I don't think they have something like this. What I think they do have is, if you're missing the auth header, you can redirect through their site and back, but that's ugly and changes the URL to some auth0 url.

Both firebase and auth0 can do email registration, so in that sense they have similar behavior. Still, I've been looking for something like Goat Guardian as I think it's a clean separation of concerns, and it doesn't redirect away from the site.

What's good about firebase and auth0 is that there is a web-based UI where you can manage your users, enable/disable users etc. This is a very convenient way to make services stateless - the user database is handled by someone else.

For firebase at least, there is a small JSON data structure that can be fetched with some account information. That could store the subscription level for example. Having access to that as a header would be great.

I think the social login in auth0 and firebase mostly work if you re-use their login screen or their SDK, but then there's no separation of concerns like with this proxy and Haskell support is non-existent.

[alexanderkjeldaas]

https://firebase.google.com/docs/reference/rest/auth/

https://auth0.com/docs/api/authentication#introduction

[arowM]

Thanks for explanation, but what I actually want to know in this time is not whether auth0/firebase can be an alternative to Goat Guardian.
(Of course, the comparison itself is so helpful ;) )

The core question I want to ask is
"Is there any reason Goat Guardian should support auth0/firebase in addition to social providers instead of directly supporting all providers that auth0/firebase support?"

[alexanderkjeldaas]

@arowM sorry for the late answer!

The answer is NO. But auth0/firebase should be supported because of all the non social use-cases. It's when I want to make my own site with my own user management without running a database. That's when I want firebase for example.

[arowM]

What do you mean by "non-social use-cases"?
I don't know what your goal is and how you want to achieve it with Goat Guardian...

[alexanderkjeldaas]

With non-social use-cases I mean login that does not use a social network. If you login but you don't use your social network account.

My goal is to be able to manage accounts for my product without using any social network login method. Also my goal is to not manage any local database.

[arowM]

Thanks!

With non-social use-cases I mean login that does not use a social network. If you login but you don't use your social network account.

It's too abstract to understand what you mean, but if believing the definition and your goal, why not using email authentication flow of Goat Guardian and using firebase in upstream server?

It's strange to require Goat Guardian to support firebase/auth0 as a login method as you say.

[alexanderkjeldaas]

It's too abstract to understand what you mean, but if believing the definition and your goal, why not using email authentication flow of Goat Guardian and using firebase in upstream server?

This means I need to keep state

Also my goal is to not manage any local database.

[arowM]

I do not think so.
Anyway, it's not the case Goat Guardian should resolve.