OAuth and User Authentication

Loading...

Из курса от партнера The Hong Kong University of Science and Technology

Server-side Development with NodeJS, Express and MongoDB

398 оценки

The Hong Kong University of Science and Technology

Server-side Development with NodeJS, Express and MongoDB

398 оценки

Курс 4 из 4 — Specialization Full-Stack Web Development with React

This course deals with all things server-side. We base the entire course around the NodeJS platform. We start with a brief overview of the Web protocols: HTTP and HTTPS. We examine NodeJS and NodeJS modules: Express for building web servers. On the database side, we review basic CRUD operations, NoSQL databases, in particular MongoDB and Mongoose for accessing MongoDB from NodeJS. We examine the REST concepts and building a RESTful API. We touch upon authentication and security. Finally we review backend as a service (BaaS) approaches, including mobile BaaS, both open-source and commercial BaaS services. At the end of this course, you will be able to: - Demonstrate an understanding of server-side concepts, CRUD and REST - Build and configure a backend server using NodeJS framework - Build a RESTful API for the front-end to access backend services

Из урока

Backend as a Service (BaaS)

In this module we learn about Mongoose population, a way of cross-referencing documents and populating the documents from other documents. We then review secure communication using HTTPS. We look at Backend as a Service (BaaS) and take a brief look at Loopback.

OAuth and User Authentication25:43

Exercise (Video): Using OAuth with Passport and Facebook36:35

Познакомьтесь с преподавателями

Jogesh K. Muppala
Associate Professor
Department of Computer Science and Engineering

I'm sure you have one or more social media accounts.

Be it Facebook, Twitter, YouTube, Google, GitHub,

or many other such service providers, where you registered phone and account.

Now, these service providers in turn,

are willing to provide authentication services on your behalf.

So, for example, you see the proliferation of a number of websites

and mobile applications where you are allowed to login

using your social media accounts.

Now, how does this actually work?

Many of these social media account providers act

as authentication service providers using a protocol called as OAuth.

We'll look at OAuth, and how it enables these third-party authentication providers

to provide authentication on your behalf,

and allow you to log into other services using their social media accounts.

I'm sure you might have heard in the passing about OAuth 1 and OAuth 2,

and might have heard from people saying

that Facebook provides OAuth 2 based authentication,

or Google provides OAuth 2 based authentication and so on.

I'm sure you must be wondering,

what exactly are these OAuth1 and OAuth 2 meant to be?

Now, OAuth1 and OAuth 2 are authorization frameworks

that are based on open standards.

And these can be used over the internet to authenticate

your identity to many websites or mobile applications.

Now, when you use these services,

you are depending on one of the social media accounts like Facebook,

Google, Twitter, Microsoft, Instagram,

GitHub, DigitalOcean, and many more,

who provide these authentication services for others to make use of.

These authentication service providers promise to

the users of these authentication service that they will authenticate the identity

of the user based upon their submission of

their credentials for these social media services.

Now, there is a complementary service OpenID.

But, of course, not related to OAuth but provides similar kind of service.

But most standard social media service providers,

as you'll see listed here,

provide OAuth 2 based services these days.

Now, as I mentioned, OAuth1 and OAuth 2 are authentication protocols,

and OAuth 1 was the first protocol that came into being.

This was evolved from Twitter,

Blaine Cook being the person behind it,

and this is documented in the Internet Engineering Task Force, RFC 5849.

So, if you want to read the gory details of how these protocols work,

that is the place to find that.

OAuth 2 protocol evolved from OAuth 1 to make it more simpler,

and to provide a simpler way for client development.

And this is documented in IETF RFC 6749 and thereafter,

another bearer token usage came about in IETF RFC 6750.

Now, from our perspective,

we don't really want to go into details of how these protocols actually work.

Instead, all we are interested in that is,

how do we leverage these for user authentication within our web application,

or within our mobile application,

when we need to authenticate the user to

the Express server that we have been building on so far?

Now, we'll primarily concentrate on OAuth 2,

because in the exercise,

we will look at the use of Facebook as an OAuth 2 authentication service provider,

and here, we need to understand

a few terms to see how exactly this OAuth 2 protocol works.

At least, the bare-bone details of how the protocol itself functions.

Now, in case of OAuth 2,

we always talk about a resource ownership.

Now in this case,

the resource that I'm referring to is not

the resource that is stored on the Express server.

Instead, the resource that we are referring to here,

is the identity of the user.

Now, any server, like the Express server that we have been building,

wants to get access to this resource,

that is your identity.

Now, where is your identity?

Your identity is stored on one of

those social media authentication service providers like Facebook and so on,

because you have already created an account on these social media sites.

So, your information or your identity information or

your profile information is stored at Facebook, for example.

Now, your Express server wants to get access to your identity and

verify that it is really you that is trying to access the Express server.

So, in this case,

the Express server that we have developed,

acts as the client application.

So, this is where the client application,

which is the website or the mobile app that wants

access to the resource server in order to obtain the information about you.

What is a resource server that we're talking about?

This is the Facebook OAuth authentication server,

which also provides your profile information on request.

Now, of course, you won't randomly keep distributing your profile information.

Instead, you want to be able to verify that you are providing access to

your profile information to an authenticated service provider or an authenticated server.

Now, this is where your client application or the Express server here,

for example, will register on Facebook with an account saying that I am operating an app,

and I want to register myself as a potential source which can

approach you to authenticate users when they provide

access to their profile that is stored on your site.

So, the Express server,

in this case acting as the client application,

will register itself on Facebook and obtain a ClientID and a client secret from Facebook.

Now, when the Express server registers on Facebook,

you need to have an account on Facebook,

an authenticated account on Facebook,

which you will use to set up this app on Facebook.

So, once you register yourself,

then you will get access to a ClientID and a client secret.

Now, the resource server,

as I mentioned, is the server that is hosting the protected data.

Protected data meaning the profile of the user that wants to access the Express server.

So, the Express server wants to access this resource server,

and get hold of the profile data of the user that wants to access the Express server.

So, you see the relationship here.

So, when I talk about a client application,

I don't mean their front-end application,

but their Express server that is trying to provide you

access to resources that it has on its site.

But the Express server,

in order to enable you to access,

will need access to your Facebook resource server which

will authenticate you and provide your profile information to the Express server.

So, the resource server that I'm talking about here,

is the Facebook's OAuth 2 authentication server

plus the resource server that gives you access to the profile information of the user.

And the authorization server is the server that will

authorize somebody to access

the resource server in order to retrieve the profile information.

Now, the user is the one that has the profile information on the resource server.

The user should authorize the Express server to go

to this resource server to fetch the profile information.

But if the user needs to authorize the Express server,

the user needs to log into the Facebook account,

and then obtaining information from Facebook called as an access token,

which the user then will pass on to Express server.

Now, when the access token is obtained from Facebook through the OAuth 2 protocol,

the access token will be issued in terms

of allowing this client application or the Express server,

which is already registered on Facebook saying that

this client server I will authorize to

access their profile information from their Facebook OAuth service provider.

So, again, this is a bit confusing.

We'll see a diagram where this flow of

information is explained a bit more clearly to you.

One point that I just mentioned is about an OAuth token or the access token.

What is this access token?

The access token is something that the authorization server issues for you.

Which authorization server?

This is the third party OAuth 2 authorization server,

Facebook server, in this example.

So they're Express server application.

Now, you, as their front end user,

wants to access something from the Express server application.

The Express server application will tell you that you authenticate

yourself from Facebook and then obtain access token from Facebook.

This access token is issued to

the front-end user from Facebook when the user logs into their Facebook account.

Now this access token is issued in the name of the client application,

Express server, which has already registered on Facebook.

So, in order for the user to access Facebook to obtain his access token,

the user requires the client ID of the client application or the Express application.

So this client ID is embedded in

the front-end application that this Express server will serve up for you.

So Express server is serving up a website that you are accessing,

then that website will contain code where

the client ID of that Express server is already embedded in there.

One more piece of information that I mentioned is a client secret.

Now, in the authentication flow that I'm going to talk about,

the client secret will be never revealed to anybody.

The client secret will be only on the Express server-side.

Back when the Express server tries to authenticate and

obtain access to the user's profile from Facebook,

the client application, the Express server will

send both the client ID and the client secret,

together with the access token that the user supplies to it to Facebook.

And Facebook, in turn,

authorizes their client application to access

the resource server in order to obtain the user's profile data.

And once the user's profile data is obtained from the Facebook resource server,

then my Express server is going to create an account

for this particular user who has logged them with their Facebook account.

And then, subsequently, supply a JSON web token to the user,

which the user can then use in order to access

the resources that are stored on the Express server.

So, again, to summarize this,

I have a diagram here to explain this to you in a bit more detail.

In addition to this,

there is also a refresh token.

When an access token is issued by the Facebook OAuth 2 server,

the access token has a limited lifetime.

After that, the access token will become invalid.

So the access token has to be kept confidential.

So all this exchange of tokens between the different sites

will be done in an encrypted matter using HTTPS protocol.

So make sure that when you're sending your access token from

your user front-end application to the Express server,

you will only send the access token through HTTPS, not HTTP.

This is very important because you don't

want your access token to be revealed to anybody because anybody

who can get one of your access token can pretend to be

their client application and then get access to your user profile.

So that is very important.

Now, since the access token has a limited lifetime,

there is also a corresponding refresh token,

which can be used to refresh an expired access token.

Now, in the kind of flow that we are going to be

using with our application in the exercise,

we will not be able to use the refresh token.

Any time the user wants to authorize

the Express server to go and fetch the profile information from Facebook,

the user will have to explicitly supply

a new access token that is obtained from Facebook.

The one part that I have just mentioned briefly,

but I haven't elaborated,

is how does the client application, the Express server,

the scales, how does it register itself at the OAuth 2 service provider?

Now, this is where many of the OAuth 2 service providers

provide a way of registering an app on their site.

So a client application,

the Express servers in our example,

will register itself as a client application on the OAuth service provider.

So as you will see in the exercise,

the very first step that we will do is to log into Facebook with

our account and then create an app on Facebook site.

When you do that, Facebook will issue you a client app ID and a client secret.

This procedure applies to many other OAuth service providers because

this is the general flow that the OAuth 2 protocol talks about.

So the client app ID and the client secret are useful for us to be able

to prove our identity to

the OAuth server when we are passing an access token that we obtain from the user.

Now, there is also a redirect URL that you need to

register when you are registering the client application,

and you will see me performing that in the steps that I register

the app on the Facebook site.

Now, to summarize the information flow

that we have just briefly talked about in earlier case,

let me start at this point.

The first point to look at is the resource owner.

So the resource owner here is the user that

is going to use his or her social media account.

Facebook, in this example,

has the authentication for the user.

So the resource owner is the one that has the profile about the resource.

And this profile information for every Facebook account,

they were stored on the Facebook server.

And so the Facebook server provides the resources server here.

So that is the OAuth service provider that you see on

the right hand side of this picture here.

So imagine the Facebook server on the right hand side, that client application,

which has the rest API server,

the Express server that we have implemented,

is a client application in this case,

and the resource owner is the user.

URL front-end user, that is going to

authorize you to go to Facebook to verify that user's credential.

So when you want to access information on the client side,

you will first have to go and

authorize this client application to be able

to obtain access to your profile information.

So the client application,

if it is acting as a web app,

it will provide an appropriate button in there saying log in using Facebook.

And so when you click on the button,

essentially, the first step is initiated.

The user authorization request is initiated.

So your client application,

through the user agent,

the user agent is basically the client application, the front-end application.

It could be the Angular app that we have developed or that mobile app,

whether it is Ionic or whether it is

a NativeScript app that we have developed in the courses earlier in

the specialization or even a native app like an iOS app or an Android app.

All these act as the user agent.

So the user agent,

they use an authorization request process through

the user agent to the authorization server,

which is the Facebook server.

Now, when that gets passed in,

then the resource owner or the user,

who is trying to give access to his or her profile to this client application,

will have to authorize Facebook to be

able to share this information with the client application.

In the implicit flow grant approach that we are using in

our example here and also in the exercise that follows,

the implicit flow grant approach is

the most suitable approach when you are implementing a web app using

a framework like Angular or the hybrid mobile app

with Ionic or a NativeScript or even a native app.

The implicit flow grant approach is much more simpler way of

operating the OAuth 2 for such kind of applications.

So then the resource owner clicks on the log in button,

then the authorization server will prompt the resource owner with the information saying,

"This client application wants to access your profile information.

Do you authorize it?"

And so this will be popped up by Facebook,

and then you will click on a button there saying, "Yes,

I authorize this client application to access on my behalf."

So, on that point,

the authorization server on Facebook,

the OAuth 2 authorization server on Facebook,

will generate an access token.

To generate this access token,

it will make use of the client ID for this client application,

the Express server application that we register.

So the client ID should be part of the user agent that this user uses.

So this client ID will be embedded into the Angular app,

the Ionic or the NativeScript app or even an iOS or an Android app.

So the client ID will then be used by

the user agent to turn the authorization server saying,

"This client app application wants access to my profile,

and I am willing to authorize you to allow the access to the profile."

So, at that point,

the authorization server will send an access token to the user agent in this case.

So, remember, this access token comes into the user agent,

which is the mobile app or their Angular app that is implemented by us.

Then this user agent will take this access token and

then pass this access token over to that client application.

So the OAuth to log in,

but the access token will be passed onto the client application,

the Express server in this case,

at a particular route on the user's router,

the authentication route on the client application site.

Now, previously, we saw the use of local authentication,

where we sent a request to slash user slash log in.

Now, for this to work in our app,

we will set up another one on slash users,

slash Facebook, slash token, and so on.

So another URL on which we provide this access token over to the Express server.

Now, when this access token is obtained by the Express server,

the Express server will take this access token,

and then together with its client ID and the client secret,

it will send this information over to the authorization server.

And the authorization server will then allow their client application

to access the resource server in order to obtain the profile information.

And so the profile information will be sent back in step number six,

back to the client application in this case.

So when the client application obtains the profile information for the user,

then the client application will create a new account for

the user on each site if an account doesn't exist.

If that user has already logged in earlier using their Facebook ID,

an account will already exist so that client application and the Rest API server will

simply crosscheck to see that this user account already exists.

And, at that point,

the user is authenticated to the third party log in functionality

provided by the OAuth 2 authentication service of Facebook.

At that point, then the client application will generate a JSON Web Token,

in the example that we will implement and exercise,

and then pass this JSON Web Token back to the user agent or the front-end application,

or Angular app, or the Ionic app,

or the NativeScript app.

Then the JSON Web Token will be subsequently used by the user in order

to authenticate himself whenever he or she wants to

access any resources stored on the Express server.

So, once you obtain the JSON Web Token,

all subsequent operations, you have already seen how to do that with JSON Web Token.

So, once you obtain the JSON Web Token,

your job is done,

and then you can proceed forward with the normal operation from that point onwards.

Now, when the JSON Web Token expires,

then you have to go through the whole process of re-authenticating yourself and,

subsequently, allow the users to access information on your site.

So, with this quick understanding of how OAuth 2 operations work,

again, as you see, there is a lot of details here.

But, fortunately, we don't have to deal with all these details because we are going to be

using a node module that takes care of much of these details on our behalf.

Since we have already set up our Express server to use Passport,

we can now use another node module code as Passport-Facebook-Token module.

The Passport-Facebook-Token module essentially implements

the implicit grant approach that I talked about earlier.

And then you can initialize

a new strategy in your Passport strategy, within your application.

And so that Passport-Facebook-Token module enables you to set up

a new Passport authentication strategy to use Facebook-based OAuth 2 API.

And so to make use of this module,

you install this by saying past npm install passport- facebook-token,

minus minus save, and then once you installed that,

then you will configure a Facebook strategy within your application, and, thereafter,

make use of this to configure the strategy for your Passport to

make use of if we are making use of the OAuth 2-based authentication for our application.

With this quick understanding of OAuth 2,

let's move on to the exercise,

where we will configure our Express server to indeed make use of

this implicit grant approach to enable us to

verify our identity to the Express server and,

thereafter, gain access to the resources, the dishes,

the promotions and the leaders' information that is stored on our Express server.

Ознакомьтесь с нашим каталогом

Присоединяйтесь бесплатно и получайте персонализированные рекомендации, обновления и предложения.

Coursera делает лучшее в мире образование доступным каждому, предлагая онлайн-курсы от ведущих университетов и организаций.

© Coursera Inc., 2018 Все права защищены.

Загрузить из App Store

Загрузить в Google Play