humanitiesplusdesign / data-pen

Personal modeling application for Linked Data.
http://hdlab.stanford.edu/fibra
26 stars 0 forks source link

What social login providers should we support? #146

Open esjewett opened 7 years ago

esjewett commented 7 years ago

Currently we support Github. Other possibilities:

Keep in mind that each one is going to require implementation effort, so we should keep it to the minimum we can live with.

jiemakel commented 7 years ago

Found another one: https://github.com/sahat/satellizer . Here, we'd get all of: Google, Facebook, LinkedIn, Twitter, Instagram, GitHub, Bitbucket, Yahoo, Twitch, Microsoft (Windows Live) in a package.

esjewett commented 7 years ago

I think that only handles the first part of the flow. Exchanging the temporary code for the access token seems to be expected to happen server-side. But still may be useful to use to implement using this library to avoid maintaining custom stuff. I'll look into it further. Thanks!

jiemakel commented 7 years ago

Hmm, you're right. So this does need a bit more thinking through. Though, I think the angularjs-social-login is fully client side, so that would give use Google, Facebook and LinkedIn. satellizer itself also seems to support the implicit grant flow, which is aimed at client side login, but there's scant documentation on that. I also found oauth-ng which seems to be a generic implicit flow authenticator. (Although the implicit flow is apparently deprecated, and nowadays also client side apps should use the auth flow, just omitting the client secret)

Finally, there's also OpenID Connect, which is supported by e.g. Google and Yahoo and has a Facebook bridge. Didn't find any killer Angular library for that one though. There is this for Angular2 and this seems to be an example of OAuth2/OIDC for Angular1.

esjewett commented 7 years ago

Yeah, there are a bunch of options. 5 years ago I was an OAuth nerd, but have thankfully left that well behind. This is bringing back bad memories :-) I think the auth flow without client secret works for a bunch of platforms but unfortunately not Github as they don't have CORS enabled on their access-token endpoint, so I have to use a relay running on a Heroku dyno, at least temporarily :-( But I actually think Satellizer will be really helpful in handling the initial part of the authorization flow generically and then we can handle each service in whatever way is necessary as far as exchanging the code for an access token - for services that support more modern client-side auth flows than Github, that part is very simple, as demonstrated by the angularjs-social-login library.

For now, I think I'm just going to leave it as is until we determine what login providers we actually need to support. If Github is enough, then that works already, though I need to fix up the UI a little. If we need more, then will switch over to Satellizer, likely.

esjewett commented 7 years ago

For now we'll stick with Github. Longer term we need to add more providers and possibly include institutional providers. Probably will require a server-side component.

jiemakel commented 7 years ago

I suggest we also add Google and Facebook right away if they come relatively easily, as not all of our test users probably have GitHub accounts (that is, if, as now, we require a login to even dabble with the app)

cncoleman commented 7 years ago

Facebook is evil. How about Google and Twitter? We already talked about OpenID, right? It's complicated?

jiemakel commented 7 years ago

Just Google then for a start?

esjewett commented 7 years ago

I think OpenID use is pretty rare now. I haven't see an opportunity to use mine for a long time, though I think Google uses it behind the scenes. Login with Twitter/Google should be doable.

Google will be quite easy and doesn't require a server-side component that I see: https://developers.google.com/identity/sign-in/web/sign-in

Twitter is more of a pain and will require a server-side component like Github because their access_token endpoint doesn't support CORS: https://dev.twitter.com/web/sign-in/implementing

Still thinking it may make the most sense to integrate Satellizer and use that for the initial redirect flow. But we just need to prioritize when we do this based on how important it is.

esjewett commented 7 years ago

Oh, Facebook is as easy as Google, and Zuckerberg seems to be seeing the light a little bit, so who knows: https://developers.facebook.com/docs/facebook-login/web

Might make sense to do a quick survey in the Slack and direct people to it via email. Asking what IDs they have and what are preferred.

jiemakel commented 7 years ago

I'm also already using a cors proxy on ldf.fi to access the Getty endpoint, if that would help. On the other hand, the easiest approach for now would be to just disable the need for being authenticated until we actually use it for anything.

esjewett commented 7 years ago

Yes, true. The reason I enabled it was because I wanted to get it tested and didn't want to handle the logged out case in the header bar unnecessarily. But happy to just disable the automatic login and add a "Login" link in the header bar when not logged in.