4. Wikipedia
_"OAuth is an open standard for authorization. It
allows users to share their private resources (e.g.
photos, videos, contact lists) stored on one site
with another site without having to hand out their
credentials, typically supplying username and
password tokens instead. Each token grants access
to a specific site (e.g., a video editing site) for
specific resources (e.g., just videos from a
specific album) and for a defined duration (e.g.,
the next 2 hours). This allows a user to grant a
third party site access to their information stored
with another service provider, without sharing
their access permissions or the full extent of
their data."_
Source: Wikipedia
5. Authorization
_"The process of authorization is distinct from
that of authentication. Whereas authentication is
the process of verifying that "you are who you say
you are", authorization is the process of verifying
that "you are permitted to do what you are trying
to do". Authorization thus presupposes
authentication."_
Source: Wikipedia
6. Origin
OAuth started in November 2006
when Twitter looked into attaching
OpenID (decentralized
authentication) to their public
API. Discussions concluded _"that
there were no open standards for
API access delegation."_
10. Users
From a user standpoint OAuth provides a way of using
applications without giving away the personal username and
password to service providers. Facebook Apps are probably the
most recognized example of OAuth applications. The user:
Starts the client application
If not already done, authorizes the request
OAuth also allows for scoping by listing the privileges that
an application will get if the user authorizes the request.
E.g. read your email, post as you...
It is up to the user to authorize the entire scope (all
privileges), or to not authorize the request.
11. Developers
From an app developer perspective, the flow is something like this:
Create an account at the Service Provider
Register your client application at the Service Provider
The Service Provider provides a client id and client secret:
CLIENT ID: a8427e34273a4aeea67792e34d020771
CLIENT SECRET: 9b3b93a9c08f400cb066c8848d0b4bad
When you want data from the Service Provider, you make a request to
the service using your client id:
curl https://api.instagram.com/v1/media/popular?
client_id=a8427e34273a4aeea67792e34d020771
The command above uses the media/popular endpoint and the provided
client_id to get JSON data about popular media.
12. Scoping
Which data that is accessible only by
authenticating with a client id is determined by
the Service Provider.
Instagram: _"For the most part, Instagram’s API
only requires the use of a client_id. A client_id
simply associates your server, script, or program
with a specific application. However, some requests
require authentication - specifically requests made
on behalf of a user."_
Making API calls on behalf of an Instagram user
requires an access token.
13. Access tokens
The only way for a client application to obtain an access
token is to have the user authorize the application with the
provided scope (granting privileges).
The process starts with a client application request to the an
authorization server, providing client id, secret and a
redirect url. The server appends the code and redirects to an
authorization dialog.
If the user is not logged in, he or she will be asked to
authenticate
If the user has not authorized the application he or she
will be asked to do so
The user is then redirected to the redirection url provided in
the first request.
Here two things can happen...
14. Server side or Implicit
Either the redirection url leads to a server controlled by the client
application developer that takes the provided code parameter and
exchanges it for an access token by posting the code to an access
token url. This is referred to as the server side flow.
or
The access token is appended as a fragment in the redirection URL.
This method allows applications without any server component to
receive an access_token with ease. It is used by my demo application
and is being referred to as the implicit flow.
A user can at any time explicitly revoke an authorization and render
the obtained access token useless. Some Service Providers, such as
Facebook, also invalidate access tokens after a certain time.
22. OAuth 2.0
_"OAuth 2.0 is the next evolution of the OAuth protocol and is not
backward compatible with OAuth 1.0. OAuth 2.0 focuses on client
developer simplicity while providing specific authorization flows for
web applications, desktop applications, mobile phones, and living
room devices. The specification is being developed[2] within the IETF
OAuth WG and was expected to be finalized by the end of 2010
according to Eran Hammer.[3] However, due to discording views about
the evolution of OAuth, Hammer left the working group[4]"_
_"Facebook's new Graph API only supports OAuth 2.0 and is the largest
implementation of the emerging standard.[5] As of 2011, both
Google[6] and Microsoft[7] had added OAuth 2.0 experimental support
to their APIs."_
Source: Wikipedia
23. Critique
_"When compared with OAuth 1.0, the 2.0 specification is more
complex, less interoperable, less useful, more incomplete, and most
importantly, less secure."_
Eran Hammer one of the leaders of the effort describes how he, and
OAuth, failed. [OAuth 2.0 and the Road to Hell]
_"At the core of the problem is the strong and unbridgeable conflict
between the web and the enterprise worlds. The OAuth working group at
the IETF started with strong web presence. But as the work dragged on
(and on) past its first year, those web folks left along with every
member of the original 1.0 community. The group that was left was
largely all enterprise… and me."_
Source: [OAuth 2.0 and the Road to Hell](http://hueniverse.com/
2012/07/oauth-2-0-and-the-road-to-hell/), July, 2012
24. Service Providers ...
Dropbox Instagram
Facebook Microsoft
Flickr LinkedIn
Foursquare Netflix
Github Tumblr
Google Twitter
