skip to main content
Administering Hybrid Data Pipeline : Configuring Hybrid Data Pipeline to authorize client applications using OAuth 2.0 : OAuth grant flows
  

Try Now

OAuth grant flows

While OAuth 2.0 defines several different grant types, Hybrid Data Pipeline currently supports the following grant flows.
*Authorization grant flow (UI-based): used with server-side applications
*Resource Owner Password credentials grant flow (non-UI based): used with trusted applications, such as those owned by the service itself.

Grant Type: Authorization Code

The authorization code grant type is the most commonly used because it is optimized for server-side applications, where source code is not publicly exposed, and Client Secret confidentiality can be maintained. This is a redirection-based flow, which means that the application must be capable of interacting with the user-agent (i.e. the user's web browser) and receiving API authorization codes that are routed through the user-agent. Now we will describe the authorization code flow:
Step 1: Authorization Code Link
First, the user is given an authorization code link that looks like the following:
https://cloud.hybriddatapipeline.com/
oauth2/authorize?response_type=code&client_id=CLIENT_ID&redirect_uri=CALLBACK_URL&scope=odata
Here is an explanation of the link components:
*https://cloud.hybriddatapipeline.com/oauth2/authorize: the API authorization endpoint
*client_id: The client id of the application in Hybrid Data Pipeline
*redirect_uri: Where the service redirects the user-agent after an authorization code is granted
*response_type: Specifies that your application is requesting an authorization code grant
*scope: Specifies the level of access that the application is requesting. Hybrid Data Pipeline currently supports one high level scope - "Allow data access via OData"
Step 2: User Authorizes Application
When the user clicks the link, they must first log in to the service, to authenticate their identity (unless they are already logged in). Then they will be prompted by the service to authorize or deny the application access to their account. If the user chooses to allow, the grant flow carries on with the next step. If the user chooses to deny, an error message will be displayed, specifying that “User denied OAuth access”.
Step 3: Application Receives Authorization Code
If the user clicks "Authorize Application", the service redirects the user-agent to the application redirect URI, which was specified during the client registration, along with an authorization code. The redirect would look something like this:
https://hybriddatapipeline.com/callback?code=AUTHORIZATION_CODE
Step 4: Application Requests Access Token
The application requests an access token from the API, by passing the authorization code along with authentication details, including the client secret, to the API token endpoint. The parameters are sent in request body as form url encoded. The following is an example of a POST request to Hybrid Data Pipeline's token endpoint.
https://cloud.hybriddatapipeline.com/oauth2/token

POST Call
client_id=CLIENT_ID
client_secret=CLIENT_SECRET
grant_type=authorization_code
code=AUTHORIZATION_CODE
redirect_uri=CALLBACK_URL
Step 5: Application Receives Access Token
If the authorization is valid, the API will send a response containing the access token and a refresh token to the application. The entire response will look something like this:
{
"access_token":"ACCESS_TOKEN",
"token_type":"bearer",
"expires_in":600,
"refresh_token":"REFRESH_TOKEN"
}
The application is now authorized. It may use the token to access the user's account via the API, limited to the scope of access, until the token expires or is revoked. A refresh token can be used to request a new access token if the original access token has expired.

Grant Type: Resource Owner Password Credentials

With the resource owner password credentials grant type, the user provides their service credentials (username and password) directly to the application. The application uses the /oauth2/token endpoint to obtain an access token from the service.
The following details are required in this grant type:
*Client credentials
*grant_type
*scope (included in the request body)
This grant type should only be used with trusted applications since user credentials need to be shared with the client application.
Resource Owner Password Credentials Flow
After the user gives their credentials to the application, the application will then request an access token from the authorization server. To generate the proper OAuth2 token, you need to pass the payload as "application/x-www-form-urlencoded". The POST request must include the user credentials in the request body. The authorization should be set to No Auth before posting the payload.

grant_type:password
scope:api.access.odata
username:<username>
password:<password>
client_id: <clientid>
client_secret:<client secret>
After the user credentials provided are authenticated, the authorization server returns an access token to the application. Now the application is authorized.