OAuth 2.

Weina Ma
[email protected]
 Agenda
• OAuth overview
• Simple example
• OAuth protocol workflow
• Server-side web application flow
• Client-side web application flow
 What’s the problem
• As the web grows, more and more sites rely on
distributed services and cloud computing:
– a photo lab printing your Flickr photos,
– a social network using your Google address book to look
for friends
– a multiple services. third-party application utilizing APIs
from multiple services.
• The problem is, in order for these applications to
access user data on other sites, they ask for user
names and passwords.
• This require exposing user passwords to someone else.
• It also provides these application unlimited access to
do as they wish.
 How Oauth was born
• The idea of Yahoo asking for Google user
passwords scared both firms as well as end
users.
 What is OAuth
• OAuth is a protocol that allows a user to grant a
third party limited permission to access a web
application on her behalf, without sharing her
credentials (username and password) with the
third party.
• The third party can be a web application, or any
other application with the capability of invoking a
web browser for the user, such as a desktop
application or an app running on a smart phone.
 OAuth’s Goal
• Website X can
access your
protected data at
API Y
– All without sharing
your password off-
site
– especially when
there isn’t one like
with OpenID
 Terminology
• Authentication
– A process of verifying the identity of a user, knowing that
the user is who they claim to be.
• Federated Authentication
OAuth works similar: a user
– Instead of having their access
grants own system of accounts
to an application
(username/password),
and thesome applications
application rely on other
can only
services to verify the identity of users.
perform the authorized actions
• Authorization
– The process of verifying that a user has the right to
perform some actions, like reading a document or
accessing an email account
• Delegated Authorization
– Grant access to another person or application to perform
actions on your behalf.
 Terminology - Roles
• Resource Server
– The server hosting user-owned resources that are protected by
OAuth.
• Resource Owner
– The user of the application.
– Has the ability to grant access to their owned data.
• Client
– An application making API requests to perform actions on
protected resources.
• Authorization Server
– Get consent from resource owner
– Issue access tokens to clients for accessing protected resources.
 Simple Example
• Jane is back from her Scotland
vacation. She spent 2 weeks on
the island of Islay sampling
Scotch. When she gets back
home, Jane wants to share some
of her vacation photos with her
friends. Jane uses Faji, a photo
sharing site, for sharing journey
photos. She signs into her
faji.com account, and uploads
two photos which she marks
private.
 Simple Example
• Using OAuth terminology, Jane is the resource
owner and Faji the server. The 2 photos Jane
uploaded are the protected resources.
 Simple Example
• After sharing her photos with a few of her online
friends, Jane wants to also share them with her
grandmother. She doesn’t want to share her rare bottle
of Scotch with anyone. But grandma doesn’t have an
internet connection so Jane plans to order prints and
have them mailed to grandma. Being a responsible
person, Jane uses Beppa, an environmentally friendly
photo printing service.
• Using OAuth terminology, Beppa is the client. Since
Jane marked the photos as private, Beppa must use
OAuth to gain access to the photos in order to print
them.
 Simple Example
• Jane visits beppa.com and begins to order prints.
Beppa supports importing images from many
photo sharing sites, including Faji. Jane selects
the photos source and clicks Continue.
 Simple Example
• After Jane clicks Continue, something important
happens in the background between Beppa and
Faji. Beppa requests from Faji a set of temporary
credentials. At this point, the temporary
credentials are not resource-owner-specific, and
can be used by Beppa to gain resource owner
approval from Jane to access her private photos.
 Simple Example
• When Beppa receives the temporary credentials, it
redirects Jane to the Faji OAuth User Authorization URL
with the temporary credentials and asks Faji to redirect
Jane back once approval has been granted.
• Jane has been redirected to Faji and is requested to sign
into the site. OAuth requires that servers first authenticate
the resource owner, and then ask them to grant access to
the client.
 Simple Example
• After successfully logging into Faji, Jane is asked
to grant access to Beppa, the client. Faji informs
Jane of who is requesting access (in this case
Beppa) and the type of access being granted.
Jane can approve or deny access.
 Simple Example
• Once Jane approves the request, Faji marks the temporary
credentials as resource-owner-authorized by Jane. Jane’s
browser is redirected back to Beppa, to the URL previously
provided http://beppa.com/order together with the
temporary credentials identifier. This allows Beppa to know
it can now continue to fetch Jane’s photos.
 Simple Example
• Beppa uses the authorized Request Token and
exchanges it for an Access Token. Request Tokens
are only good for obtaining User approval, while
Access Tokens are used to access Protected
Resources.
 Simple Example
• Beppa successfully fetched Jane’s photo. They
are presented as thumbnails for her to pick
and place her order.
 Basic Steps of OAuth Application
• Register Application
• Obtain an Access Token from the
Authorization Server
• Send Access Token to an API
• Refresh the Access Token (optional)
 Application Registration
• API request is able to be identified after registering.
• Information required to register an OAuth client with
Google:
– Google Account
– Product Name
– Product logon (optional)
– Website URL used for Redirect URIs
• After registration, the developer gets client credentials:
– Client ID
– Client secret
 Client Profiles
• Server-side web application
• Client-side application running in a web
browser
• Native application
 Access Tokens
• The goal of using OAuth is obtaining an OAuth
access token that your application can use to
perform API request on behalf of a user or the
application itself.
 Authorization Flows
• Authorization code
– Code must be exchanged
– Allow to refresh tokens for long-lived access to API
 Authorization Flows
• Implicit grant for browser-based client-side
applications
– Not need for code exchange
– Not allow to refresh token for long-lived access
 Authorization Flows
• Resource owner password-based grant
– For highly-trusted clients like mobile application
– Password is exposed to client, but not stored on
the device.
 Authorization Flows
• Client credentials
– For installed application
– Similar to the flow of Authorization code
– On behalf of themselves (application) rather than
a specific user.
 Authorization Flows
• Device profile
– For devices that do not have build-in web browser or
have limited input options
– Separate access to a computer or device with richer
input capabilities is needed.
• User will first interact with application on the limited device,
obtain an URL and a code from the device
• then switch to a device or computer with richer input
capabilities and launch a browser.
• Once in a browser, the user will navigate to the URL specified
on the device, authenticate, and enter the code.
 Authorization Flows
• SAML bearer assertion profile
– Enable exchanging SAML 2.0 assertion for an
OAuth access token.
– Useful in enterprise environment that already
have SAML authorization servers set up to control
application and data access.
 Server-Side Web Application Flow
• From application developer’s point of view.
• Assume application registration is done
• Step1: Let the user know what you’re doing and
request authorization
 Server-Side Web Application Flow
• Since OAuth flows involves directing your users to
the website of the API provider, let them know in
advance what will happen.
 Server-Side Web Application Flow
• After user initiates the flow, your application need to send
the user’s browser to the OAuth authorization page.
• Get URL for OAuth authorization endpoint in API provider’s
documentation.
• For Google App Engine, the authorization endpoint is at:
– https://your_app_id.appspot.com/_ah/OAuth...
 Server-Side Web Application Flow
• Specify a few query parameters with this link:
– Client_id
– Redirect_url
– Scope
– Response_type
– State
• Specific parameters to Google’s implementation:
– Approval_promt
– Access_type
 Server-Side Web Application Flow
• Error handling – access_denied
• Types of error
– Invalid_request
– Unauthorized_client
– Unsupported_response_type
– Invalid_scope
– Server_error
– Temporarily_unavailable
 Server-Side Web Application Flow
• Step2: Exchange authorization code for an
access token
– When the user has granted access, two parametes
will be included in the redirect back to the web
application:
• Code
• State – be compared against the value generated in
Step 1.
 Server-Side Web Application Flow
• The application needs to exchange the code for an
access token to make API request.
• Parameters need to be passed:
– Code
– Redirect-Uri
– Grant_type
– Client_id
– Client_secret
 Server-Side Web Application Flow
• OAuth access token is returned in a JSON-
encoded response, including:
– access_token
– Token_type
– Expires_in
– Refresh_token
 Server-Side Web Application Flow
• Step3: call the API
 Server-Side Web Application Flow
• Step4:
– Refresh the access token
• Store both token and expire time.
• When making an API call, first check to see if the current
time is greater than the expiration time.
• If so, refresh the token first, instead of waiting for the API
server to reject your request.
– Or obtain a new access token
• “online” access
• Token with limited lifespan
• No refresh token
 Server-Side Web Application Flow
• How can access be revoked?
– User explicitly revoke access through an account
management interface
– User changes password
– Applications are not informed for revoking access.
• OAuth 2.0 extension:
– Tokens can be revoked programmatically.
– Support “callback”
 Client-side web application flow
• From application developer’s point of view.
• OAuth client is running in the browser (using
JavaScript, Flash, etc.)
• Assume application registration is done
 Client-side web application flow
• Step1: Let the user know what you’re doing
and request authorization
 Client-side web application flow
• Step2: parsing the access token from the URL
 Client-side web application flow
• Step3 : call the API
 Client-side web application flow
• Step4: refreshing the access token
– No protocol for refreshing tokens
– Need to request a new access token
– “Immediate” mode is not standardized, but is
supported by some providers, which enables a
new access token to be transparently sent back to
application without prompting the user.
 Client-side web application flow
• How can access be revoked?
– Same with server-side web application