Contents
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. For example, a Gmail user could allow LinkedIn or Flickr to have access to their list of contacts without sharing their Gmail username and password.
The Oracle API Gateway can be used as an Authorization Server and as a Resource Server. An Authorization Server issues tokens to client applications on behalf of a Resource Owner for use in authenticating subsequent API calls to the Resource Server. The Resource Server hosts the protected resources, and can accept or respond to protected resource requests using access tokens.
The following diagram shows the main OAuth components:
This guide assumes that you are already familiar with the terms and concepts of The OAuth 2.0 Authorization Framework specification:
The API Gateway uses the following definitions of basic OAuth 2.0 terms:
-
Resource Owner:
An entity capable of granting access to a protected resource. When the resource owner is a person, it is referred to as an end user.
-
Resource Server:
The server hosting the protected resources, and which is capable of accepting and responding to protected resource requests using access tokens. In this case, the API Gateway acts as a gateway implementing the Resource Server that sits in front of the protected resources.
-
Client Application:
A client application making protected requests on behalf of the resource owner and with its authorization.
-
Authorization Server:
The server issuing access tokens to the client application after successfully authenticating the Resource Owner and obtaining authorization. In this case, the API Gateway acts both as the Authorization Server and as the Resource Server.
-
Scope:
Used to control access to the Resource Owner's data when requested by a client application. You can validate the OAuth scopes in the incoming message against the scopes registered in the API Gateway. An example scope is
https://localhost:8090/auth/userinfo.email.
The following diagram shows the roles of the API Gateway as an OAuth 2.0 Resource Server and Authorization Server:
The API Gateway ships with the following features to support OAuth 2.0:
-
Web-based client application registration
-
Generation of authorization codes, access tokens, and refresh tokens
-
Support for the following OAuth flows:
-
Authorization Code
-
Implicit Grant
-
Resource Owner Password Credentials
-
Client Credentials
-
JWT
-
Refresh Token
-
Revoke Token
-
Token Information Service
-
-
Sample client applications for all supported flows
These API Gateway features are explained in the topics that follow.
The API Gateway supports the following authentication flows:
-
OAuth 2.0 Authorization Code Grant (Web Server):
The Web server authentication flow is used by applications that are hosted on a secure server. A critical aspect of the Web server flow is that the server must be able to protect the issued client application's secret.
-
OAuth 2.0 Implicit Grant (User-Agent):
The user-agent authentication flow is used by client applications residing in the user's device. This could be implemented in a browser using a scripting language such as JavaScript or Flash. These client applications cannot keep the client application secret confidential.
-
OAuth 2.0 Resource Owner Password Credentials:
This username-password authentication flow can be used when the client application already has the Resource Owner's credentials.
-
OAuth 2.0 Client Credentials:
This username-password flow is used when the client application needs to directly access its own resources on the Resource Server. Only the client application's credentials are used in this flow. The Resource Owner's credentials are not required.
-
OAuth 2.0 JWT:
This flow is similar to OAuth 2.0 Client Credentials. A JSON Web Token (JWT) is a JSON-based security token encoding that enables identity and security information to be shared across security domains.
-
OAuth 2.0 Refresh Token:
After the client application has been authorized for access, it can use a refresh token to get a new access token. This is only done after the consumer already has received an access token using the Authorization Code Grant or Resource Owner Password Credentials flow.
-
OAuth 2.0 Revoke Token:
A revoke token request causes the removal of the client application permissions associated with the particular token to access the end-user's protected resources.
-
OAuth 2.0 Token Information Service:
The OAuth Token Info service responds to requests for information on a specified OAuth 2.0 access token.
For more details on the API Gateway OAuth 2.0 support, see the following topics:
For more details on OAuth 2.0, see The OAuth 2.0 Authorization Framework:
