[Fuente: http://usemoslinux.blogspot.com/2011/07/que-es-oauth-y-por-que-es-importante.html]

Oauth es un estándar abierto que fue lanzado hacia finales de 2007 que define un mecanismo para que una aplicación web (cliente) pueda acceder a la información de un usuario en otra (proveedor) sin tener que informar a la primera del usuario y contraseña.

Imaginemos que queremos programar una aplicación tipo “página de inicio para el usuario”, en la que este pueda añadir sus fotos de Flickr. Para ello utilizaremos el API de Flickr, le pediremos el nombre de usuario y contraseña al usuario y armaremos dicha página. En este tipo de situaciones es en el que Oauth tiene sentido, comunicaciones entre aplicaciones web en la que hay acceso a datos de usuario. La idea es que la aplicación cliente (en este ejemplo nuestra página de inicio) no tenga acceso al nombre de usuario y contraseña del usuario. Dicho de otro modo, Oauth es una metodología para identificación mediante APIs genérica y de implementación gratuita. Si estas cansado de servicios que te piden el usuario de Gmail o Hotmail para proveerte de tal o cual funcionalidad, ya puedes ir viendo por donde puede estar la utilidad de un protocolo como Oauth.

Por supuesto ya hay un montón de estándares cerrados que hacen esto, por ejemplo Google AuthSub o las APIs de Flickr y Facebook, pero la idea tras Oauth es unificar en un estándar abierto de forma que este tipo de comunicaciones entre aplicaciones web (bueno, el cliente puede ser web o de escritorio) no se articulen mediante protocolos propietarios.

Inmediatamente uno piensa en OpenId, pero Oauth no sustituye este estándar para identificación de usuarios, sino que lo complementa. De hecho, los usuarios nunca “ven” nada relacionado con Oauth, situado en el nivel de comunicación entre aplicaciones. De hecho, gran parte de la gracia de Oauth es que el usuario controle a qué datos acceden terceras aplicaciones. Siguiendo con el ejemplo de Flickr, se podría establecer qué tipo de fotos sí y cuáles no desde el servicio proveedor y los clientes no podría obtener nada más.

Como dato curioso, detrás de Oauth están Pownce, Twitter, SixApart, Jaiku, Flickr, Ma.gnolia y Google, entre otros.

Más información en su sitio oficial, que tiene blog.

Fuente: Error500

[Fuente: http://oauth.net/documentation/getting-started/]

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. In the terms of the OAuth specification, the application seeking permission is the consumer, and the application providing the data is the service provider.

OAuth 1.0

The OAuth 1.0 guide covers the protocol as defined by RFC 5849 and includes many corrections and improvements from previous blog posts and the original Beginner’s guide. To stay up to date about all things OAuth, check this page or subscribe.

• Introduction
• History
• Terminology
• Specification Structure
• Protocol Workflow
• Security Framwork
• Authentication

OAuth Core 1.0 (also known as RFC 5849), the community-based specification published on December 4th, 2007, revised June 24th, 2009, and finalized in April 2010 is one of the fastest growing Open Web specifications. It provides a much needed solution for security web APIs without requiring users to share their usernames and passwords.

This guide attempts to explain OAuth by taking a look at its history, architecture, and technical details. It is written primarily for developers looking to implement services offering secure APIs or developers implementing clients using OAuth-protected services.

The OAuth specification has gone through a few complete rewrites. The final revision was made at the end of 2009 as part of the effort to publish OAuth 1.0 as an RFC, which concluded in April 2010 with the publication of RFC 5849. This guide is based on the final edition which changed the document structure and terminology to better align OAuth with HTTP and other web standards.

OAuth 1.0 is being replaced by the new OAuth 2.0 protocol from the IETF. OAuth 2.0 is a large undertaking with many times more participants and industries. OAuth 2.0 is expected to be completed by the end of 2011.

Valet Key for the Web

Many luxury cars come with a valet key. It is a special key you give the parking attendant and unlike your regular key, will only allow the car to be driven a short distance while blocking access to the trunk and the onboard cell phone. Regardless of the restrictions the valet key imposes, the idea is very clever. You give someone limited access to your car with a special key, while using another key to unlock everything else.

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, or a 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 usernames and passwords. Not only does this require exposing user passwords to someone else – often the same passwords used for online banking and other sites – it also provides these application unlimited access to do as they wish. They can do anything, including changing the passwords and lock users out.

OAuth provides a method for users to grant third-party access to their resources without sharing their passwords. It also provides a way to grant limited access (in scope, duration, etc.).

For example, a web user (resource owner) can grant a printing service (client) access to her private photos stored at a photo sharing service (server), without sharing her username and password with the printing service.  Instead, she authenticates directly with the photo sharing service which issues the printing service delegation-specific credentials.

Beyond Client-Server

In the traditional client-server authentication model, the client uses its credentials to access its resources hosted by the server. OAuth introduces a third role to this model: the resource owner. In the OAuth model, the client (which is not the resource owner, but is acting on its behalf) requests access to resources controlled by the resource owner, but hosted by the server.

In order for the client to access resources, it first has to obtain permission from the resource owner.  This permission is expressed in the form of a token and matching shared-secret.  The purpose of the token is to make it unnecessary for the resource owner to share its credentials with the client.  Unlike the resource owner credentials, tokens can be issued with a restricted scope and limited lifetime, and revoked independently.

On the Beaten Path

Taking inspiration from the Microformats community, the OAuth community made an early decision to base the first version of the protocol on well-established practices. OAuth represents the combined wisdom of many proprietary industry protocols, such as Google AuthSub, Yahoo BBAuth, and Flickr API.

Each protocol provides a different method for exchanging user credentials for a token or ticket. OAuth was created by carefully studying each of these protocols, engaging their authors, and extracting the best practices and commonality to support new implementations as well as a smooth transition for existing services to support OAuth.

An area where OAuth is more evolved than some of the other protocols and services is its direct handling of non-website services. OAuth has built-in support for desktop applications, mobile devices, set-top boxes, and of course websites.

OAuth Core 1.0

The OAuth community, to a large extent, emerged out of the OpenID community. Around November 2006, Blaine Cook was investigating adding OpenID support to Twitter, where he served as chief architect. Blaine was also looking for a better authentication method for the Twitter API, one that did not require Twitter users to share their usernames and passwords with third-party applications.

We want something like Flickr Auth / Google AuthSub / Yahoo! BBAuth, but published as an open standard, with common server and client libraries, etc. The trick with OpenID is that the users no longer have passwords, so you can’t use basic auth for API calls without requiring passwords (defeating one of the main points of OpenID) or giving cut-and-paste tokens (which suck).

– Blaine Cook, April 5th, 2007

At the same time, Chris Messina was working together with Larry Halff and the Ma.gnoliateam on integrating OpenID into the Ma.gnolia Dashboard Widgets (the Ma.gnolia service was discontinued in February 2009). Blaine and Chris got in touch in December 2006 and organized a meeting with David Recordon (OpenID co-creator) and others at a Citizen Space OpenID meetup to discuss existing solutions.

After reviewing the existing OpenID functionality and the limitations of its design, as well as existing proprietary protocols, the group came to the conclusion that there was a need for a new open standard for API access control that did not require sharing password and was login-agnostic, allowing technologies such as OpenID to be used with API calls. They called the new initiative OpenAuth (inspired by OpenID).

[It’s about] providing a standard blueprint for these services to follow so that you can substitute any kind of authentication in the middle of accessing a remote web service and have it work — without needing to build specific implementations for each form of authentication. At once it makes a developer’s life easier by cutting down the number of external auth protocols they need to support and it creates a standard user flow for the end user experience (based on the well-established FlickrAuth flow).

– Chris Messina, July 30th, 2007

In April 2007, the OpenAuth Google group was created with a small group of engineers working together to produce a proposal for such an open protocol. It turned out that this problem wasn’t unique to OpenID, with application developers using other services asking for similar solutions. The original group included Blaine Cook, Kellen Elliott-McCrea, Larry Halff, Tara Hunt, Ian McKeller, Chris Messina, and a few others.

On April 16th, 2007, AOL introduced their OpenAuth protocol. The AOL protocol focused on using the AOL login system to authenticate users on other applications (for example, to log into the AIM service using a third-party application). This forced the group to look for a new name, and on May 5th, 2007, the name OAuth was chosen (pronounced oh-auth).

We need to agree on pronunciation — I really could go either way — as in “oath” or, as Blaine always says “Oh-auth”. Oauth is a good, short name and we have the domains (which is tough for 5 letters). I think that it also has a nice double entente where the idea of an “oath” (like a sacred vow) is being made between you and the originating source of data (the “oath” being that your data provider will act on your behalf and only share your data the way you tell it to) and the built-in “auth” aspect signifies to techie folks what this thing is about.

– Chris Messina, July 9th, 2007

In early June 2007, DeWitt Clinton from Google caught wind of the project and expressed his interest in supporting the effort. DeWitt brought the effort to the attention of the Google security team and got Ben Laurie and Jonathan Sergent involved.

On June 10th, 2007, Blaine Cook and Kellen Elliott-McCrea wrote the first outline. It was, as Kellen put it:

Some notes Blaine and I scrawled down tonight. Trying to nail down the “rough consensus” half of “rough consensus and running code“. They may or may not be penetrable.

– Kellen Elliott-McCrea, June 10th, 2007

On June 14th, David Recordon joined the drafting effort. He also met with George FletcherandPraveen Alavilli from AOL to discuss the proposal.

The group met again at the end of June 2007 at FooCamp. In July 2007 after the firstiPhoneDevCamp, which was well attended and the first time OAuth has been discussed in public, it was decided that the time had come to open it up for others to join.

The public OAuth Google group was created on July 10th, and on July 15th, David Recordon took the collection of notes and turned it into the first real specification draft.

Early OAuth Logo Mockups by Chris Messina

As the group opened up during FooCamp and iPhoneDevCamp, and moved to its new list, other contributors joined the effort like Mark Atwood, John Panzer, Eran Sandler, and Brian Slesinsky. On July 26th, the first public draft was published. On August 5th, 2007, Michal Migurski submitted the first OAuth client implementations in PHP and Python, designed to work with the then-private Twitter OAuth API prototype.

On July 27th, 2007, Eran Hammer-Lahav (while a bit odd, I am going to write about myself in the third person for consistency) joined the project and started contributing to the specification, eventually taking over a community chair and editor. On August 21st and 28th, the group met in person at the Twitter office, with a few people dialing in, and worked together to produce the 0.9 draft.

Between July and November 2007, the community published 7 additional drafts. The drafts received growing interest, community feedback and contributions, most notably, the initial specification cleanup by Larry Halff and Todd Sieling, and the document restructuring and transition to the ‘unified flow’ (a single workflow for the three classes of clients – web-based, desktop, and mobile) by Eran Hammer-Lahav.

On December 4th, the OAuth Core 1.0 specification was declared final at the Internet Identity Workshop, beating OpenID 2.0 by one day. Ma.gnolia had the first live production OAuth implementation. On August 26th, 2008, after help from Gabe Wachob and the Yahoo! legal team, all the original contributors to the OAuth specification and their employer executed the OAuth Non-Assert and License agreement, guaranteeing that the specification will continue to be freely available to all implementers.

OAuth Core 1.0 Revision A

On April 15th, 2009, Twitter released a delegated user authentication solution called ‘Sign-in with Twitter’ using the OAuth protocol. Unlike OpenID which provides a federated, vendor-neutral user authentication framework, the OAuth-based approach created a service specific to Twitter (similar to Facebook Connect).

The release triggered a comprehensive security review of the OAuth Core 1.0 protocol since it was being used for a different set of use cases than originally intended. Two days later at Social Web FooCamp, a potential exploit has been identified which affected almost every OAuth implementation. It was the first real test of the community’s ability to address security issuessince the specification has been completed.

The community released its first Security Advisory (2009.1) on April 23rd 2009, and followed with a revised version of the protocol, OAuth Core 1.0 Revision A on June 24th, 2009.

OAuth at the IETF

In May 2008, Mark Nottingham suggested bringing the OAuth work into the IETF. At a Bar BOF at the Vancouver IETF meeting in December 2007, many people expressed an interest in forming a new working group in the area of Web Authentication. Given the progress OAuth has made, it seems like a productive idea to use it to bootstrap such a working group.

In November 2008 with the support of Lisa Dusseault, the IETF Application Area Director, and with the help of Mark and Sam Hartman, the IETF held its first OAuth BOF at the 73rd IETF meeting in Minneapolis, MN. Larry Halff presented a study of the various OAuth use cases and the overall reception was very positive. Shortly after the second OAuth BOF held March 23rd, 2009 at the 74th IETF meeting in San Francisco, CA, the OAuth Working Grouphas been approved.

The OAuth working group was created to standardize the OAuth Core 1.0 protocol, while maintaining as much backward-compatibility as possible – an effort labeled ‘OAuth Core 1.1′. On November 23rd, 2009, Eran Hammer-Lahav proposed to drop work on a 1.1 revision and instead focus on a more significant 2.0 version.

OAuth Core 1.0 RFC Edition

While preparing the OAuth Core 1.0 specification for IETF submission, Eran Hammer-Lahav collected feedback from implementers regarding the readability and errors in the 1.0 specification. On March 9th, 2009, Eran published the OAuth Core 1.0 Editor’s Cut edition – a complete rewrite of the entire specification including many fixes and clarifications.

The Editor’s Cut edition was later incorporated into draft-hammer-oauth, the IETF Internet Draft used as the basis of the OAuth Working Group. In April 2010, the IETF published RFC 5849 as an informational RFC, replacing the OAuth Core 1.0 Revision A specification.

Client, Server, and Resource Owner

OAuth defines three roles:

• client
• server
• resource owner

(nicknamed the OAuth Love Triangle by Leah Culver). These three roles are present in any OAuth transaction; in some cases the client is also the resource owner. The original version of the specification used a different set of terms for these roles: consumer (client), service provider (server), and user (resource owner).
In the traditional client-server authentication model, the client uses its credentials to access its resources hosted on the server. As far as the server is concerned, the shared secret used by the client belongs to the client. The server doesn’t really care where it came from or if the client is acting on behalf of some other entity. As long as the shared secret matches the server’s expectation, the request is processed.

There are many times when the client is acting on behalf of another entity. That entity can be another machine or person. When such a third actor is involved, typically a user interacting with the client, the client is acting on the user’s behalf. In these cases, the client is not accessing its own resource but those of the user – the resource owner.

Instead of using the client’s credentials, the client is using the resource owner’s credentials to make requests – pretending to be the resource owner. User credentials typically include a username or screen-name and a password, but resource owners are not limited to users, they can be any entity controlling the server resources.

The model gets a bit more detailed when the client is a web-based application. In that case, the client is split between a front-end component, usually running within a web browser on the resource owner’s desktop, and a back-end component, running on the client’s server.

The resource owner is interacting with one part of the client application while the server is receiving requests from another part. However, no matter what internal architecture the client uses, it is still acting as a single entity and on behalf of the resource owner.

Protected Resources

A protected resource is a resource stored on (or provided by) the server which requires authentication in order to access it. Protected resources are owned or controlled by the resource owner. Anyone requesting access to a protected resourcemust be authorized to do so by the resource owner (enforced by the server).

A protected resource can be data (photos, documents, contacts), services (posting blog item, transferring funds), or any resource requiring access restrictions. While OAuth can be used with other transport protocols, it is only defined for HTTP(S) resources.

2-Legged, 3-Legged, n-Legged

The number of legs used to describe an OAuth request typically refers to the number of parties involved:

• In the simple OAuth flow: a client, a server, and a resource owner, the flow is described as 3-legged.
• When the client is also the resource owner (that is, acting on behalf of itself), it is described as 2-legged. Additional legs usually mean different things to different people, but in general mean that access is shared by the client with other clients (re-delegation).

Credentials and Tokens

OAuth uses three kinds of credentials: client credentials, temporary credentials, and token credentials. The original version of the specification used a different set of terms for these credentials: consumer key and secret (client credentials), request token and secret (temporary credentials), and access token and secret (token credentials). The specification still uses a parameter name ‘oauth_consumer_key‘ for backwards compatibility.

• The client credentials are used to authenticate the client. This allows the server to collect information about the clients using its services, offer some clients special treatment such as throttling-free access, or provide the resource owner with more information about the clients seeking to access its protected resources. In some cases, the client credentials cannot be trusted and can only be used for informational purposes only, such as in desktop application clients.
• Token credentials are used in place of the resource owner’s username and password. Instead of having the resource owner share its credentials with the client,it authorizes the server to issue a special class of credentials to the client which represent the access grant given to the client by the resource owner.The client uses the token credentials to access the protected resource without having to know the resource owner’s password.
  • Token credentials include a token identifier, usually (but not always) a random string of letters and numbers that is unique, hard to guess, and paired with a secret to protect the token from being used by unauthorized parties. Token credentials are usually limited in scope and duration, and can be revoked at any time by the resource owner without affecting other token credentials issued to other clients.
• The OAuth authorization process also uses a set of temporary credentials which are used to identify the authorization request. In order to accommodate different kind of clients (web-based, desktop, mobile, etc.), the temporary credentials offer additional flexibility and security.

In OAuth 1.0, the secret half of each set of credentials is defined as a symmetric shared secret. This means that both the client and server must have access to the same secret string. However, OAuth supports an RSA-based authentication method which uses an asymmetric client secret. The different credentials are explained in more detailed later on.

The OAuth 1.0 Guide

Specification Structure

Updated on December 26th, 2009

The OAuth specification consists of two parts:

• The first part defines a redirection-based browser process for end-users to authorize client access to their resources. This is done by having the users authenticate directly with the server, instructing the server to provision tokens to the client for use with the authentication method.
• The second part defines a method for making authenticated HTTP requests using two sets of credentials, one identifying the client making the request, and the other identifying the resource owner on whose behalf the request is being made.

The following is an outline of the OAuth 1.0 protocol specification:

1. Introduction – the introduction provides a quick overview of the specification and its objectives. The terminology sub-section defines the terms used and their relation to the HTTP specification (this guide provides a more detailed description). The example sub-section provides a full walk-through, describing a typical use case of a user sharing photos on one site and looking to print them on another.
2. Redirection-Based Authorization – the authorization flow is what most people think of when they talk about OAuth. It is the process in which the user is redirected to the server to provide access. This section describes the three steps used to request and grant access: Obtaining Temporary Credentials, Requesting Resource Owner Authorization, and Obtaining Token Credentials.
3. Authenticated Requests – In order for the client to obtain a set of token credentials and use it to access protected resources, the client must make authenticated HTTP requests. This section describes how the client makes such requests, how the server verifies them, and the various steps and cryptographic options available. Most of this section is dedicated to the construction of the signature base string, the normalized version of the request used for signing.
4. Security Considerations – this often-overlooked section is a must-read for any developer writing client or server code. It provides a comprehensive (but never complete) list of issues which can greatly impact the security properties of any given implementation. Developers should read this list before starting any OAuth related project, and read it at least once more when they are done to review.

Another section worth mentioning is Appendix A which lists the differences from the community edition. While the RFC edition is the same as the OAuth Core 1.0 Revision A specification, some of its clarifications and errata require code changes on both the client and server sides. Developers working on existing implementations should pay close attentions to the variations described.

The OAuth 1.0 Guide

Protocol Workflow

Updated on July 15th, 2011

OAuth se explica mejor con ejemplos de la vida real. En la specification introduction se incluye un ejemplo similar pero se efoca en la sintaxis de las invocaciones HTTP.En este ejemplo mostramos la típica sesión OAuth e incluye las perspectivas tanto del resource owner, el cliente y el servidor. Los websites y personas mencionadas son ficticios.Aqui empieza la historia…

Jane ha vuelto de sus vacaciones en Escocia. Estuvo dos semanas en la isla de Islay. Cuando volvió a casa , Jane quiere compartir algunas de las fotos de sus vacaciones con sus amigos. Jane utiliza Faji , una web de compartir fotos , para compartir las fotos de sus viajes. Se loggea en Faji y sube sus fotos la cuales ella marca como privadas.

Utilizando la terminología OAuth , Jane es el resource owner y Faji el server. Las dos fotos que Jane ha subido a Faji son los recursos protegidos.

Después de compartir sus fotos con algunos amigos que estaban online, Jane quiere compartirlas también con su abuela. Pero su abuela no tiene conexión a internet asi que Jane decide encargar una copias en papel y enviarselas por correo postal a su abuela.Jane utiliza Beppa , un servicio de impresión de fotografías.

Utiljzando la terminología OAuth , Beppa es el cliente. Debido a que Jane marcó las fotos como privadas, Beppa debe utilizar OAuth para conseguir acceso a las fotos que hay que imprimir.

Jane se conecta a beppa.com para encargar sus impresiones. Beppa soporta importar imágenes desde muchas webs de compartir fotos, incluida Faji. Jane selecciona la fuente de donde sacar las fotos y pulsa Siguiente.

Cuando Beppa implementó soporte para importar fotos desde Faji, un programador de Beppa , client developer en terminología OAuth , obtuvo un conjunto de client credentials(client identifier y secret) de Faji para que fueran utilizadas a la hora de atacar el API OAuth de Faji.

En el momento que Jane hace click en Continuar, algo importante sucede en segundo plano entre Beppa y Faji:

• Beppa solicita de Faji un conjunto de credenciales temporales
• En este punto las credenciales temporales no son especificas del resource owner pero son utilizadas por Beppa para conseguir aprobación del resource owner (Jane) para acceder a sus fotos privadas.

Jane pulso Continuar y ahora está esperando alguna respusta en pantalla.

Cuando Beppa recibe las credenciales temporales, redirige a Jane a una Faji OAuth User Authorization URL y le pide a Faji que redirija a Jane de vuelta una vez haya sido concedido el permiso a  http://beppa.com/order.

En este punto Jane ha sido redirigida a Faji y se le solicita que se loggee con su usuario de Faji. OAuth requiere que los servidores primero autentiquen al resource owner, y luego le pidan permiso para conceder acceso al cliente.

Jane se da cuenta que ahora está en una página Faji porque ve la URL del navegador , entonces introduce su usuario y su contraseña.

OAuth permite a Jane conservar su usuario y contraseña privados y no compartirlas con Beppa o ningún otro sitio. En ningún momento Jane introduce sus credenciales en beppa.com.

Después de logarse con éxito enFaji, a Jane se le pide que conceda acceso a Beppa, el cliente. Faji informa a Jane de quien está pidiendo acceso (en este caso Beppa) y el tipo de acceso que pide. Jane puede aprobar o denegar el acceso.

Jane se asegura que es Beppa quien solicita el acceso limitado a lo que necesita Beppa. Ella no quiere dar permiso a Beppa para que cambie sus fotos o hacer cualquier otra cosa. Ella también observa que el permiso que está concediendo es por una hora , lo cual debe ser tiempo suficiente para que Beppa descargue las fotos.

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.

Jane waits for Beppa to present her with her photos fetched from her Faji account.

While Jane waits, 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, in this case Jane’s photos. In the first request, Beppa exchanges the Request Token for an Access Token and in the second (can be multiple requests, one for a list of photos, and a few more to get each photo) request gets the photos.

When Beppa is done, Jane’s browser refreshes to complete the order.

Beppa successfully fetched Jane’s photo. They are presented as thumbnails for her to pick and place her order.

Jane is very impressed how Beppa grabbed her photos without asking for her username and password. She likes what she sees and place the print order.