Oracle® Fusion Middleware
Access Token Using Authorization Code

The OAuth 2.0 Access Token using Authorization Code filter is used to get a new access token using the authorization code. This supports the OAuth 2.0 Authorization Code Grant or Web server authentication flow, which is used by applications that are hosted on a secure server. A critical aspect of this flow is that the server must be able to protect the issued client application's secret. For more details on supported OAuth flows, see API Gateway OAuth 2.0 Authentication Flows.

OAuth access tokens are used to grant access to specific resources in an HTTP service for a specific period of time (for example, photos on a photo sharing website). This enables users to grant third-party applications access to their resources without sharing all of their data and access permissions. An OAuth access token can be sent to the Resource Server to access the protected resources of the Resource Owner (user). This token is a string that denotes a specific scope, lifetime, and other access attributes.

Configure the following fields on this tab:

Use this store to validate the Authorization Code:

Click the browse button to select the store in which to validate the authorization code (for example, in the default Authz Code Store). To add a store, right-click Authorization Code Stores, and select Add Authorization Code Store. You can store codes in a cache, in a relational database, or in an embedded Cassandra database. For more details, see the section called “Managing Access Tokens and Authorization Codes”.

Find client application information from message:

Select one of the following:

Configure the following fields on the this tab:

Access Token will be stored here:

Click the browse button to select where to store the access token (for example, in the default OAuth Access Token Store). To add an access token store, right-click Access Token Stores, and select Add Access Token Store. You can store tokens in a cache, in a relational database, or in an embedded Cassandra database. For more details, see the section called “Managing Access Tokens and Authorization Codes”.

Access Token Expiry (in secs):

Enter the number of seconds before the access token expires. Defaults to 3600 (one hour).

Access Token Length:

Enter the number of characters in the access token. Defaults to 54.

Access Token Type:

Enter the access token type. This provides the client with information required to use the access token to make a protected resource request. The client cannot use an access token if it does not understand the token type. Defaults to Bearer.

Include Refresh Token:

Select whether to include a refresh token. This is a token issued by the Authorization Server to the client that can be used to obtain a new access token. This setting is selected by default.

Refresh Token Expiry (in secs):

When Include Refresh Token is selected, enter the number of seconds before the refresh token expires. Defaults to 43200 (twelve hours).

Refresh Token Length:

When Include Refresh Token is selected, enter the number of characters in the refresh token. Defaults to 46.

Store additional Access Token parameters:

Click Add to store additional access token parameters, and enter the Name and Value in the dialog (for example, Department, Engineering).

The settings on this tab configure service-level monitoring options such as whether to store usage metrics data to a database. This information can be used by the web-based API Gateway Manager tool to display service use, and by the API Gateway Analytics tool to produce reports on how the service is used. For details on the fields on this tab, see the section called “Monitoring” in OAuth Access Token Information.