- [Instructor] In this chapter,
I'm going to show you how to log in users
using single sign on without any need
to provide credentials to our app.
Single sign on is actually a pretty complex topic.
And this is why this video gives you a short preview.
Please note that each of the technologies
I will be mentioning would deserve a course of its own.
I just focus on what you need to know
to satisfy the common use case of logging in users
using an account at this third-party.
First, let's introduce two basic terms
that we haven't covered in detail yet.
It's authentication and authorization.
While they sound similar,
they described two related, but different things.
First, authentication ensures the identity of a user.
When we logged into the application before,
we authenticated the user using a username and a password.
Authorization on the other hand ensures that the user
can only access resources they are allowed to.
We did use authorization implicitly before
when we made sure that the user is authorized
to modify or delete the to-do list item.
The authorization rule was in this case that the user
can only modify or delete their own resources.
In large applications you might add users
with access levels like regular users and admins
with elevated permissions to perform specific operations.
In enterprises, authorization is also often used
to make sure that the user has even access
or is allowed to access a given internal application.
Next, let's look at how single sign on works.
And I'll really show you this in a very simplified way.
And it really depends on which technology
or standard that you're using,
but in a nutshell, it works like that.
So in the morning,
you come to the office and switch on your computer.
And you want to access some internal application like email.
Let's imagine you work in a company
that uses single sign on.
In the morning,
you start your computer and want to access your email
or some other resource with your browser.
Let's call this resource the service provider.
The service provider is configured
to authenticate users using single sign on.
And right now,
your request does not contain the expected credentials.
It will now redirect
you to a so-called identity provider, short IP.
Now, it depends on if the identity provider
can authenticate you.
If not, it will send you to a login page.
And hopefully, you come back with a valid user session
containing authentication information.
So basically, now,
your user profile is stored with your session.
Still we don't know if you're allowed to access
the service provided by the service provider.
So now, the authorization server comes into play.
It will look up if you are allowed to access the service.
And if you are, it will then send you
with an authentication session back to the service provider.
And you can finally access to your email.
The way how this authorization information provided
to the service provider.
Now, it really depends on which technology
or standard you're using for authorization.
Key is here that the service provider trusts
the identity provider and the authorization server.
And delegates authentication and authorization to it.
Of course, there are well-known standards
for implementing SSO today.
The oldest and most popular one is SAML.
It's security assertion and markup language.
And it's an open standard for exchanging authentication
and authorization data between parties.
In particular,
between an identity provider and the service provider.
And the typical use case for that is Enterprise SSO.
So if you're working in an enterprise.
And you have maybe a log in
against an Asia-active directory or something similar,
you're using most likely SAML.
Then there is OAuth 2.0 aka OAuth2.
This is an open standard for authorization.
A typical use case is to grant websites applications access
to the information on other websites,
but without giving them passwords.
Very often, this is used to authenticate API requests
to other websites.
Additionally, and this is important
because we will do this in this chapter.
It can also be used for authorization in single sign on.
So that's a bit of a contradiction because we said before,
it can only be used for authorization,
but you will see this in a bit.
And most recently, OpenID Connect entity stage.
And it's an identity layer
built on top of the OAuth2 framework.
And it provides real standardized authentication.
Today's most typical use case is Consumer SSO.
So single sign on for regular consumer apps,
but we will see what the future will bring.
And it might want to even replace SAML, as it's more likely.
Which standard or technology
to use highly depends on the use case.
And often, you don't have much of a choice
because you have to use what the third-party,
like your company's SSO server supports.
Regardless, passport likely comes with a strategy for it.
For our example, we will use GitHub as OAuth provider.
And I will show you a popular way
to use it for authentication,
although it does not support OpenID Connect.