2. This presentation is based on
OAuth 2 specification and the
chapters of this book.
3. OAuth is a delegation protocol that provides
authorisation across systems.
OAuth is about:
how to get a token and how to use a token.
OAuth replaces the password-sharing anti-pattern
with a delegation protocol
that’s simultaneously more secure and more usable.
4. Two major steps to an OAuth transaction:
Issuing a token Using a token
5. OAuth2.0 authorisation grant flow
• Here the client will be interactively authorised directly by the
resource owner.
• The authorisation code grant uses a temporary credential,
the authorisation code, to represent the resource owner’s
delegation to the client.
6. Resource Owner Client
Authorisation Server
Token End PointAuthorisation End Point
Protected Resource
Redirects the user agent to
authorisation end point
User agent loads authorisation end point
Resource owner authenticates to authorisation server
Resource owner authorises the client
Authorisation server redirects user agent to the client with authorisation code
User agent loads the redirect URI
at client with authorisation code
Client sends the authorisation code and its own credential to
token end point
Authorisation server sends access token to the client
Client sends access token to protected resource
Protected resource returns resource to client
9. This redirect to the browser causes the browser to send an HTTP GET
to the authorisation server.
/authorize/authorize?client_id=P9BxWcYwdNnGFmI
t8Oiz&redirect_uri=http://localhost:8080&respo
nse_type=code&scope=openid&state=2qdOs6PJAcE1E
6qwg81R
10. Now the authorisation server will usually require the user to authenticate.
This step is essential in determining who the resource owner is and what rights
they’re allowed to delegate to the client.
12. Next, the authorisation server redirects the user back to the client
application.
This takes the form of an HTTP redirect to the client’s redirect_uri.
http://localhost:8080/?
code=VzYHKvGXwqxBMq9qn8Pw&
state=moBRz4CFpviCE4e5h0HZ
Authorisation code
13. The authorisation code is sent back to the client.
This code is a one-time use credential. It represents the result
of the user’s authorisation decision.
14. The client now sends the code and it’s own credential (client
id and client secret) to the authorisation server on its token
end point.
15. The authorisation server takes the request and performs a number of
steps to ensure that the request is valid:
• It validates the client’s credential to determine which client is requesting the
access.
• Then, it reads the value of the code parameter from the body and looks up
any information it has about that authorisation code, including which client
made the initial authorisation request, which user authorises it, and what it
was authorised for.
• If the authorisation code is valid, hasn’t been used previously, and the client
making this request is the same as the client that made original request, then
the authorisation server issues a new access token for the client.
17. This access token is returned in the HTTP response
as a JSON object:
{
“access_token”: “tdgsgsdfq232wASDq232a”,
“token_type”: “Bearer”
}
The client can now parse the token response and get the access
token value from it to be used at the protected resource.
18. The client has several methods for presenting the access token. The
recommended one: using the Authorization header.
GET /reward HTTP/1.1
Host: localhost:8080
Accept: application/json
Connection: keep-alive
Authorization: Bearer tdgsgsdfq232wASDq232a
The protected resource can then parse the token out of the header.
It determines whether it’s still valid, look up information regarding who authorised it
and what it was authorised for, and return the response accordingly.
21. Client
• It is a piece of software that attempts to access the protected
resource on behalf of the resource owner.
• It uses OAuth to obtain that access.
• An OAuth client can be a web application, a native application, or
even an in-browser JavaScript application.
22. Protected Resource
• An OAuth protected resource is available through an HTTP server
and it requires an OAuth token to be accessed.
• The protected resource needs to validate the tokens presented to it
and determine whether and how to serve requests.
• In an OAuth architecture, the protected resource has the final say as
to whether or not to honor a token.
23. Resource Owner
• A resource owner is the entity that has the authority to delegate
access to the client.
• In most cases, the resource owner is the person using the client
software to access something they control.
24. Authorisation Server
• An OAuth authorisation server is an HTTP server that acts as the
central component to an OAuth system.
• It authenticates the resource owner and client, provides
mechanisms for allowing resource owners to authorise clients, and
issues tokens to the client.
• Some authorisation servers also provide additional capabilities such
as token introspection and remembering authorisation decisions.
26. Access Token
An OAuth access token is an artifact issued by the authorisation server to a
client that indicates the rights that the client has been delegated.
OAuth does not define a format or content for the token itself, but it always
represents the combination of the client’s requested access, the resource
owner that authorised the client, and the rights conferred during that
authorisation.
OAuth tokens are opaque to the client, which means that the client has no
need (and often no ability) to look at the token itself. The client’s job is to carry
the token, requesting it from the authorisation server and presenting it to the
protected resource.
27. Scope
An OAuth scope is a representation of a set of rights at a protected
resource.
Scopes are represented by strings in the OAuth protocol, and they can be
combined into a set by using a space-separated list.
The scope value can’t contain the space character.
Scopes are an important mechanism for limiting the access granted to a
client. Scopes are defined by the protected resource, based on the API that
it’s offering.
28. Refresh Token
An OAuth refresh token is similar in concept to the access token, in that it’s
issued to the client by the authorisation server and the client doesn’t know or
care what’s inside the token.
But this token is never sent to the protected resource. Instead, the client
uses the refresh token to request new access tokens without involving the
resource owner.
In OAuth, an access token could stop working for a client at any point. When
the access token expires, client can use the refresh token to request a new
access token.
29. Authorisation grant
An authorisation grant is a way by which an OAuth client is given
access to a protected resource using the OAuth protocol, and if
successful it ultimately results in the client getting a token.
The authorisation grant is the method for getting a token.
30. What OAuth 2.0 isn’t?
OAuth isn’t an authentication protocol.
OAuth doesn’t define a mechanism for user-to-user delegation,
even though it is fundamentally about delegation of a user to a piece
of software. OAuth assumes that the resource owner is the one
that’s controlling the client.
OAuth doesn’t define authorisation-processing mechanisms.
OAuth doesn’t define a token format.
OAuth 2.0 does not define any cryptographic method.
The power of OAuth is the notion of delegation. Although OAuth is often called an authorisation protocol, it is a delegation protocol. Generally, a subset of a user’s authorisation is delegated, but OAuth itself doesn’t carry or convey the authorisation. Instead, it provides a means by which a client can request that a user delegate some of their authority to it. The user can then approve this request, and the client can then act on it with the results of that approval.
OAuth is used to grant authorisation. It enables you to authorise the web app A to access the information from the web app B without sharing your credentials.
It was built with only authorisation in mind and does not include any authentication mechanism.
The token represents the access that’s been delegated to the client and it plays a central role in every part of OAuth 2.0.
The user’s authentication passes directly between the user (and their browser) and the authorisation server; it’s never seen by the client application.
This essential aspect protects the user from having to share their credentials with the client application, the anti-pattern that OAuth was invented to combat.
The client can parse the HTTP parameter to get the authorisation code value when the request comes in, and it will use that code in the next step. The client will also check that the value of the state parameter matches the value that it sent in the previous step.
State parameter is used to protect against CSRF attack. Cross-site request forgery (CSRF) is an exploit in which an attacker causes the user-agent of a victim end-user to follow a malicious URI (e.g., provided to the user-agent as a misleading link, image, or redirection) to a trusting server (usually established via the presence of a valid session cookie).
A CSRF attack against the client's redirection URI allows an attacker to inject its own authorization code or access token, which can result in the client using an access token associated with the attacker's protected resources rather than the victim's (e.g., save the victim's bank account information to a protected resource controlled by the attacker).
The client performs an HTTP POST with its parameters as a form-encoded HTTP entity body, passing its client_id and client_secret as an HTTP Basic authorisation header. This HTTP request is made directly between the client and the authorisation server, without involving the browser or resource owner at all.
This separation between different HTTP connections ensures that the client can authenticate itself directly without other components being able to see or manipulate the token request.
The response can also include a refresh token (used to get new access tokens without asking for authorisation again) as well as additional information about the access token, like a hint about the token’s scopes and expiration time.
In Okta, using the authorisation_code grant type also returns an ID token if the openid scope is requested. ID token is a JWT. ID token must be validated before use.
The client is generally the simplest component in an OAuth system, and its responsibilities are largely centered on obtaining tokens from the authorisation server and using tokens at the protected resource. The client doesn’t have to understand the token, nor should it ever need to inspect the token’s contents. Instead, the client uses the token as an opaque string.
Refresh tokens also give the client the ability to down-scope its access. If a client is granted scopes A, B, and C, but it knows that it needs only scope A to make a particular call, it can use the refresh token to request an access token for only scope A.
