Contents
The OAuth 2.0 Authorize Transaction filter is used to authorize the Resource Owner and grant (allow/deny) client access to the resources. This supports the OAuth 2.0 Authorization Code Grant or Web server authentication flow, which is used by applications 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. The Web server flow is suitable for clients capable of interacting with the end-user’s user-agent (typically a Web browser), and capable of receiving incoming requests from the Authorization Server (acting as an HTTP server).
For more details on supported OAuth flows, see API Gateway OAuth 2.0 authentication flows.
Configure the following fields on the Validation/Templates tab:
HTML Templates:
Specify the following templates for HTML forms:
-
Login Form:
Enter the full path to the HTML form that the Resource Owner can use to log in. Defaults to the following:
${environment.VDISTDIR}/samples/oauth/templates/login.html -
Authorization Form:
Enter the full path to the HTML form that the Resource Owner can use to grant (allow/deny) client access to the resources. Defaults to the following:
${environment.VDISTDIR}/samples/oauth/templates/requestAccess.html
VDISTDIR specifies the directory in which the API Gateway is installed.
Configure the following fields on the Authz Code Details tab:
Authorization Code will be stored here:
Click the browse button to select where to cache the access token (for example,
in the default Authz Code Store). To add an access token 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 “Manage access tokens and authorization codes”.
Location of Access Code redirect page:
Enter the full path to the HTML page used for the access code HTTP redirect. Defaults to the following:
${environment.VDISTDIR}/samples/oauth/templates/showAccessCode.html
Length:
Enter the number of characters in the authorization code. Defaults to 30.
Expiry (in secs):
Enter the number of seconds before the authorization code expires. Defaults to
600 (ten minutes).
Additional parameters to store for this Authorization Code:
If you wish to store additional metadata with the authorization code, click
Add, and enter the Name and Value
in the dialog (for example, Department and Engineering).
When additional data is set, it is then available in the Access Token using
Authorization Code filter when the authorization code is exchanged for an
access token. You can also specify the fields in this table using selectors. For
more details, see the API Gateway User Guide.
![[Note]](../common_oracle/images/admon/note.png) |
Note |
|---|---|
|
If you entered parameters for the authorization code and parameters for the access
token, the data will be merged. Data in the Access Token using Authorization
Code filter may overwrite parameters stored with the authorization code. For
example, if you set |
Configure the following fields on the Access Token Details tab:
Access Token will be stored here:
Click the browse button to select where to cache 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 “Manage access tokens and authorization codes”.
Expiry (in secs):
Enter the number of seconds before the access token expires. Defaults to
3600 (one hour).
Length:
Enter the number of characters in the access token. Defaults to 54.
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.
Additional parameters to store for this Access Token:
Click Add to store additional access token parameters, and enter
the Name and Value in the dialog (for example,
Department, Engineering).
Generate Token Scopes:
When requesting a token from the Authorization Server, you can specify a parameter for the OAuth scopes that you wish to access. When scopes are sent in the request, you can select whether the access token is generated only if the scopes in the request match all or any scopes registered for the application. Alternatively, for extra flexibility you can get the scopes by calling out to a policy.
Select one of the following options to configure how access tokens are generated based on specified scopes:
-
Get scopes from a registered application:
Select whether the scopes must match Any or All of the scopes registered for the application in the Client Application Registry. Defaults to Any. If no scopes are sent in the request, the token is generated with the scopes registered for the application.
-
Get scopes by calling policy:
Select a pre-configured policy to get the scopes, and enter the attribute that stores the scopes in the Scopes approved for token are stored in the attribute textbox. Defaults to
scopes.for.token. The configured filter requires the scopes as set of strings on the message whiteboard.
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 settings” in Get access token information.
