OAuth protocol simplified

OAuth protocol is an outsourced authentication protocol, masterminded  by the authenticating server. It is different from OpenID or other federated identity protocols in that OAuth accepts only a single set of credentials whereas OpenID accepts multiple sets of credentials (Yahoo id, Google id, etc.). OAuth allows the task of authentication to be performed by the one component that can authenticate the user and is in fact, in charge of it - the authentication server - even though 3rd party components (called clients) request for the authentication.

Once a service becomes a platform, 3rd parties create applications that operate on the platform. These applications need access to protected resources on the platform, which has a set of credentials to authenticate a user. However, creating application-specific credentials to authenticate the user is not optimal - e.g. for each application on the Twitter platform, it is impractical to ask a twitter user to enter application-specific username and password. Alternatively, giving platform credentials to the 3rd party application is not secure either. OAuth addresses this problem by authenticating the user with the platform and allowing the 3rd party application to access the protected resources on behalf of the user.

There are 3 distinct parties involved in the OAuth interaction.

• resource owner - e.g. the end user with credentials on the platform (aka "the server").
• client - e.g. the 3rd party application, which is acting on behalf of the resource owner to access protected resources on the platform ("the server")
• server - protected resource resides here. Additionally, the server can authenticate the resource owner.

Here is a sequence diagram, highlighting the interaction between the parties involved in OAuth:

More details about the interaction:

0. The client ("3rd party application") registers with the server ("platform") and gets a set of credentials to identify itself to the server. This is an out-of-band activity.
1. The user tries to access a protected resource on the server via the client. At this point, the user has not authorized the client to access the resource on its behalf, i.e. the server is unaware of any such authorization.
2. The client identifies itself to the server and includes a callback URI that will be accessed by the user once the user has successfully authenticated itself to the server.
3. The server issues a temporary set of credentials to the client, till the resource owner successfully identifies itself to the server. The temporary credentials are expired at that time.
4. The resource owner's user agent (e.g. "the browser") is redirected to the server along with the temporary token.
5. User's browser connects with the server and hands over the temporary token. It then authenticates itself to the server. Additionally, it authorizes the client to request protected resources on its behalf. It is important to note that this authorization is temporary and can be revoked by the user at any time.
6. Upon successful authentication, the browser is redirected to the callback URL, along with a piece of information called "verifier" that verifies that the user authenticated with the server and authorized the client to access protected resources on its behalf.
7. The user's browser is redirected to the callback URL on the client with the verifier and the client's token. The client now can pass the verifier to the server, so the server knows that the user authorized the client to work on its behalf.
8. The client passes on the verifier along with its temporary credentials to the server.
9. Upon successful verification, the server invalidates the temporary credentials. They are not needed anymore. A more permanent set of credentials will be generated and issued.
10. The new set of credentials are sent back to the client. They identify that the user is authenticated with the server and that user has authorized the client to access protected resources on its behalf.
11. The client now requests access to the protected resource using the new set of credentials.
12. The server grants access to the resource and sends a representation of the resource back to the client.
13. The client sends the resource representation to the end user.

Here are the advantages of OAuth:

• For 3rd party applications operating on a platform, OAuth allows the 3rd party applications to outsource the authentication functionality to the platform.
• The credentials are contained within the platform and not exposed outside.
• Also, there are no application-specific credentials for the resource owner to remember.

All these advantages make for a compelling case for OAuth for platforms.