6. Objectives
To give an eye opener to the audience about the authorization technology
in the web
To give the audience a basic understanding on how an authorization
framework does its job
8. Agenda
A.Introduction
a. Traditional Client-Server Authentication Model
b. Roles
c. Protocol Flow
d. Authorization Grant
i. Authorization Code
ii. Resource Owner Password Credentials
B. Protocol Endpoints
11. Grading System Example
GRADING SYSTEM
( Shows grades in different
subject )
USERNAME
PASSWORD
LOGIN
Juan Grades
Science
: 87
Math
: 87
English
: 87
USER
12. Grading System Example
GRADING SYSTEM
( Shows grades in
different subject )
USERNAME
PASSWORD
LOGIN
Juan Grades
Science
: 87
Math
: 87
English
: 87
USER
GWA COMPUTING
SYSTEM?
How???
14. A.Introduction
Traditional client-server authentication model
GWA
COMPUTING
SYSTEM? GRADING SYSTEM
/ SERVER
Requests access /users
Denied request if not
Authenticated
Authenticated access to /users
Shares Credentials
User / Resource Owner
Returns /users
resource
Auth
Layer
15. A.Introduction
Sharing Credentials creates several problems:
Third-party applications are required to store the resource owner's
credentials for future use, typically a password in clear-text.
Third-party applications gain overly broad access to the resource owner's
protected resources, leaving resource owners without any ability to
restrict duration or access to a limited subset of resources.
16. A.Introduction
Resource owners cannot revoke access to an individual third party without
revoking access to all third parties, and must do so by changing the third
party's password.
Compromise of any third-party application results in compromise of the
end-user's password and all of the data protected by that password.
18. A.Introduction -> Roles -> Resource Owner
Resource Owner
An entity capable of granting access to protected resource.
When a resource owner is a person, it is usually referred to as end-user.
USER
19. A.Introduction -> Roles -> Resource Server
Resource Server
The server hosting the protected resources, capable of accepting and responding to
protected resource requests using access tokens.
GRADING SYSTEM
/ SERVER
20. A.Introduction -> Roles -> Client
Client
An Application making protected resource requests on behalf of other resource owner and
with its authorization.
GWA COMPUTING
SYSTEM?
21. Client Registration (Client Types)
OAuth defines two client types, based on their ability to authenticate securely with the authorization
server:
Confidential
Clients capable of maintaining the confidentiality of their credentials or capable of secure
client authentication using other means.
(e.g clients implemented on secure server with restricted access to the client
credentials),
Public
Clients incapable of maintaining the confidentiality of their credentials and incapable of
secure client authentication about the client type.
22. A.Introduction -> Roles -> Authorization Server
Authorization Server
The server issuing access tokens to the client after successfully authenticating the resource
owner and obtaining authorization.
GRADING SYSTEM /
SERVER
23. A.Introduction -> Protocol Flow
Client
Resource Owner
Authorization
Server
Resource Server
( A ) Authorization Request
( B ) Authorization Grant
( C ) Authorization Grant
( D ) Access Token
( E ) Access Token
( F ) Protected Resources
24. A.Introduction -> Protocol Flow
Client
Resource Owner
Authorization
Server
Resource Server
( A ) Authorization Request
( B ) Authorization Grant
( C ) Authorization Grant
( D ) Access Token
( E ) Access Token
( F ) Protected Resources
25. Protocol Flow in Real World Situation
( A ) Give me the key of your car
( B ) It’s with key holder, I will give you a chit, show
this to key holder and ask for key.
( C ) Give me car key. Here is the chit of approve
from owner
( D ) Ok, This is accepted, here is the key
( E ) Give me car to repair, this is the key
( F ) Ok, have the car
Mechanic
Car Owner
Key Holder
Car Park
26. A.Introduction -> Authorization Grant
An authorization grant is a credential representing the resource owner’s
authorization ( to access its protected resources ) used by the client to
obtain an access token.
The OAuth specification has four (4) grants types:
Authorization code
Resource owner password credentials
Implicit
Client credentials
27. A. Introduction -> Authorization Grant -> Authorization Code
The authorization code is obtained by using an authorization server as an
intermediary between the client and resource owner.
28. Authorization a client using FB Account
USER
www.scribd.com
FB AUTHORIZATION SERVER
User visits a client
CLIENT
Redirects upon clicking login
with fb button
FB Server redirects back the
user to scribd.com
29. Authorization Code Grant
RESOURCE OWNER
USER-AGENT
( Browser / Google
Chrome Browser )
CLIENT
AUTHORIZATION
SERVER
(A) (C)
(B)
(A) Client Identifier & Redirection URI
(B) User Authenticates
(C) Authorization Code
(D) Authorization Code & Redirection URI
(E) Access Token (w/ Optional Refresh Token)
30. Authorization Code Grant
RESOURCE OWNER
USER-AGENT
( Browser / Google
Chrome Browser )
CLIENT
AUTHORIZATION
SERVER
(A) (C)
(B)
(A) Client Identifier & Redirection URI
(B) User Authenticates
(C) Authorization Code
(D) Authorization Code & Redirection URI
(E) Access Token (w/ Optional Refresh Token)
31. A. Introduction -> Authorization Grant -> Resource owner
password credentials
The resource owner password credentials ( i.e., username and password) can
be used directly as an authorization grant to obtain an access token.
Should be used only when there is a high degree of trust between the
resource owner and the client.
34. Protocol Endpoints
The authorization process utilizes two authorization server endpoints:
Authorization Endpoint
Used by the client to obtain authorization from resource owner via user-agent
redirection.
Token Endpoint
Used by the client to exchange an authorization grant for an access token, typically
with client authentication.
As well as one client endpoint
Redirection endpoint
35. Web links
Demo OAuth 2.0
The OAuth 2.0 Authorization Framework
OAuth V.1.0 VS OAuth 2.0
Which OAUTH 2.0 Grant should I use?
Security Considerations
Notes :
OAuth2 + API Security By Amila Paranawithana
Editor's Notes
Authentication is any process by which a system verifies the identity of a User who wishes to access it.
Authorization is the process of giving someone permission to do or have something.
Resource Owner - An entity capable of granting access to a protected resource.
Resource Server- The server hosting the protected resources, \
Client - An application which accesses protected resources on behalf of the resource owner (such as a user). The client could be hosted on a server, desktop, mobile or other device.
Example. The mobile fb app is a client. The web fb is a client. Anything that access the resource server in behalf of a user is a client.
Authorization Server - A server authenticates a client and resource owner, and authorizing the request.
Access Token - Is a token “String” used by any client to access protected resource in behalf of someone.
In this diagram we show a traditional client-server authentication model.
We can think of this diagram like logging in a Grading System.
Client in this diagram refers to user ( e.g me ) and the server as Grading System in LNU ( The one you are using right now to view your grades )
NEXT >>>
In the traditional client-server authentication model, the client requests an access-restricted resource (protected resource) but first go to the authentication process <NEXT> and get denied <NEXT> if the credentials given by the client are not authenticated and get passed <NEXT> if authenticated.
The server then returns <NEXT> the requested resource by the client.
<NEXT> >>>
I have here a Grading System Diagram Example
In which the user logins to the grading system to view the user grades.
Now here comes a problem. I want to create a GWA Computing System that will use the grades of the user.
<NEXT> >>>
The problem is how can we get the grades of Juan so we can use it in our GWA Computing System?
Anyone?
Some of you might have ideas and is just afraid to share.
But this is how they solve this problem. They solve this problem by sharing the username and password to the GWA Computing System.
NEXT >>>
This is the diagram for our application.
<NEXT> >>>
First, the resource owner share credentials ( username and password ) to the 3rd party client ( our application ).
The 3rd party client uses <NEXT> the resource owner credentials to authenticate to the server through the auth layer. And gets denied <NEXT> if the credentials given are not correct and <NEXT> passes thru if authenticated.
The server then returns <NEXT> the requested resource to the 3rd party client.
Question: It seems correct right?
But what are the downside or the disadvantages of sharing the resource owners credentials or your username and password to a 3rd party client?
NEXT >>>
<READ>
NEXT >>>
<READ>
Now you may ask. What should we do then to avoid the said problems. In order for our application to use the needed data?
NEXT >>>
In order for us to understand OAuth thoroughly, we have to understand the four roles OAuth defines : <READ>
NEXT >>>
Note that :
The interaction between the authorization server and resource server is beyond the scope of this presentation.
The authorization server may be the same server as the resource server or a separate entity. A single authorization server may issue access tokens accepted by multiple resource servers.
OAuth defines two client types, based on their ability to authenticate securely with the authorization server (i.e., ability to maintain the confidentiality of their client credentials):
This image is the abstract OAuth 2.0 flow that describes the interaction between the four roles and includes the following steps
<NEXT> >>>:
The client requests authorization from the resource owner <NEXT> >>>.
The authorization request can be made directly to the resource owner (as shown), or preferably indirectly via the authorization server as an intermediary.
The client receives <NEXT>>> an authorization grant,
Which is a credential representing the resource owner's authorization, expressed using one of four grant types defined in this specification or using an extension grant type. The authorization grant type depends on the method used by the client to request authorization and the types supported by the authorization server.
The client requests <NEXT> >>> an access token by authenticating with the authorization server and presenting the authorization grant.
The authorization server authenticates the client and validates the authorization grant, and if valid <NEXT> >>>, issues an access token.
The client requests the protected resource from the resource server <NEXT> >>> and authenticates by presenting the access token.
The resource server validates <NEXT> >>> the access token, and if valid, serves the request.
NEXT >>>
Now we have a real world example of Protocol Flow in OAuth
Our example is a mechanic (Client) needs to get the car (Resource) of the car owner ( Resource Owner ).
First the mechanic asks the key of the car of the owner and then the car owner gives a chit or a note/authorization ( Authorization Grant ) in order for the mechanic to get the key from the key holder.
The mechanic presents the note to the key holder ( Authentication Server ).
The key holder authenticates or see if the note is valid
If the note is valid the key is given to the mechanic
The mechanic then gets the car from the car park ( Resource Server ) presenting the key given by the key holder
The Car park gives the car.
Next >>>
Now I have been mentioning the word “Authorization Grant”. What does it exactly means in laymans term?
In OAuth Usage <READ>>>
NEXT >>>
<READ>
What do you mean by authorization code??? Anyone? It’s a code used to authorize in behalf of someone. Like an authorization letter.
Now facebook is using this authorization grant.
Anyone? In which part facebook is using this authorization grant?
NEXT >>>
<READ>
Now let’s try to view what really is happening in an authorization code grant
NEXT >>>
This is the flow of authorization code grant in OAuth.
In our example earlier who is acting as the client? -> scribd.com. What is the user-agent? Browser -> Who is the resource owner? User -> Who is the authorization server? Facebook Authorization server.
Let’s try to do this flow step by step you might recall where you encountered this flow.
<NEXT>>>
The client initiates the flow by directing the resource owner's <NEXT> user-agent to the authorization endpoint <NEXT>.
The client includes its a redirection URI to which the authorization server will send the user-agent back once access is granted (or denied).
This is the part where the user visits the browser and clicks on login with facebook button and scribd.com redirected us to the facebook authorization server.
The authorization server authenticates the resource owner (via the user-agent) <NEXT> and establishes <NEXT> whether the resource owner grants or denies the client's access request.
This is the part where the user clicks on the okay or close button.
Assuming the resource owner grants access, the authorization server redirects <NEXT> the user-agent back to the client <NEXT> >>> using the redirection URI provided earlier (in the request or during client registration).
The redirection URI includes an authorization code provided by the client earlier.
This is the part where the facebook redirects the user back to the client.
The next part becomes tricky --
What happens is you just authorize the client “scribd.com” to use your information from facebook.com.
The client “scribd.com” has not yet access your information from facebook.com.
The client requests an access token <NEXT> >>> from the authorization server's token endpoint by including the authorization code received in the previous step.
This is the part where the client “scribd.com” asks for an access token to facebook.com.
What is an access token? Is a token “String” used by any client to access protected resource in behalf of someone from the resource owner.
Why we use access token? The reason is the server did not actually gave you an authorization you just authorize the client “scribd.com” to access your resource that is in the fb server.
The authorization server authenticates the client, validates the authorization code, and ensures that the redirection URI received matches the URI used to redirect the client in step (C). If valid, the authorization server responds <NEXT> >>> back with an access token and, optionally, a refresh token.
The last part is the server gives access to the client.
<READ>
Even though this grant type requires direct client access to the resource owner credentials, the resource owner credentials are used for a single request and are exchanged for an access token. This grant type can eliminate the need for the client to store the resource owner credentials for future use, by exchanging the credentials with a long-lived access token or refresh token.
Do you have a guess on where you have encountered this authorization grant?
Let us see the flow if anyone can recognize.
NEXT >>>
The flow illustrated in Figure 5 includes the following steps:
The resource owner provides the client with its username and password.
The client requests an access token from the authorization server's token endpoint by including the credentials received from the resource owner. When making the request, the client authenticates with the authorization server.
The authorization server authenticates the client and validates the resource owner credentials, and if valid, issues an access token.
Anyone who can recognize now? Wild guess? Facebook mobile app is the very common. Lets try to go back to the definition of this grant.