OAuth 2

OAuth 2 is an authorization framework that enables applications to obtain limited access to user accounts on an HTTP service. It works by delegating user authentication to the service that hosts the user account, and authorizing third-party applications to access the user account. OAuth 2 provides authorization flows for web and desktop applications, and mobile devices.

OAuth 2 facilitates the integration of complementary systems with ONE's platform. For example, one could integrate a Document Management system with logistics.onenetwork.com or integrate a Time Management system with rtvn.onenetwork.com.

OAuth Roles In an OAuth flow, there are three actors:

  1. Resource Owner - The resource owner is the user who authorizes an application to access their account. The application's access to the user's account is limited to the "scope" of the authorization granted (e.g. a specific role's privileges).

  2. Client - The client is the application that wants to access the user's account. Before it may do so, it must be authorized by the user, and the authorization must be validated by the API.

  3. Resource Server / Authorization Server - The resource server hosts the protected user accounts, and the authorization server verifies the identity of the user then issues access tokens to the application. From an application developer's point of view, a service's API fulfills both the resource and authorization server roles. We will refer to both of these roles combined, as the Service or API role.

Abstract Protocol Flow - Now that you have an idea of what the OAuth roles are, let's look at a diagram of how they interact with each other:

Here is a more detailed explanation of the steps in the diagram:

  1. The application requests authorization to access service resources from the user.

  2. If the user authorized the request, the application receives an authorization grant.

  3. The application requests an access token from the authorization server (API) by presenting authentication of its own identity, and the authorization grant.

  4. If the application identity is authenticated and the authorization grant is valid, the authorization server (API) issues an access token to the application. Authorization is complete.

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

  6. If the access token is valid, the resource server (API) serves the resource to the application.

One can potentially use ONE's Platform as a client of OAuth (i.e. making an "outbound" OAuth call), or as a sever for OAuth (i.e. supporting "inbound" calls from clients). These two usecases are supported in the subsequent sections.