Would you like to manage authorization of your APIs
and applications on the cloud
so other entities like third-party applications can use them?
Have you thought about using an authorization standard
that uses an access token?
Let me show you how an access token works.
Think about your car keys.
Your car usually has a regular key and a valet key.
The valet key has no access to the glove box,
trunk, motor, or gas tank.
This key is mainly used to park your car
while you visit restaurants, stores,
and other businesses that offer a valet parking service.
OAuth 2.0 is an open standard framework
that can securely issue and validate
tokens for services on the internet.
OAuth essentially allows access tokens
to be issued to third-party clients
by an authorization server
with the approval of the user.
The third party then uses the access token
to access the protected resources
hosted by the resource server.
The access tokens will have some limitations,
like the valet key.
So, who are the participants
or roles involved in this standard?
The resource owner or user who owns the data.
The client application is who wants to access
or manipulate the user's data;
for example, a web or mobile app.
The authorization server issues access tokens
to the client app,
which are used to request access to the user's data.
Google, Facebook, and LinkedIn
are some common examples.
The resource server retrieves the user's data
if the owner authorizes it.
Examples include Dropbox,
Google Drive,
or any social network resource.
In many scenarios, the authorization server
and the resource server
are part of the same trust domain.
All of these participants interact through flows
like the two or three-legged flows.
The three-legged flow
typically involves three legs or parties:
The user or resource owner,
the client or third-party application,
and the authorization server.
On the other hand,
the two-legged flow
describes a typical client server scenario,
without any user involvement.
An example is a local Facebook mobile application
accessing your Facebook account.
Let's review a scenario
where all these participants are involved.
Here, a user wants to book a flight
from the airline website or client application.
He's able to complete the reservation
without manually creating a user account
within the airline system,
because he uses a trusted authorization server
such as Facebook or Twitter to login.
He gives his consent to use data
from his social account through OAuth.
When the user tries to pay for his tickets
using net banking,
he's prompted to log into his bank account
which then authorizes the payment.
Just like this scenario,
there are many others were mobile applications
and cloud services are using OAuth
for authorization
without the need to manually create an account
for the third party app.
Let's take a look at what happens
when the user gives consent to
the airline application through Facebook.
First, the user's being redirected
to the Facebook OAuth consent form.
The URL shows request elements
like app ID,
client ID,
response type,
and scope, among others.
In this case the response type
indicates that it expects a token
from the authorization server.
The authorization scope determines the resources
to access from the users Facebook account,
like email and user_birthday.
After the user gives consent to access his resources,
the airline application receives an access token
which is used to access the resources
on behalf of the user.
An access token represents an authorization
that a client application may have to do something
on behalf of the resource owner or user.
It can only be used by a specific client application
and it has a time out.
There are other types of tokens in OAuth.
For example, Refresh Tokens,
which allow clients to obtain a fresh access token
without re-obtaining authorization
from the resource owner.
It's a long live token,
and it's useful when the client application
wants to keep an authorization for a very long time,
time like days or even months.
Some authorization servers support the Refresh Token
revocation prior to its time out;
for example when the user removes
the previously granted airline application
from his Facebook app settings.
Besides the previous tokens,
the authorization code works almost like a token,
but it doesn't carry out any authorization information
or scopes in it.
It's used in a very specific situation;
We'll talk more about this
in a future video.
Every token has specific authorization scopes
and durations of access,
granted by the resource owner,
and enforced by the resource server
and the authorization server.
The scope is a parameter,
which is included when a client app makes a request
to the authorization or token endpoints.
OAuth scopes provide a way
to limit the amount of access
that's granted to an access token.
For example,
an access token issued to a social network application
might include
post to my wall,
send notification,
or read my age.
The client application can trigger processes
or access user's data through these tokens.
An access token
proves that the user has given consent
to access specific information or resources.
OAuth defines a number of grant types
or ways for a client application
to acquire an access token.
They include
Authorization Code,
Implicit,
Resource Owner Password Credentials,
and Client Credentials.
Each grant type is used
in a specific scenario.
To learn more about OAuth Grants,
when to use them, and how they work
check out other videos in this series.
Thank you for watching.