Add oauth2 social login option

[marcosfede]

I love that you included JWT for authentication, but I think that it will be very instructive to also add the option to log in using common oAuth2 providers, like github or facebook. This is a common issue we have when developing a fullstack app, and some examples of this would be greatly appreciated.

[EricSimons]

Excellent suggestion — we originally kicked the idea around of having oAuth as part of the core spec but decided against it to try and cut scope creep. oAuth implementations can vary between providers, frameworks, etc so broad support across all stacks would likely have been sufficiently difficult to create & maintain.

That said, I think a good solution to this might be encouraging folks to fork the existing repo's and add on additional functionality (in this case oAuth, but #26 would also benefit from something like this). We can still list them in the main readme, but they could (& should) be maintained as separate repos (unless we end up changing the core spec to include oAuth, image uploading, etc).

Would love to hear thoughts on this!

[deksden]

My 50 cents: social login is very common task for real life apps. Login with facebook, google, instagram at least.

Specs for my social apps are:

• signup with social network (after login with oAuth provider - create local profile for new user with specifiying additional detail like email or login into existing account if this token already attachet to any existing profile)
• login with social network
• link new social network to existing logged-in user
• (?) user profile merging if signed up via different oAuth providers (common problem for user when first time they signup with google, and next time - with facebook).

upd: related tasks:

• forget / reset password & email notifications,
• captcha on signup form

[Cameron-C-Chapman]

@EricSimons I'm guessing this isn't something we want to support in the core spec per the discussion in issue #90?

[deksden]

@Cameron-C-Chapman : imho, nope. Social login is complicated separate feature set.

One more idea: we can extend API spec via versioning, and add some "addons" to spec, like, social logins.

So, backend implementing this "addon" can use /v1-social/api" endpoint, not plain "/api". Next version of core spec can be "/v2/api". Maybe we can think on semver for spec.

[EricSimons]

@Cameron-C-Chapman yeah, social login would def fall into the "extra credit" category

@deksden I like the idea of potentially extending the spec via semver in the future 👍 probably will be a while before we create additional specs, but if/when we do, that seems like a great solution!

[sandeesh]

@EricSimons i think we need to finalise the the v1 of the spec and tag it before we even think about extending it. This will help prevent a lot of confusion and mess with all the other developers given the number of codebase we have growing.