OAuth2.0 in ConnnectionsCloud

Understanding OAuth 2.
0
in IBM Connections Cloud
Contents
Overview..................................................................................................................................................................2
Application registration...........................................................................................................................................3
Flow for third-party data access...............................................................................................................................5
Conclusion.............................................................................................................................................................14
References..............................................................................................................................................................14
© Copyright IBM Corporation, 2016.
Understanding OAuth 2.0 in IBM Connections Cloud

Understanding OAuth 2.0 in IBM Connections Cloud
IBM® Connections Cloud is a security rich, multi-tenant, social business service where customers can
collaborate and socialize with colleagues and guests to get business done. Each user’s log-in identity controls
access to a personalized experience and to social business data.
Third party applications that integrate with IBM Connections Cloud must establish each user’s identity to utilize
the service on behalf of that user. IBM Connections Cloud supports several authentication mechanisms: Basic
Authentication, Open Authorization (OAuth) 1.0a, and Open Authorization (OAuth) 2.0. This document
provides an overview for the preferred mechanism – OAuth 2.0. There are a number of reasons for the
preference for OAuth 2.0:
✔ Eliminates the need for storing username-password pairs
✔ Provides granular control of application access to IBM Connections Cloud
✔ Provides a simpler authorization process than OAuth 1.0a
✔ Works in concert with a federated identity provider (Secure Assertion Markup Language), where Basic
Authentication does not
Overview
The OAuth 2.0 flow is suited for web applications, desktop applications, and third-party extensions. Example
use are project management, electronic signatures, customer relationship management, and innovation
solutions.
To understand the OAuth 2.0 flow, consider the scenario with a courier working on behalf of a customer. This
scenario assumes that Paul is registered with the bank as a trusted courier, and Mike has a bank account. Mike
wants Paul to run an errand for him at the bank. But before Paul can access Paul's bank account, he must be
authorized using the following steps:
1. Mike asks Paul to go to the bank on his behalf.
2. Paul gives Mike his previously registered ID to submit to the Bank.
3. Mike goes to the Bank, proves his own identity, and then submits Paul's ID to register Paul as his courier.
4. Bank confirms with Mike: "Do you want to allow Paul to access your assets?"
5. As Mike trusts Paul, he agrees.
6. Bank grants a temporary code to Mike.
7. Mike passes the temporary code to Paul.
8. Paul immediately goes to the bank to submit the code because the code is short-lived (if Paul waits too long,
the code expires and the process must begin all over again).
9. Bank validates the temporary code submitted by Paul.
10. Bank issues Paul a token that lets him bypass the registration check for the next two hours.
11. Paul accesses Mike's assets. (Note: The Connections Cloud implementation of OAuth 2.0 provides
unlimited access to user resources).
12. Within 2 hours, Paul must renew the token so he can continue to access Mike's assets.
Understanding OAuth 2.0 in IBM Connections Cloud 1

If Fred (another bank customer) hires Paul to be his courier, the entire process must be repeated, because Mike's
code is only valid for accessing Mike's assets.
The following sections in this document explain how the OAuth 2.0 flow works in IBM Connections Cloud:
➔ Application registration explains the process of registering a third-party app with Connections Cloud so that
users can authorize the app to access data on their behalf.
➔ Flow for third-party data access explains the flow for a user to grant access to the application.
Application registration
When a third-party application is integrated with IBM Connections Cloud, customers can "opt in" by registering
the application within their organization, which makes the application available to all users within that
organization. Applications can be registered with organizations in specific geographies (Central Europe,
Americas, or Asia Pacific).
To register a third party-application with IBM Connections Cloud, complete the following steps:
1. Log in to IBM Connections Cloud.
2. In the top navigation bar, click the arrow next to your profile picture and select Account Settings.
3. In the side navigation, click Internal Apps.
4. Click Register App.
5. In the Register App window, provide the application details as explained in Table 1.
Table 1. Application registration fields
Field name Example value Description
App Name Test Application - Paul This field is not used as part of the OAuth 2.0 flow; it is used only
to identify the application in the list of Internal Applications. The
best practice is to include the name of the owner in the
application name, as shown in the example.
App An application to demonstrate Provide an extended description of the third-party application.

Description OAuth2.0 Many customers add details such as date added, date approved,
and key contacts.
Auth Type OAuth 2.0 Indicates the type of authentication used by the application that
you are registering: Basic, OAuth 1.0a, or OAuth 2.0.
Registering an OAuth 2.0 application automatically creates an
OAuth 1.0a application registration as well.
Access Grant 90 Days Specify the life (duration) of the refresh token, in days. You can
Duration set the duration for as many as 90 days, but you might decide to
set a shorter duration for security reasons.
Note the difference between the duration of the access token and
the refresh token:
Access token: Used to call actual APIs and live only about two
hours.

Refresh token: Used to automatically obtain a new access token

without having to restart the OAuth 2.0 flow.
Callback URL https://localhost/call Provide any URL that can be accessed by the application being
back registered. This value must match the callback that is sent to the
authorization URL, described in the next section.
The customer callback URL enables the third-party application to direct to any URL (secure or insecure)
using any protocol (for example, notes:// or myapp://). The OAuth 2.0 flow allows the application to be
public or private, as long as it can connect with IBM Connections Cloud.
Best practice is to use a secure protocol such as https or wss. The callback URL redirects the user back to the
third-party application from IBM Connections Cloud, and includes the short-lived access code as a URL
parameter.
Note: IBM Connections Cloud does not support OAuth scopes, which limit access to data or limit the Read-
Write capabilities of the third-party application.
6. Click OK.
IBM Connections Cloud displays a message stating that the application was registered successfully:
After the application is registered, the OAuth credentials are available. To obtain the credentials, complete the
following steps:
1. Click Account Settings > Internal Apps.
2. Find your application's name (for example, "Test Application - Paul") in the list of Internal Apps.
3. Click application_name > Show Credentials.
4. Click Show Client Secret.
5. Copy the ClientID, Client Secret, and Callback URL values. Example values are shown in Table 2.

Table 2. Example OAuth credentials for an application
ClientID app_20085940_1399482973905 A unique identifier for the application.
Client Secret a133ed0de271c2253e5cfe146c176 A unique key, with a maximum of 256 characters,

5e012dcc1241de29ed7d that is associated with the application.
The client secret never expires, so it should be protected.
If necessary, you can reset the client secret by using the
Reset Credentials option on the "Internal Apps"
window.
Callback URL https://localhost/callbac The callback URL that you provided when you
k registered the application with Connections Cloud.
The third-party application must store its OAuth credentials in a secure location, and treat the information as
confidential data.
Flow for third-party data access

The OAuth 2.0 authorization flow enables a third-party application to obtain, on behalf of a user, access to IBM
Connections Cloud Social Business APIs without requiring access to that user's authentication credentials. The
core of the IBM Connections Cloud OAuth 2.0 flow for a third-party application to access data is as follows:
1. User opens third-party application.
2. Third-party application authenticates user with that person's own credentials for the application.
3. Third-party application redirects user to the authorization URL on IBM Connections Cloud.
4. User authenticates with IBM Connections Cloud using their own Connections Cloud credentials.
5. Third-party application requests permission to access Connections Cloud APIs on behalf of the user.
6. User grants or denies permission:
- If user denies permission, the flow ends here.
- If user grants permission, the flow continues (proceed to step 7).
7. IBM Connections Cloud returns the user to the registered callback URL with a short-lived access code.
8. Third-party application exchanges the short-lived authorization code for a set of user-specific credentials: an
access token and a refresh token.
9. Third-party application stores the access token and refresh token for the user, so that the third-party
application can act on behalf of the user.
10. Third-party application uses the access token to use IBM Connections Cloud APIs.
11. Upon the expiration of the access token, third-party application requests a new access token.
12. Third-party application stores the updated refresh and access tokens.
These steps are explained in more detail below.

Note: The OAuth 2.0 implementation in IBM Connections Cloud is not backwards-compatible with OAuth
1.0a, and is implemented prior to the final 2.0 specification. The main divergence from the current version of
the specification is that Connections Cloud uses the argument callback_uri while the specification uses
redirect_uri (see RFC 6749).
1. User opens third-party application
When the user opens the application, the application presents a panel indicating either that the user must enable
IBM Connections Cloud access for the application, or that the user must set up access to IBM Connections
Cloud.
2. Third-party application authenticates user with that person's own credentials for the application.
The application delegates the authentication to the customer’s identity provider or uses the third-party
application’s own identity provider. The authenticated identity is used to look up the user’s configured access
data. For third parties that do not store access and refresh tokens for the user, the user must execute the entire
OAuth 2.0 flow for each session with the third-party application.
Tip: Third-party developers should use SAML to seamlessly sign on a user with the customer's identity
provider. Generally, the customer stores a secure cookie to quickly authenticate and authorize the user’s log-in
to the third-party application.
3. Third-party application redirects user to the authorization URL on IBM Connections Cloud.
The third-party application redirects the user to the authorization URL with the application's registered values.
The URL must include the parameters listed in Table 3.
Table 3. Parameters in the authorization URL
Parameter name Parameter value
response_type The fixed-value code that signals the generation of a short-lived access code.
client_id The third-party application’s ClientID (from the application's registration)
callback_uri The third-party application’s registered callback URL
The authorization URL is unique for each IBM Connections Cloud environment. If the user logs into the
Americas service (https://apps.na.collabserv.com), the third-party application must be registered with
the organization on the Americas data center. The authorization URL would be
https://apps.na.collabserv.com/manage/oauth2/authorize. Table 4 lists the authorization URLs for
the Connections Cloud environments.
Table 4. Authorization URLs for Connections Cloud environments
Environment Authorization URL
North America https://apps.na.collabserv.com/manage/oauth2/authorize
Europe https://apps.ce.collabserv.com/manage/oauth2/authorize
Asia-Pacific https://apps.ap.collabserv.com/manage/oauth2/authorize
For example, a third-party application calling IBM Connections Cloud with the Americas service would use the
URL https://apps.na.collabserv.com/manage/oauth2/authorize?
response_type=code&client_id=app_example&callback_uri=http://localhost/callback.

The third-party application redirect should be handled with a pop-up window (_blank) or the main Window
(_self). Many third-party application vendors use the _self redirect because _blank now redirects to a new tab
and is often lost among other tabs. IBM Connections Cloud does not support the state parameter, so the
application should store the state in the user’s session.
4. User authenticates with IBM Connections Cloud using their own Connections Cloud credentials.
The user must log in to IBM Connections Cloud using either the customer’s identity provider (IdP) or using
IBM Connections Cloud as the identity provider. To improve security, the user's credentials for the third-party
application should not be the same as that person's credentials for Connections Cloud, unless the same SAML
IdP is used by both.
5. Third-party application requests permission to access Connections Cloud APIs on behalf of the user.
The application displays a message prompting the user to grant or deny access:
6. User grants or denies permission:

The user must respond by choosing whether to grant or deny permission.
- If user denies permission, the flow ends here.
If the user denies access, IBM Connections Cloud returns an oauth_error to the third-party application. For
example, if the resource owner has denied access to a protected resource, the redirect URI includes an
oauth_denied error message using the format:
https://<host_name>/callback?oauth_error=oauth_denied
- If user grants permission, the flow continues.

If the user chooses to always grant access for the application, future redirects are seamless.
For any invalid request, the OAuth 2.0 provider displays one of the error codes and reasons listed in Table 5.
Table 5. OAuth 2.0 Error codes and reasons
Error Type Status Code Error Message and Detail
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 500 oauth_request_failed
ERROR
The OAuth flow failed. Try again or contact the administrator.
7. IBM Connections Cloud returns the user to the registered callback URL with a short-lived access code.
IBM Connections Cloud redirects the user's browser to the callback URL, which includes a unique identifying
code, using the format: https:///callback?code=1236879. The code is short-lived (90 seconds). The third-
party application must convert to a more permanent OAuth credential within that time-frame.
8. Third-party application exchanges the short-lived authorization code for a set of user-specific
credentials: an access token and a refresh token.
To exchanged the short-lived authorization code, the third-party application must make an HTTP GET or HTTP
POST request to the token URL. The request must have the HTTP Header Content-Type set to
application/x-www-form-urlencoded. The request body must be URL-encoded and must contain the
parameters listed in Table 6.
Table 6. URL parameters for a request to exchange a short-lived authorization code
callback_uri The URL for the third-party application’s callback URL:
callback_uri=CALLBACK_URI
client_secret Third-party application client secret:
client_secret=CLIENT_SECRET
client_id Third--pParty application client ID:

client_id=CLIENT_ID
grant-type There is only one allowed value-- authorization_code:
grant_type=authorization_code
code The short-lived access code received by the third-pParty application
code=AUTHORIZATION_CODE
The HTTP GET method uses the Authorization header with OAuth 2.0 instead of the POST body. The values
are added to the authorization header in the following set format:
Authorization: OAuth callback_uri="CALLBACK_URI",client_secret="CLIENT_SECRET",
client_id="CLIENT_ID", grant_type="authorization_code", code="AUTHORIZATION_CODE"
The token URL is unique for each IBM Connections Cloud environment. If the user logs into the Americas
service (https://apps.na.collabserv.com), the third-party application must be registered with the organization on
the Americas data center, and the token URL would be:
https://apps.na.collabserv.com/manage/oauth2/token. Table 7 lists the token URLs for the various
Connections Cloud environments.
Table 7. Token URLs for Connections Cloud environments
Environment Token URL
North America https://apps.na.collabserv.com/manage/oauth2/token
Europe https://apps.ce.collabserv.com/manage/oauth2/token
Asia-Pacific https://apps.ap.collabserv.com/manage/oauth2/token
If the request is successful, the parameters listed in Table 8 are returned in the body of the response, with an
HTTP response code of 200.
Table 8. User-specific authorization data that is returned to the application
access_token The access token that is used as a bearer token to access the protected resource, and is valid
for two hours from time it is granted. The maximum number of characters is 256.
refresh_token A long-lived refresh token that can be used to obtain a new access token when the access
token expires. The maximum number of characters is 256.
Note: The value of the refresh token is confidential and should be protected.
issued_on The details of when the access token was created. The created timestamp is based in epochs.
expires_in The amount of time, in milliseconds, that the access token is valid.
token_type The default value is Bearer.

The application receives a URL-encoded response, such as:
access_token=16c7f772427f367be615ffaefd8293cff73646e246e1d094a63dd914c43b9e3efd848093
78199815886d83a740&refresh_token=5b1e334d4de0b8e39c3dff8fd1c88dc8d9169fdbe7a0759b155d
cd2b3a0479c47f5b&issued_on=1399488937103&expires_in=7200000&token_type=Bearer
For any invalid request, the OAuth 2.0 provider responds to the third-party application with one of the errors
listed in Table 9.
Table 9. OAuth error codes for invalid authorization requests
BAD REQUEST 400 oauth_invalid_parameters: <parameter_list>
Invalid parameters were passed with the request.
BAD REQUEST 400 oauth_unsupported_grant_type
The grant_type parameter passed with the request is not supported in
IBM Connections Cloud. The following grant types are supported: code,
refresh_token, and authorization_code.

The value of the response_type parameter in the request is not set to code.
UNAUTHORIZED 401 oauth_missing_clientsecret
The client_secret parameter is either missing or has a null or empty
value.
UNAUTHORIZED 401 oauth_missing_callbackurl
The callback_uri parameter is either missing or has a null or empty
value in the request.
The Oauth 2.0 credential is not present or was deleted in Connections.
Cloud.
UNAUTHORIZED 401 Callback URI sent with the request is not the same as the one registered
for this Company App

UNAUTHORIZED 401 fail decrypt client secret
The client secret cannot be decrypted.
UNAUTHORIZED 401 Service Component not found
The application associated with the credentials that were passed with the
request cannot be found in Connections Cloud.
UNAUTHORIZED 401 oauth_missing_authorizationcode
The authorization_code parameter is missing from the request.
UNAUTHORIZED 401 oauth_invalid_authorizationcode
The authorization_code parameter is not valid.
UNAUTHORIZED 401 oauth_authorization_code_expired
The authorization code has expired.
UNAUTHORIZED 401 oauth_access_token_expired
The access token has expired.
UNAUTHORIZED 401 refresh token encrypt failure
The refresh token cannot be encrypted.
UNAUTHORIZED 401 fail decrypt refresh token
The refresh token cannot be decrypted.
ERROR
9. Third-party application stores the access token and refresh token for the user, so that the third-party
application can act on behalf of the user
The application should store the OAuth 2.0 response data in a secure data store.
10. Third-party application uses the access token to use IBM Connections Cloud APIs.
The application uses the authorization header with the Bearer value to access the IBM Connections Cloud APIs.
The application should confirm the user’s identity with the given access token using the Authorization Bearer
Token. The getUserIdentity request returns user information such as subscriber ID, customer ID, name, and
email.
URL https://apps.na.collabserv.com/manage/oauth/getUserIdentity
Header Authorization: Bearer
When the third-party application invokes an API request with an expired access token, the error code 401 is
returned with an oauth_access_token_expired error message. After receiving the error message, the application
must use the refresh token to get a new access token.

11. Upon the expiration of the access token, third-party application requests a new access token
The application requests a new token using the access credentials. IBM Connections Cloud supports the token
refresh using HTTP POST or HTTP GET.
The HTTP POST request is Content-Type: application/x-www-form-urlencoded and requires that the input
parameters be URL-encoded.
The HTTP GET request is of the format:
Authorization: OAuth client_secret="", client_id="", grant_type="refresh_token", refresh
token="<refresh_token"
Table 10 lists the input parameters used in the HTTP GET request for a long-lived refresh token.
Table 10. Input parameters for requesting a long-lived refresh token
grant_type Set the value to refresh_token.
client_id The client ID of the third-party application. The client ID is provided at the time the
application is registered.
client_secret The client secret of the third-party application. The client secret is provided at the time the
application is registered. The maximum number of characters is 256.
refresh_token A long-lived refresh token that can be used to obtain a new access token when the access
token expires. The maximum number of characters is 256.
If the request is successful, the parameters listed in Table 11 are returned in the body of the response, with an
HTTP response code of 200.
Table 11. Parameters included in the response to a successful request for a long-lived refresh token
access_token The short-lived access token. The default life span of the token is two hours and the
maximum number of characters is 256.
refresh_token A long-lived refresh token that can be used to obtain a new access token when the current
access token expires. The maximum number of characters is 256.
issued_on The details of when the access token was created.
expires_in The amount of time, in milliseconds, that the access token is valid.
token_type The default value is Bearer.
For any invalid request, the OAuth 2.0 provider responds to the third-party application with one of the error
messages listed in Table 12.

Table 12. Error messages returned when a request fot a long-lived refresh token in invalid
BAD REQUEST 400 oauth_invalid_parameters: <parameter_list>
Invalid parameters were passed with the request.
BAD REQUEST 400 oauth_unsupported_grant_type
The grant_type parameter passed with the request is not supported in
IBM Connections Cloud. The following grant types are supported: code,
refresh_token, and authorization_code.

The value of the response_type parameter in the request is not set to code.
UNAUTHORIZED 401 oauth_missing_clientsecret
The client_secret parameter is either missing or has a null or empty
value.
UNAUTHORIZED 401 oauth_missing_callbackurl
The callback_uri parameter is either missing or has a null or empty
value in the request.
The Oauth 2.0 credential is not present or was deleted in Connections.
Cloud.
UNAUTHORIZED 401 Callback URI sent with the request is not the same as the one registered
for this Company App
UNAUTHORIZED 401 fail decrypt client secret
The client secret cannot be decrypted.
UNAUTHORIZED 401 Service Component not found
The application associated with the credentials that were passed with the
request cannot be found in Connections Cloud.

UNAUTHORIZED 401 oauth_access_token_expired
The access token has expired.
UNAUTHORIZED 401 oauth_consumer_missing_subscription
The user is not subscribed to this application.
FORBIDDEN 403 Oauth 2.0 is not supported at this time
Contact your administrator.
ERROR
12. Third-party application stores the updated refresh and access tokens
The application updates the stored OAuth data for the user (just as it did in step 9). At this point the application
can continue to use the Connections Cloud APIs until the tokens expire (as long as 90 days, depending on how
the user granted access). Long-running tasks, scheduled tasks, and integrations no longer need the user’s direct
authorization to connect with IBM Connections Cloud.
Conclusion
IBM Connections Cloud recommends the use of OAuth 2.0 for authenticating users with third-party
applications. OAuth 2.0 removes the need to store username-password pairs, allows for granular access to data,
and works in concert with SAML authentication.
For more information on using OAuth 2.0 in an application, review the photosharing-java sample code on
GitHub.
References
For developers new to OAuth 2.0, the following links will help you to become familiar with the authorization
flow.
● "About OAuth 2.0" article on the OAuth Community site
● "Developing an IBM SmartCloud for Social Business application" on the IBM developerWorks site
● "Open Authorization" article in the IBM Connections Cloud Developers wiki
● "User Authentication" article in the JavaScript Web Guide section of the Firebase site
● "Obtaining access tokens" article in the Twitter Developer's documentation

Notices
© Copyright 2016. IBM Corporation.
This information was developed for products and services offered in the U.S.A. This material may be available
from IBM in other languages. However, you may be required to own a copy of the product or product version in
that language in order to access it.
IBM may not offer the products, services, or features discussed in this document in other countries. Consult
your local IBM representative for information on the products and services currently available in your area. Any
reference to an IBM product, program, or service is not intended to state or imply that only that IBM product,
program, or service may be used. Any functionally equivalent product, program, or service that does not
infringe any IBM intellectual property right may be used instead. However, it is the user's responsibility to
evaluate and verify the operation of any non-IBM product, program, or service.
IBM may have patents or pending patent applications covering subject matter described in this document. The
furnishing of this document does not grant you any license to these patents. You can send license inquiries, in
writing, to:
IBM Director of Licensing
IBM Corporation
North Castle Drive
Armonk, NY 10504-1785
U.S.A.
The following paragraph does not apply to the United Kingdom or any other country where such provisions are
inconsistent with local law: INTERNATIONAL BUSINESS MACHINES CORPORATION PROVIDES THIS
PUBLICATION "AS IS" WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESS OR IMPLIED,
INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF NON-INFRINGEMENT,
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Some states do not allow disclaimer
of express or implied warranties in certain transactions, therefore, this statement may not apply to you.
This information could include technical inaccuracies or typographical errors. Changes are periodically made to
the information herein; these changes will be incorporated in new editions of the publication. IBM may make
improvements and/or changes in the product(s) and/or the program(s) described in this publication at any time
without notice.
Any references in this information to non-IBM Web sites are provided for convenience only and do not in any
manner serve as an endorsement of those Web sites. The materials at those Web sites are not part of the
materials for this IBM product and use of those Web sites is at your own risk.
IBM may use or distribute any of the information you supply in any way it believes appropriate without
incurring any obligation to you.
Licensees of this program who wish to have information about it for the purpose of enabling: (i) the exchange
of information between independently created programs and other programs (including this one) and (ii) the
mutual use of the information which has been exchanged, should contact:
IBM Director of Licensing
IBM Corporation
North Castle Drive
Armonk, NY 10504-1785
U.S.A.
Such information may be available, subject to appropriate terms and conditions, including in some cases,
payment of a fee.
The licensed program described in this document and all licensed material available for it are provided by IBM
under terms of the IBM Customer Agreement, IBM International Program License Agreement or any equivalent
agreement between us.
All statements regarding IBM's future direction or intent are subject to change or withdrawal without notice,
and represent goals and objectives only.
Trademarks
IBM, the IBM logo, and ibm.com are trademarks or registered trademarks of International Business Machines
Corp., registered in many jurisdictions worldwide. Other product and service names might be trademarks of
IBM or other companies. A current list of IBM trademarks is available on the Web at "Copyright and trademark
information" at www.ibm.com/legal/copytrade.shtml.

OAuth2.0 in ConnnectionsCloud

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

OAuth2.0 in ConnnectionsCloud

Uploaded by

Copyright:

Available Formats

Understanding OAuth 2.

© Copyright IBM Corporation, 2016.

Understanding OAuth 2.0 in IBM Connections Cloud

Understanding OAuth 2.0 in IBM Connections Cloud 1

App An application to demonstrate Provide an extended description of the third-party application.

Understanding OAuth 2.0 in IBM Connections Cloud 2

Refresh token: Used to automatically obtain a new access token

Understanding OAuth 2.0 in IBM Connections Cloud 3

ClientID app_20085940_1399482973905 A unique identifier for the application.

Client Secret a133ed0de271c2253e5cfe146c176 A unique key, with a maximum of 256 characters,

Flow for third-party data access

Understanding OAuth 2.0 in IBM Connections Cloud 4

Understanding OAuth 2.0 in IBM Connections Cloud 5

6. User grants or denies permission:

- If user grants permission, the flow continues.

Understanding OAuth 2.0 in IBM Connections Cloud 6

Understanding OAuth 2.0 in IBM Connections Cloud 7

Understanding OAuth 2.0 in IBM Connections Cloud 8

UNAUTHORIZED 401 oauth_invalid_responsetype

Understanding OAuth 2.0 in IBM Connections Cloud 9

Understanding OAuth 2.0 in IBM Connections Cloud 10

Understanding OAuth 2.0 in IBM Connections Cloud 11

UNAUTHORIZED 401 oauth_invalid_responsetype

Understanding OAuth 2.0 in IBM Connections Cloud 12

Understanding OAuth 2.0 in IBM Connections Cloud 13

You might also like