-: So what exactly is Oauth2?
So O of two is a standard protocol for authentication
and authorization and,
is widely used mainly in web apps.
Now the OAuth2 protocol has many moving parts,
and is quite complicated to implement,
but we will discuss only the high level details.
So to understand how exactly OAuth2 is working
let's first review the OAuth2 protocol components.
So the first one is naturally the user.
The user is some, again
end user who wants to access protected resources in the api.
In other words, this is someone
and it can be a human being or a software,
that wants access
to a resource that is protected
with authentication and authorization mechanism.
The next component is the client app.
This client application is the application
that is accessing the api.
So the user is using the client app
in order to access the API that is on the server.
The next one is the authorization server.
Now the authorization server is a specialized
server that is used to authorize the user
for the client application.
So the authorization server identifies the user
using whatever method of identification it supports
and tells back the client
app who the user is and,
what is he allowed to do.
And the last component is the resource server.
which is actually the API itself that we want to access.
Okay, so we have the four components,
the user, the client app
the authorization server, and the resource server.
And now let's see the complete flow
of Oauth 2 and how all these components work together.
So we have the client up,
and we have the resource server.
The first thing in the flow is
that the client app calls the API anonymously
without passing any identification data.
The resource server identifies that the call is anonymous
and that no user data is passed,
and it tells the client app
to redirect to authorization server.
The authorization server asks user to grant permission.
Of course, after identifying the user
and returns an access token to the client app.
This access token contains the data that is needed
by the resource server, the api
in order to identify the user and to figure
out what exactly the user is allowed to do.
The next and the last step
of the OAuth2 flow is that the client app
sends the access token to the resource server
and now the resource server knows who the user is
and whether he is allowed to access the api.
So if this sounds a little bit complicated
let's see a demo of this flow, and I'm sure
that after that the whole process will be much clearer.
So we will demonstrate OAuth2
using a site called Feedly.
I dunno if you know of Feedly,
but Feedly is one of the best RSS clients
in the web,
and I highly recommend you to use it.
RSS clients are clients that are subscribed
to blogs and they are a great resource
of learning in any field of knowledge you would like.
I'm using Feedly almost every day to learn new things
about api, about software architecture
about technological advancement
about public speaking, and lots more.
So again, highly recommended.
Now, when browsing the Feedly homepage,
you will be presented with this page.
And now let's click on login.
What happens now,
is that Feedly asks us how do we want to login.
So if you remember from our flow
we say that the server is redirecting the client app
to an authorization server.
So basically what is happening here is that Feedly
asks us which authorization server do we want to use.
So I'll go with Facebook.
So again, Facebook here is functioning
as an authorization server.
And I'll log in.
And now I'm logged into Feedly.
So basically,
Facebook told Feedly,
I know who this guy is
you can see down here
the picture of me.
So Freedly knows who I am,
and now I am logged into feedly.
without Feedly doing anything related to the identification.
So basically what happened here is
that Facebook identified me for Feedly
and returned this information to Feedly.
Now, in order to make this flow walk the OAuth2
flow walk the authorization server.
Facebook in our example, should be familiar
with the resource server or Feedly again, in our scenario
because when Feedly redirected me to Facebook
then he basically told Facebook,
Listen, I'm Feedly,
and I want you to identify this user
for me and then return the information to Feedly.
So Facebook should be familiar with Feedly.
So in order to do that,
the resource server
must register itself with the authorization server.
So this process is called
the app registration,
and in this process the resource server comes
to authorization server and registers itself.
The registration process includes filling some data
about the resource server, mainly the name
and the URL address to which the authorization server
should access to return the information about the user.
So let's see a demo
on the how app registration process is working.
Now I'm going to demonstrate the app registration process
with GitHub.
GitHub can also be used as an authorization server
for OAuth2 ,
which means that it has an app registration page.
So this is the app registration page in GitHub.
So I'll just type in the details
of the application I want to register.
This is of course a fictional application.
So let's type in the application details.
So the application name will be order
management ,the homepage will be
http
order
manage.com.
We'll skip the description
and the authorization call back url.
So this is maybe the most important part
in the application registration process.
If you remember from our discussion on the OAuth2 flow
after the authorization server authorizes the user,
it should tell back the application who the user is and,
what is he allowed to do.
So the way to do it is
that the authorization server calls a specific call back URL
of the application passing in this data.
So this is URL will be specifying
and it will be
order manage.com/callback.
So this is the URL the authorization server will call,
after authorizing the user.
So let's click register application
and the application is registered
and we see some data about application.
Now, the most important things to note about this page,
are the client ID and,
the client secret.
Those two keys must be passed
to the authorization server when asking for authorization so
that the authorization server will know which
application is requesting the user authorization.
Okay, so we talked about the Coauthor flow
and we talked about the application registration.
And now let's move on.