X

The Integration blog covers the latest in product updates, best practices, customer stories, and more.

Securely Connect to REST APIs from Oracle Integration Cloud

Oracle REST Adapter provides a comprehensive way for consuming external RESTful APIs including secure APIs. In this blog we will provide an overview of the available methods of consuming protected APIs using the REST Adapter.

Oracle Integration cloud provides a re-usable connection that can be used to specify the security policy for accessing protected APIs. Once configured, users can test, save and complete the connection and use this in integration flows just like any other connection.
 

When a REST Adapter connection is updated with new security credentials, then the change is automatically visible to all the deployed integrations and there is no need to update or re-deploy the integration flows.  The integration developer must ensure that the new security credentials have identical access and privileges to the APIs and Resources being referenced within the integration flow. 
 

Any other change, especially in the co-ordinates for the external REST APIs such as Base URI / URL to Swagger / RAML documents may call for deactivation and reactivation of impacted flows - and in some cases, it would call for re-editing of impacted adapter endpoints. 


The following security policies are supported in Oracle Integration Cloud:

  • Basic Authentication

    HTTP Basic authentication is a simple authentication scheme built into the HTTP protocol. The client sends HTTP requests with the Authorization header that contains the word Basic followed by a space and a base64-encoded string username:password.

    In the REST Adapter, users should select the Basic Authentication security policy and provide the username and password.

    REST Adapter ensures that the credentials are securely stored in a Credentials Store. During API invocation, the adapter will inject a HTTP header along with the request as follows:  

     Authorization: Basic <base64-encoded-value-of-credentials>
     

    The username and password is not validated even if test connection is successful. Integration developers should validate the credentials before using them in this security policy.

     

  • API Key Based Authentication

    In order to consume APIs protected using an API-Key, integration developers should use the API Key Based Authentication security policy.


     

    REST Adapter provides an extensible interface for developers to declaratively define how the API Key needs to be sent as part of the request. During API invocation, the adapter will inject the API-Key as specified in the API Key Usage along with the request.  
     

    The API-key is not validated even if test connection is successful. Integration developers should validate the API-Key before using it in this security policy.


    Please see our detailed blog API-Key Based Authentication: Quickly and Easily for more details on this security policy.
     

  • OAuth Client Credentials

    The client application directly obtains access on its own without the resource owner’s intervention using its Client Id and Client Secret.

    In the REST Adapter, users should select the OAuth Client Credentials security policy and provide the required information.


     

    Test connection will use the provided credentials to obtain an access token from the authorization server. This access token will be securely cached internally and also refreshed when required.

    The REST adapter will procure an access token using the values provided in the security policy as follows:

    curl -X POST -H 'Content-Type: [Auth Request Media Type]' -H "Accept: application/json" -H 'Authorization: Basic {base64#[YOUR_CLIENT_ID]:[YOUR_CLIENT_SECRET]}' -d  ‘{'grant_type=client_credentials&scope=[YOUR_SCOPE]' '[YOUR_ACCESS_TOKEN_URI]'

    During API invocation, the adapter will inject the access token as an authorization header along with the request as follows:   

    Authorization: Bearer <access_token_obtained_using_oauth_client_credentials>
     

     The access token is for a specific scope. The integration developer must ensure that the connection is used to access resources within the same scope.   

    Caution:  The OAuth2 specification deliberately leaves out the exact mechanism for client authentication. Access token attributes and the methods used to access protected resources are also beyond the scope of this specification. As a result, there are many implementations of OAuth2 that cannot be addressed using the standard policy.

    Oracle REST Adapter provides a flexible Custom Two Legged OAuth security policy that can be used with any flavour of OAuth Client Credential configuration. Please see our blog entry to see the details. We will explore this in the later sections.

  • OAuth Resource Owner Password Credentials

    The resource owner password credentials can be used directly as an authorization grant to obtain an access token. Since the resource owner shares its credentials with the client, this policy is used when there is a high degree of trust between the resource owner and the client.

    In the REST Adapter, users can select the Resource Owner Password Credentials security policy and provide the required information.



     

    Test connection will use the provided credentials to obtain an access token from the authorization server. This access token will be securely cached internally and also refreshed when required.

    The REST adapter will procure an access token using the values provided in the security policy as follows:

    curl -X POST -H "Authorization: Basic {base64#[YOUR_CLIENT_ID]:[YOUR_CLIENT_SECRET]}" -H "Content-Type: [Auth Request Media Type]" -d '{"grant_type": "password", "scope": "[YOUR_SCOPE]",    "username": "[USER_NAME]", "password": "[PASSWORD]" }' "[YOUR_ACCESS_TOKEN_URI]"

    During API invocation, the adapter will inject the access token as an authorization header along with the request as follows:   

    Authorization: Bearer <access_token_obtained_using_oauth_ropc>
     

    The access token is for a specific scope. The integration developer must ensure that the connection is used to access resources within the same scope.

    Caution:  The OAuth2 specification deliberately leaves out the exact mechanism for client authentication. Access token attributes and the methods used to access protected resources are also beyond the scope of this specification. As a result, there are many implementations of OAuth2 that cannot be addressed using the standard policy.


    Oracle REST Adapter provides a flexible Custom Two Legged OAuth security policy that can be used with any flavor of OAuth Resource Owner Password Credential configuration. Please see our blog entry to see the details. We will explore this in the later sections.
     

  • OAuth Custom Two Legged Flow

    Custom Two legged security policy provides Oracle Integration Cloud the necessary flexibility to connect with a plurality of OAuth protected services including services protected using OAuth Client Credentials and OAuth Resource Owner Password Credentials flows.

    In the REST Adapter, users should select the OAuth Custom Two Legged Flow security policy and provide the required information.

    Test connection will use the provided credentials to obtain an access token from the authorization server. This access token will be securely cached internally and also refreshed when required.

    Access Token Usage provides an extensible interface for developers to declaratively define how the access token needs to be sent as part of the request. During API invocation, the adapter will inject the access token as specified in the Access Token Usage along with the request.
     

    The access token is for a specific scope. The integration developer must ensure that the connection is used to access resources within the same scope.


    Please see our blog entry describing OAuth Custom Two Legged policy in more details.

  • OAuth Authorization Code Credential

    The authorization code grant is an OAuth flow where the resource owner is required to provide consent before an access token can be granted to the client application.

    In the REST Adapter, users should select the OAuth Authorization Code Credential security policy and provide the required information.


    Once configured, the integration developer can click on provide consent, which will redirect the user to the authorization URL where the resource owner should authenticate with the authorization server and provide consent to the client application. This concludes the OAuth Flow successfully. The integration developer can test, save and complete the connection and use this in integration flows just like any other connection.
     
    Test connection will validate that the provide consent flow was successful and an access token from the authorization server was obtained. This access token will be securely cached internally and also refreshed when required.

    During API invocation, the adapter will inject the access token as an authorization header along with the request as follows:   

    Authorization: Bearer <access_token_obtained_using_code_authorization>
     

    The access token is for a specific scope. The integration developer must ensure that the connection is used to access resources within the same scope.

    Caution:  The OAuth2 specification deliberately leaves out the exact mechanism for client authentication. Access token attributes and the methods used to access protected resources are also beyond the scope of this specification. As a result, there are many implementations of OAuth2 that cannot be addressed using the standard policy.

    Oracle REST Adapter provides a flexible Custom Three Legged OAuth security policy. We will explore this in the next section.
     
  • OAuth Custom Three Legged Flow

    OAuth Custom Three legged security policy provides Oracle Integration Cloud the necessary flexibility to connect with a plurality of OAUTH2 protected services that include a Code Authorization Flow.

    In the REST Adapter, users should select the OAuth Custom Three Legged Flow security policy and provide the required information.


    Once configured, the integration developer can click on provide consent, which will redirect the user to the authorization URL. The resource owner should authenticate with the authorization server and provide consent to the client application. This concludes the OAuth Flow successfully. The integration developer can test, save and complete the connection and use this in integration flows just like any other connection.

     
    Test connection will validate that the provide consent flow was successful and an access token from the authorization server was obtained. Test connection will also validate the provided refresh mechanism by refreshing the access token if specified. The refreshed access token will be securely cached internally and also refreshed when required.

    *Since the provide consent flow requires the resource owner’s intervention, it is recommended that a refresh mechanism is specified so that the access tokens can be refreshed without the resource owner’s intervention at runtime.

    Access Token Usage provides an extensible interface for developers to declaratively define how the access token needs to be sent as part of the request. During API invocation, the adapter will inject the access token as specified in the Access Token Usage along with the request.
     

    The access token is for a specific scope. The integration developer must ensure that the connection is used to access resources within the same scope.

    We will include a detailed entry for describing OAuth Custom Three Legged policy in more details.
     

  • OAuth 1.0 One legged Authentication

    OAuth 1.0a (One-legged) enables a client to make authenticated HTTP requests to gain access to protected resources by using their credentials. The method is designed to include two sets of credentials with each request, one to identify the client, and another to identify the resource owner.  Before a client can make authenticated requests on behalf of the resource owner, it must obtain a token authorized by the resource owner.

    Test connection will only check that the required values are provided.  At runtime these credentials will be used to generate a signed access token. Since authenticated tokens are meant for one-time use only, the generated tokens will not be cached.

    During API invocation, the adapter will inject the access token as an authorization header along with the request as follows:   

    Authorization: OAuth <generated_oauth1.0a_access_token >

    The access token is for a specific scope. The integration developer must ensure that the connection is used to access resources within the same scope.



In today’s connected world, where information is being shared via APIs to external stakeholders and within internal teams, security is a top concern. Most of the service providers provide secure access to their APIs using one of the mechanisms listed above. In this post, we have reviewed how Oracle REST adapter can be used to securely consume these protected services. We will follow this up with detailed accounts of most of the security policies listed above. In particular, the Custom OAuth Policies provide a flexible interface to work with a multitude of OAUTH protected services.

 

Be the first to comment

Comments ( 0 )
Please enter your name.Please provide a valid email address.Please enter a comment.CAPTCHA challenge response provided was incorrect. Please try again.Captcha
Oracle

Integrated Cloud Applications & Platform Services