OAuth is an open standard for authorization that enables client applications to access server resources on behalf of a specific Resource Owner. OAuth also enables Resource Owners (end users) to authorize limited third-party access to their server resources without sharing their credentials.
API Gateway can act as the client application in an OAuth 2.0 scenario, and as such API Gateway can instigate the authorization process, handle redirects, and request OAuth tokens from an authorization server. Received tokens are stored securely and subsequently used to access protected resources on behalf of users. This provides the following benefits:
-
The OAuth client burden is moved to API Gateway
-
The resource owner's credentials are never shared with the client application
-
The access token is never shared with the resource owner's user agent
![[Note]](../common_oracle/images/admon/note.png) |
Note |
|---|---|
|
This document assumes that you are familiar with both the terms and concepts described in the OAuth 2.0 Authorization Framework and the OAuth server features of API Gateway (for more information, see Part 1, “API Gateway as an OAuth server”). |
API Gateway ships with the following features to support OAuth 2.0 client functionality:
-
Provider profiles for defining OAuth service providers and the applications registered therein.
-
A set of preconfigured sample provider profiles for use with Oracle, Google, and Salesforce OAuth services.
-
Storage of received tokens.
-
Support for the following OAuth flows:
-
Authorization Code
-
Resource Owner Password Credentials
-
Client Credentials
-
JWT
-
SAML
Note The implicit grant type is not supported as it is designed to support client applications that do not have a secure server component, and as such it is not applicable for API Gateway acting as an OAuth client.
-
The OAuth 2.0 client is responsible for accessing the OAuth 2.0 protected resources of other servers. Consider the following example workflow, which demonstrates how API Gateway fits the role of OAuth client. This example is similar to the one in the section called “OAuth 2.0 example workflow”, but in this context API Gateway acts as a client, and the service provider is Google.
As an OAuth client API Gateway wants to access the calendar of a local user who maintains a personal account on Google. The user does not want to reveal their Google credentials to API Gateway. This problem can be solved using the example OAuth 2.0 web server flow shown in the following diagram:
Out of band, API Gateway preregisters with Google and obtains a client ID and secret. API Gateway also
registers a callback URL to receive the authorization code from Google when the Resource Owner
authorizes access to their calendar. The application has also requested access to an API
named /google/calendar, which has an OAuth scope of calendar.
The credentials received from Google are added to the Google provider profile using Policy Studio (for more information, see Configure OAuth 2.0 client applications). The provider profile is also configured with the authorization end point and token endpoint of the Google authorization server. The callback URL is also created as an HTTP listener on API Gateway, with a filter for receiving the authorization code.
The steps in the diagram are described as follows:
-
With a User Agent (UA), such as a browser or mobile phone, the user accesses a service defined on API Gateway. This service must access Google on the user's behalf and initiates the authorization flow by redirecting the UA to the authorization endpoint defined in the Google provider profile.
-
After following the redirect the user logs into their Google account and authorizes the application for the requested scope.
Note The user has not shared their Google user name and password with the API Gateway application. At this point, the Resource Owner is no longer involved in the process.
-
The authorization server then redirects the user's UA to the callback URL on API Gateway, along with an authorization code.
-
On receiving the authorization code the API Gateway client application can exchange this short-lived code for an access token. The client application sends another request to the authorization server, this time to the token endpoint, requesting that the code that proves the user has authorized it to access their calendar be exchanged for an access token to be sent on to the API (Resource Server). The authorization server verifies the authorization code and returns an access token. API Gateway then stores the access token in persistent storage.
-
The client application then attaches the access token to the API (Resource Server) requests, and receives the calendar information as requested.
