Step 2: Obtain authorization code
Added by IBM contributorIBM | Edited by IBM contributorAlex Leiskau on February 20, 2015
Rate this article 1 starsRate this article 2 starsRate this article 3 starsRate this article 4 starsRate this article 5 stars

The authorization check is a browser based operation in which resource owners log in and grant application access to their IBM Connections Cloud™ data.
After access is granted, the authorization server returns an authorization code by appending it to the redirect URI that was registered as a callback URL in Step 1: Register the application. The authorization code is exchanged for the access and refresh tokens in the next step in the web server flow.

Obtain authorization code

Note: If the resource owner selects Always grant application name access and do not show this message, the grant access window does not show again unless the resource owner resets the access.

API details

If you want to obtain authorization via the API, you can make an HTTP GET call to following URI:


The following parameters are required:

Table 1. Input parameters
Set the value as code.
The client ID of your application. This ID is provided at the time the application is registered.
Set the value as the URI to redirect the user to after approval. The value must match the value in the Callback URL field when registering the company application.

Example URI<callback_uri>&client_id=<client_id>&response_type=code

If the resource owner has granted access, and the call is successful, the newly generated authorization code is appended to the redirect URI:


If the resource owner has denied access to the protected resource, the redirect URI includes an oauth_denied error message:


Response codes and messages

Successful requests return a 200 response code. If your request is unsuccessful, refer to the following error codes and explanations:

BAD REQUEST (400): oauth_absent_parameters: <parameter_list>
The <parameter_list> parameters must be included in the request.
BAD REQUEST (400): oauth_duplicated_parameters: <parameter_list>
Duplicate parameters were passed with the request.
BAD REQUEST (400): oauth_unsupported_parameters: <parameter_list>
Unsupported parameters were passed with the request.
BAD REQUEST (400): oauth_invalid_parameters:response_type=invalidValue
The value of the response_type parameter contains invalid characters. Invalid characters include commas (,) and spaces.
UNAUTHORIZED (401): oauth_invalid_responsetype
The value of the response_type parameter in the request is not set to code.
UNAUTHORIZED (401): oauth_invalid_clientid
The client_id parameter is not valid.
UNAUTHORIZED (401): Callback URI sent with the request is not the same as the one registered for this Company App
The callback_uri parameter that was sent with the request is not the same as the value that is registered for this application.
UNAUTHORIZED (401): oauth_consumer_missing_subscription
The user is not subscribed to this application.
INTERNAL SERVER ERROR (500): oauth_request_failed
The OAuth flow failed. Try again or contact the administrator.
Parent topic: OAuth 2.0 APIs for web server flow
Previous topic: Step 1: Register the application
Next topic: Step 3: Exchange authorization code for access and refresh tokens