Add Authorization Code and Access Token docs for social login

[typerandom]

Add Authorization Code and Access Token docs for social login.

How to verify

1. Run $ npm run docs.
2. Open /docs/_build/html/social_login.html to view the new docs.

Discussion

• Part of the issue discussion was adding a note about using postmessage as the callback uri when authenticating using the Google provider. But I did not really understand that, and the Google docs about postmessage was very thin.
• I'm not happy about the placement of the new docs. The sections Logging in using an Authorization Code and Logging in using an Access Token are currently placed after the section Test it Out. This feels strange. Any suggestions on how to make it better?

Fixes #380

[coveralls]

Coverage remained the same at 69.759% when pulling 6c30c90 on add-social-login-access-token-auth-code-docs into 2ece900 on master.

[mdeggies]

Hey Robin! Took me awhile to test all this, but looks awesome. I added some comments about renaming the sections & beefing up the scope explanation :)

[mdeggies]

I think this needs a little more detail. It should link to the scopes that are available (https://developers.facebook.com/docs/facebook-login/permissions) and explain what adding extra scopes do. For ex, if I set the scope to "email,user_friends", how do I access this data? Same for the Google/LinkedIn sections

[mdeggies]

I would also add that the account is returned on 200 in all of these sections 👍

[mdeggies]

This looks good, but I see what you mean about the title & placement of the new section. I think this section and ‘Test it Out’ should be renamed. I would rename ‘Test it Out’ to something like Standard auth, or Default auth. This implies that the standard/easy way of doing things is to visit /login, click on the FB button, input credentials, etc. Then you can rename your section to something like Facebook SDK Auth, or Facebook Access Token Auth, since this section shows an alternative. Same with Google/LinkedIn sections

[mdeggies]

I really like your explanations at the beginning of the Google & LinkedIn sections. I would add that same explanation here if it applies. "Using the Access Token (implicit) workflow is preferable when you're logging in from a place where the storage can be trusted. E.g. from your back-end where only you have access to the Access Token."

[oshalygin]

Really good stuff, directly relates to what I'm currently trying to accomplish with Google. With that, the redirect URI is something I need to handle at the React level. I get the response back which includes the queryString params of state and code.

Is this something specific to the individual FE SDK and thus should be excluded from the docs since they're really meant for server side applications which are agnostic to the underlying SDK?

My redirect looks something like this(Note the http://localhost:8080/authorize/callback string is configurable at the GCP console, the rest is what you get back after you've authenticated with Google):

http://localhost:8080/authorize/callback?state=df81b8ae-a25b-781a-b45f-832&code=4/Jtq8_nbU6A2vvixT82Bsak73gCigvnebsE