OAuth 2.0 Weina Ma Weina.Ma@uoit.ca Agenda OAuth overview Simple - - PowerPoint PPT Presentation

OAuth 2.0

Weina Ma Weina.Ma@uoit.ca

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
• ther 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

– Instead of having their own system of accounts (username/password), some applications rely on other services to verify the identity of users.

• 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. OAuth works similar: a user grants access to an application and the application can only perform the authorized actions

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

• f 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
• wner 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
• f 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,
• btain 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
• n 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