Differences between OAuth 1.0a and 2.0 in IBM Connections Cloud
Added by IBM contributorIBM | Edited by IBM contributorAlex Leiskau on February 19, 2015
Rate this article 1 starsRate this article 2 starsRate this article 3 starsRate this article 4 starsRate this article 5 stars

Connections Cloud supports both Open Authorization (OAuth) 1.0a and 2.0. The main usage differences are listed here.

A callback URL is required when registering applications

When registering an application, you must provide a callback URL. The callback URL provides an additional level of security so that the redirect URI that comes with each new request can be verified against the callback URL. This security component is important because Connections Cloud sends the authorization code and other confidential and sensitive information to this callback URL.

Note: Connections Cloud supports only secure HTTPS-based callback URLs.

Consumer key and consumer secret are now client ID and client secret

OAuth 1.0a credential components called consumer key and consumer secret are now called client ID and client secret in OAuth 2.0. Also, the client secret that is shared with external applications is no longer encrypted.

A request token is no longer required

The step for obtaining a request token in the OAuth 1.0a web server flow is no longer required in the OAuth 2.0 web server flow. An authorized request token in OAuth 1.0a is referred to as a verifier code. In OAuth 2.0, the verifier code is called an authorization code.

Client secret, authorization code, and tokens are no longer encrypted

The client secret, authorization code, access token, and refresh token are no longer encrypted before they are shared with external applications. Access tokens are treated as bearer tokens in OAuth 2.0, and the signing of requests is no longer required when accessing protected resources.

Long-lived refresh tokens are now available

OAuth 2.0 supports refresh tokens that can live as long as 90 days. When an access token expires, you can use the refresh token to obtain the new access token without requiring users to grant access to resources again. Access tokens typically live only about two hours.

New App Developer role for managing Internal Apps

Connections Cloud now supports a new App Developer role for managing internal applications (Internal Apps) within an organization. Before this support was added, only users with Customer Service Representative (CSR) and Customer Administrator roles could manage tasks.

Note: The new App Developer role is not new in OAuth 2.0. However, Connections Cloud did not support the role with earlier iterations.

Support for configuring duration of access grants

Users with either Customer Administrator or App Developer roles can now configure the duration of access grants. The duration that is configured applies to all users and resource owners who want to interact with protected resources on Connections Cloud using the company or internal application that is being registered or updated. After the duration is set, resource owners can use their refresh token for that duration only.

Parent topic: Open Authorization