- [Instructor] Social login is a form of single sign-on
using existing information from a social networking service
to log into another service
without providing username and password for it.
I'm sure you've already used your Google, Twitter,
Facebook, or LinkedIn account to sign in
to some other application
and also hi that behind the scenes,
you were using OAuth 2.0 for this.
Technically, this means you were giving the app
you were using access to the API
of the service on your behalf.
As I said, actually OAuth 2.0
does not support authentication,
yet for social sign on, it is used regardless.
After this video, you will understand how this is done.
We will use GitHub to implement social sign on.
It is an OAuth provider as well.
OAuth 2.0 flows are always rather similar
but they have their specifics.
Let's look at how this works with GitHub.
First, you have to register your site
as an OAuth app in GitHub.
We will do this in the next video together
but the process contains some key information you will need
to understand the authentication flow.
When you set up the app,
you provide, along with some other information,
a callback URL and as you see here,
this is relative to the client.
This means that we can use the respective URL
on localhost here as this is where the browser
will be redirected too.
After registering the application,
you end up on the screen that provides you with a client ID,
as well as with the button
to generate the client secret.
After this step, you have a registered app,
client ID and the client secret.
Now let's look at the authorization and authentication flow
and brace yourself
because now you will learn
what UML sequence diagrams were made for.
All right, we have the browser,
we have the playground app and we have GitHub.
In the browser, you click now
on this sign up with GitHub button.
This now leads you to auth/github,
so that's a GET request against the playground app
and there we have the passport.authenticate middleware
and it uses the GitHub strategy.
This strategy will now redirect the browser
to github.com/login/oauth/authorize
and it will send along the client_id,
this is what we acquired before,
the redirect_uri, this is something we configure
with the strategy in passport
and it has to match the callback URL
that we defined before when setting up the app.
It also contains the scope
and the scope defines to which data we want
to have access to.
And it also contains an argument state
and state is a random string
that is just used for security reasons.
So now the browser redirects to GitHub
and sends along the arguments from before.
Now, in GitHub, you get the authorization screen.
So this is the screen where you're asked
if you really want to grant authorization
to this given app.
And if you grant authorization,
your browser is again redirected.
Now it's redirected to auth/github/callback on localhost.
This is the callback URL you defined before.
And GitHub also sends along its GET argument a code.
This is just a very short code
that will expire after a few minutes.
So now the browser follows this redirect
and heads to auth/github/callback.
And there again,
we have the passport.authenticate middleware
and the middleware will now do a POST request
to login/oauth/access_token
on GitHub and send along the client_id,
now also the client_secret,
the code it got before,
the redirect_uri and also the state argument,
which is still a random string.
When everything goes well,
GitHub will now reply with the so-called access_token.
This is the token that allows us now
to communicate with the GitHub API
on behalf of the user.
And now authorization is basically done
because now we have authorized our app against GitHub
and now the authentication of our user starts
because what we are now doing is we send a request
to api.github.com/user
and send the access_token with it.
And with this access-Token,
we are now allowed to fetch the user information
and get back the user profile.
And with that, we have now,
though OAuth does not provide authentication directly,
identified the user.
As you can see, this is rather complex
but luckily the GitHub passport strategy does most
of the work for us.
Now before we implement this,
there is one more thing.
Ideally, you should have two GitHub accounts.
Account one would be your regular GitHub account
and you would use it to register the OAuth application.
So this is the app owner.
And then we would ideally need a second account,
which would be just a temporary test account.
You can create it with a separate email address
and this would be then the user we use for login.
This is basically just to emphasize
that the user of the OAuth app is registered to
is technically unrelated to the user
who uses the OAuth app then to authenticate.
If you don't want to create an additional account,
you can use your regular GitHub account
to own the OAuth app, as well as to log in.
Just keep in mind again
that the user you register the app to
does not need to be the same user who logs in then.