OAuth 2.0 Concepts

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 registration 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.

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.