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.
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 own system of accounts grants access to an application (username/password), some applications rely on other and the application 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.
Recommend
More recommend
