Understanding OAuth 2.0 and how it works

OAuth is an open authorization protocol, which allows accessing the resources of the resource owner by enabling the client applications on HTTP services such as Google, Facebook, Twitter, GitHub, BitBucket, and a long etc... It allows sharing of resources stored on one site to another site without using user credentials. Username and password tokens are used instead. The access to the resource can be limited by defined and approved scope.

In other words, what actually companies like Twitter, Facebook or Google do is verifying our identity and offering the scoped data to the client's application. So, we can skip the standard registration process and directly login as registered user in just a few clicks.

Basic concepts

The protocol defines following roles for users and applications:

• Resource Owner: the person that owns the data that is to be shared.

• Resource Server: the server hosting the resources (e.g. Facebook).

• Client Application: the application requesting access to the resources on the resource server.

• Authorization Server: the server authorizing the client app to access the resources of the resource owner. The authorization server and the resource server can be the same server.

Based on the application type, clients are assigned to one of the groups below.

• Confidential clients are applications that are able to securely authenticate with the authorization server and keep their registered client secret safe.

• Public clients are unable to use registered client secrets, such as applications running in a browser (e.g. JavaScript) or on a mobile device.

Depending on the type of the client and security characteristics the authorization grant flow may slightly differ. The most common case is covered in the following section.

Authorization

When a client application wants access to the resources of a resource owner, hosted on a resource server, the client application must first obtain an authorization grant. You must register your application with the authorization server associated to the resource server. Typically it's done once through a registration form available on the their website.

Client ID and Client Secret

The authorization server will issue client credentials in the form of a client identifier and a client secret. The credentials are unique on that authorization server.

• The Client ID is a publicly exposed string used by the application to build authorization URLs that are presented to users.

• The Client Secret is a private key used to authenticate the identity of the application to the authorization server.

Authorization grant

The authorization grant is given to a client application by the resource owner, in cooperation with the authorization server associated with the resource server.

More detailed explanation of the steps in the diagram:

1. The resource owner (user) accesses the client's application.

2. Client's application is provided with URL to authorization server such as Google, Facebook, Twitter, etc... The URL contains the client ID to identify the application.

3. The user is redirected to the authorization server and asked to login using the authenticating application (e.g. Google). Then user is asked to confirm the access grant and the scope of the shared data.

4. The authorization server issues an access token and redirects to a specific callback URI.

5. The application requests the resource from the resource server and presents the access token for authentication.

6. Access token is validated against authorization server and the resource server serves the resource to the client's application.

Conclusion

Registering the same personal data over and over on different webs, forums, stores, etc... is a quite common thing. OAuth makes the process easier and allows us to login all those applications with only one account.