Copyright © Cloud Software Group, Inc. All Rights Reserved

Overview

The OAuth 2.0 framework enables a third party application to access private data to which a user has granted permission. OAuth 2.0 is an open standard for authorization that allows a third party application user to share data from a site that owns data, without exposing any credentials to the application that is being accessed. TIBCO API Exchange Gateway supports the OAuth 2.0 framework.

The OAuth 2.0 Authorization Framework specification can be found at the following location:

https://tools.ietf.org/html/draft-ietf-oauth-v2-31

Capabilities of the OAuth Server

The OAuth server has the following features:

•	Register client application using TIBCO API Exchange Manager.

•	Support the following standard OAuth flows. See OAuth Flows.

−	Authorization Code

−	Password Credential

−	Client Credential

•	Generate authorization code.

•	Generate access tokens from the OAuth flows.

•	Provide APIs to manage access tokens. See the following APIs:

−	Authorization API

−	Token Request API

−	Token Validation API

•	Provide the interface to build custom (non-default) adapters to plug in your implementations of the owner, client, and scope adapters. See OAuth Service Provider Interface chapter.

OAuth Client Policies

TIBCO API Exchange Gateway supports the OAuth client policies for authentication and credential mapping. See Security Policies chapter for details on the OAuth client policies.

OAuth 2.0 Concepts

The OAuth server uses the following concepts from the OAuth 2.0 framework. Refer to the following link for details:

https://tools.ietf.org/html/draft-ietf-oauth-v2-31

Resource Owner

A resource owner is an entity capable of granting access to a protected resource. When the resource owner is a person, this is referred to as an end-user.

Client

A client is an application making protected resource requests on behalf of the resource owner, which are authorized by the owner.

Client ID

A client ID is a unique identifier issued to the client by authorization server during the registeration process.

Client Secret

A client secret is a password for the client. This should be kept confidential.

Authorization Server

An authorization server issues access tokens to the client after authenticating the resource owner successfully and after obtaining authorization.

Resource Server

A resource server hosts the protected resources and responds to the requests to access the protected resources using access tokens.

Authorization Code

The authorization code is obtained from an authorization server when the resource owner grants the client access to the resource.

Access Token

Access tokens are credentials used to access the protected resources.

Refresh Token

Refresh tokens are credentials used to refresh the access tokens.

Authorization Endpoint

The authorization endpoint is the endpoint on the authorization server where the client requests for authorization. The request is redirected to allow the resource owner to log in and grant authorization to the client.

Token Endpoint

The token request endpoint is the endpoint on authorization server where the client requests for access token. This includes exchanging an authorization code for an access token or refreshing access token with a refresh token.

Redirect Endpoint

The redirect endpoint is the endpoint in the client application where the authorization server redirects to after the resource owner grants authorization to the client application. The client receives an authorization code which can be used to exchange for an access token.

Example Scenario

For example, a client application can access an API from the TIBCO API Exchange Gateway as long as the owner of the API allows the application to do so.

The following figure illustrates this example scenario.

Figure 27 OAuth Server Overview

 

The OAuth process flow for the above example is explained as follows:

•	A user goes to a website hosting an application that displays some data from APIs on the gateway.

•	Before the application accesses the APIs on the gateway, the application requests an access token from an authorization server.

•	In the process of obtaining the access token, the user is asked to login and grant the application to the data that the application wishes to access.

•	After the user logs in and grants access, the application receives an authorization code, which is exchanged to obtain an access token.

•	The application uses the received access token to access the APIs on the gateway.

Benefits of using the OAuth Server

The OAuth server uses pluggable adapters for the following purposes:

•	Authenticate owners

•	Authenticate and authorize clients access

•	Retrieve scopes for resources

The use of pluggable adapters enables the OAuth server to provide core OAuth2 capability such that the OAuth server can delegate the authentication and authorization for specific domain to pluggable adapters.

For example, the OAuth server can authenticate the resource owners from LDAP, database, or from any third party identity provider using owner adapters. The OAuth server can authorize resources with a scope that manage the resources for a specific domain. The resources are authorized based on the scope of resources for a specific owner.

Copyright © Cloud Software Group, Inc. All Rights Reserved