OAuth

Basic concept

OAuth is an open standard to authorization. OAuth provides client applications a secure delegated access to server resources. OAuth 2.0 defines four roles:

• Resource Owner - An entity capable of granting access to a protected resource. When the resource owner is a person, it is referred to as an end-user.
• Resource Server - The server hosting the protected resources, capable of accepting and responding to protected resource requests using access tokens.
• Client - An application making protected resource requests on behalf of the resource owner and with its authorization. The term "client" does not imply any particular implementation characteristics (e.g., whether the application executes on a server, a desktop, or other devices).
• Authorization Server - The server issuing access tokens to the client after successfully authenticating the resource owner and obtaining authorization.

Protocol flow

            +--------+                               +---------------+
            |        |--(A)- Authorization Request ->|   Resource    |
            |        |                               |     Owner     |
            |        |<-(B)-- Authorization Grant ---|               |
            |        |                               +---------------+
            |        |
            |        |                               +---------------+
            |        |--(C)-- Authorization Grant -->| Authorization |
            | Client |                               |     Server    |
            |        |<-(D)----- Access Token -------|               |
            |        |                               +---------------+
            |        |
            |        |                               +---------------+
            |        |--(E)----- Access Token ------>|    Resource   |
            |        |                               |     Server    |
            |        |<-(F)--- Protected Resource ---|               |
            +--------+                               +---------------+
      

Source: RFC 6749

Developer-friendly explanation

Many services such as Facebook, Github, and Google have already deployed OAuth 2 servers, and deployed implementations. Before you can begin the OAuth process you must first register a new app with the service (Google, Facebook etc.). When registering a new app, you usually fill some basic information such as application name, website, logo etc. In addition you must register an URI used for redirecting users within web server, browsed-based, or mobile apps.

After registering your app, you will receive a client ID and a client secret. The client ID is considered public information, and is used to build login URLs, or included in Javascript source code on a page. The client secret must be kept confidential. If a deployed app cannot keep the secret confidential, such as Javascript or native apps, then the secret is not used.

The first step of OAuth 2 is to get authorization from the user. For browser-based or mobile apps, this is usually accomplished by displaying an interface provided by the service to the user. Web server apps are the most common type of application you encounter when dealing with OAuth servers. Web apps are written in a server-side language and run on a server where the source code of the application is not available to the public. You must prepare valid "Log in" link sending to the user. After clicking you will see something like an authorization prompt with question similar to "An application would like to connect to your account...allow app access? DENY/ALOW". If user clicks "Allow", the service redirects the user back to your site with an auth code. After that your server exchanges the auth code for an access token. Server replies with an access token and that's all. As long as token is up to date you can use your app.