OAuth 2.0

Monday 18th of November 2013 09:41:11 AM


  Toggle Advanced Options



OAuth 2.0 Terminology

  • Authentication: the process of verifying the identity of a user — knowing that the user is who they claim to be.
  • Federated authentication: relying on other services to verify the identity of users.
  • Authorization: the process of verifying that a user has the right to perform some action (typically, this first requires valid identification of the user, i.e., authentication, in order to check whether the actual user is authorized)
  • Delegated authorization: granting access to another person or application to perform actions on your behalf.
  • Roles
    • Resource server: the server hosting user-owned resources that are protected by OAuth. This is typically an API provider that holds and protects data such as photos, videos, etcetera.
    • Resource owner; typically the user of an application, the resource owner has the ability to grant access to their own data hosted on the resource server.
    • Client: an application making API requests to perform actions on protected resources on behalf of the resource owner and with its authorization.
    • Authorization server: the authorization server gets consent from the resource owner and issues access tokens to clients for accessing protected resources hosted by a resource server.

OAuth protocol flow


Client profiles

  • Server-side web application
  • Client-side application running in a web browser

Access tokens

Whether you're building a server-side web application, client-side web application, or a native application, the end goal of using OAuth is the same: you’re trying to obtain an OAuth access token that your application can use to perform API requests on behalf of a user or the application itself.

After obtaining an access token, the token can be sent along with your requests in one of several ways. The preferred method of authorizing requests is by sending the access token in a HTTP Authorization header:

  • GET /tasks/v1/lists/@default/tasks HTTP/1.1
  • Host: www.googleapis.com
  • Authorization: Bearer ya29.AHES6ZSzX

The Authorization header is the preferred mechanism because:

  • The header is rarely logged by proxy servers and web server access logs
  • The header is almost never cached
  • The header doesn’t get stored in the browser cache when making requests from the client

Authorization flows

  • Authorization code
  • Implicit grant for browser-based client-side applications
  • Resource owner password-based grant
  • Client credentials



Comments

Acknowledgement@13-11-18 10:55:22 by Brett Kromkamp

The above is a summary from the book "Getting Started with OAuth 2.0" (http://shop.oreilly.com/product/0636920021810.do).






Google