The OAuth 2.0 Authorization Code Flow filter is used to consume OAuth authorization requests. 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).
The OAuth 2.0 Authorization Code Grant flow is as follows:
-
The Web server redirects the user to the API Gateway acting as an Authorization Server to authenticate and authorize the server to access data on their behalf.
-
After the user approves access, the Web server receives a callback with an authorization code.
-
After obtaining the authorization code, the Web server passes back the authorization code to obtain an access token response.
-
After validating the authorization code, the API Gateway passes back a token response to the Web server.
-
After the token is granted, the Web server accesses their data.
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:
The application registry is stored in the following KPS:
Enter the Key Property Store (KPS) in which the application registry is stored.
The application registry contains the applications registered with the Authorization
Server that are permitted access to specific scopes and resources. Defaults to the
example ClientApplicationRegistry, which is available at the following URL:
http://localhost:8089/appregistry/
For more details, see the topic on Key Property Stores.
Validate Scopes:
Select whether to validate the OAuth scopes in the incoming message against the scopes registered in the API Gateway. For example, select Libraries -> OAuth Scopes in the Policy Studio to view the default scopes:
https://localhost:8090/auth/user.photos https://localhost:8090/auth/userinfo.email
Authorize Resource Owner:
Select one of the following:
-
Use internal flow
Uses the internal API Gateway flow to authorize the Resource Owner. This is the default setting.
-
Call this policy
Click the browse button to select a policy to authorize the Resource Owner. You can use the Policy will store subject in selector text box to specify where the policy is stored. Defaults to the
${authentication.subject.id}message attribute. For more details on selectors, see Selecting Configuration Values at Runtime.
Configure the following fields on the this tab:
Cache Authorization Code 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 select to Store in a cache or Store in a database. For more details, see the following topics:
The Purge expired tokens every setting specifies the time interval
in seconds that the database or cache is polled for expired tokens. Defaults to
every 60 seconds.
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
Authz Code Length:
Enter the number of characters in the authorization code. Defaults to 30.
Authz Code Expiry (in secs):
Enter the number of seconds before the authorization code expires. Defaults to
600 (ten minutes).
Configure the following fields on the this tab:
Cache Access Token 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 select to Store in a cache or
Store in a database. For more details, see the following topics:
The Purge expired tokens every setting specifies the time interval
in seconds that the database or cache is polled for expired tokens. Defaults to
every 60 seconds.
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.
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).
The settings on this tab configure service-level monitoring options such as whether the service stores 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 Oracle API Gateway Analytics tool to produce reports on how the service is used.
Monitoring Options
For details on the Monitoring Options fields on this tab, see the Monitoring Options in Set Service Context.
Record Outbound Transactions
Select whether to record outbound message traffic. You can use this setting to override the Record Outbound Transactions setting on the System Settings -> Traffic Monitor screen. This setting is selected by default.
