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 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.
Website X can access your protected data at API Y All without sharing your password offsite especially when there isn t one like with OpenID OAuth s Goal
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 grants their access own system to an application of accounts (username/password), and the some application applications can only rely on other 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 JSONencoded 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