The following sections describe Oracle Utilities Adapter authentication capabilities in detail.
This authentication scheme enables external clients to acquire a token that is also sent as part of the request sent to invoke Oracle Utilities application APIs.
The most important step for an application in the OAuth flow is how the application receives an access token (and optionally a refresh token). A grant type is the mechanism used to retrieve the token. OAuth defines several different access grant types that represent different authorization mechanisms.
Applications can request an access token to access protected endpoints in different ways, depending on the type of grant type specified in the Oracle Identity Cloud Service application. A grant is a credential representing the resource owner's authorization to access a protected resource.
The following sections discuss the various grant types and their pros/cons, along with instructions on how to configure the specific grant type.
There are several OAuth 2.0 grant types you can use in Oracle Integration with the Oracle Utilities Adapter. Review the following information to identify the grant type to use for your use case.
|Grant Type||About the Grant Type||Use Cases and Risks|
Resource owner password credential (ROPC)
The resource owner’s password credentials (that is, the user name and password) can be used by the OAuth client directly as an authorization grant to obtain an access token.
The resource owner password credentials grant type is suitable for cases where the resource owner has a trust relationship with the OAuth client.
When using the resource owner password credentials grant, the user provides the credentials (user name and password) directly to the application. The application then uses the credentials to obtain an access token from the OAuth token service.
The resource owner password credentials grant is a grant workflow where the client application, together with its client identifier and secret, sends the user name and password in exchange for an access token. Instead of the user having to log in and approve the authorization request in a web interface, the user can enter the user name and password in the client application user interface directly. This workflow has different security properties than other OAuth workflows. The primary difference is that the user’s password is accessible to the application. This requires a strong trust of the application by the user.
The resource owner password credentials grant has the following characteristics:
In this OAuth flow:
This grant can be used by applications that want to programmatically invoke the integration without any user intervention.
Use this grant only with trusted first-party clients that securely handle user credentials.
Even though this grant type can be used by client applications to acquire an OAuth access token to use for sending the request to invoke an integration in a programmatic manner, Oracle Integration does not recommend the resource owner password credential grant because of the following risks:
The client credentials grant is used when the OAuth client itself owns the data and doesn’t need delegated access from a resource owner. The client credentials grant provides a specific grant flow in which the resource owner (that is, the user) is not involved. When using this grant, the client application requests an access token only with its own credentials (the identifier and secret) or an assertion from the token endpoint and uses the access token on behalf of the client application itself. The token endpoint does not issue a refresh token. This is because refresh tokens are not supported by the client credentials grant. When the access token expires, the client application must request a new access token.
Client credentials have the following characteristics:
In this OAuth flow:
A OAuth client that uses the client credentials grant must have credentials on the authorization server, which means the client must be a confidential client.
With the client credentials grant, the integration server does not know the owner because the client does not need resource owner approval.
This grant flow is best-suited for when a service provider wants to provide some API methods for use by the client application in general, instead of methods that apply to a certain resource owner.