Skip to Content
Technical Articles
Author's profile photo Peter Gutsche

Cloud Integration – Inbound HTTP Connections using OAuth Client Credentials Grant

When using basic authentication or client certificate authentication, usually the server (who provides restricted access to some protected resources) grants a client access to these resources.

With OAuth, you can implement an authentication scenario where the resource server (where the protected resources can be accessed) is separated from a dedicated component that is granting access to the protected resources. The latter component is referred to as authorization server. In other words, the authorization server is issuing the access tokens that are required by the client to access the protected resources.

The following figure shows a simple setup of components for implementing an OAuth authorization scenario for the use case that OAuth is used to protect inbound HTTP communication to SAP Cloud Integration (CPI).

In terms of CPI, protected resources are the message processing capabilities represented by an integration flow endpoint.

In this document, we show how you can set up a dedicated authentication scenario using OAuth Client Credentials Grant for HTTTP inbound communication. To keep it simple, we propose the following to quickly set up the scenario:

  • Use the integration flow explained at HTTPS Adapter: Example Integration Flow and make sure that the user associated with the OAuth client is authorized to process the integration flow.
  • To simulate the HTTP client, install Postman.

To learn more about another scenario using the same authentication option, check out the following blog: Part 1 : Secure connectivity (OAuth) to SAP Cloud Platform Integration.

Configure the OAuth Client

In a first step, you register your sender system (HTTP client) as OAuth client.

In SAP BTP cockpit, go to your subaccount and select Security > OAuth and go to the Clients tab.

Choose Register new client to register the sending application as new client (more information: Register an OAuth Client).

Specify the following settings:

Parameter Description
Name Enter any name of choice.
Description Enter any description of choice.
Subscription

Select the entry ending with iflmap.

That way, you make sure to choose the runtime node of the CPI cluster where the integration flow is deployed. The runtime node represents the resource server of our OAuth authentication scenario.

ID An ID is generated. You need this ID to identify the client when requesting the access token.
Authorization Grant Select the option Client Credentials.
Secret Enter a password that you need to notice for later reference when configuring the HTTP client.
Token Lifetime This parameter determines the validity period for the access token. If you delete the default entry of 60 minutes, the token is valid so long until the client requests a new one (see below).

Click Save.

Finally, you need to find out the URL of the token endpoint for a later step (to request the OAuth token). To do that, go to the Branding tab. The desired URL is displayed under OAuth URLs (look for the Token Endpoint entry). The URL has the following form:

https://oauthasservices-<consumer-account>.<landscape host name>/oauth2/api/v1/token

Now, you give the user associated with the OAuth client the permission to call the integration flow.

Go to Security > Authorizations and assign the user with name oauth_client_<client ID> to the role ESBMessaging.send. Alternatively, you can assign a custom role to this user in case you like to make sure that permissions to process messages on the runtime node should be defined per integration flow endpoint.

Get Access Token from Authorization Server

We propose that you use Postman to simulate the HTTP client. Install Postman from https://www.getpostman.com.

First, the HTTP client needs to get the access token from the authorization server.

It is recommended that you request a JSON Web Token (JWT). For more information, see OAuth Client Credentials Grant (Help Portal documentation about the OAuth Client Credentials Grant option for Neo).

  1. In Postman set up a POST HTTPS call to the following address:

    https://oauthasservices-<consumer-account>.<landscape host name>/oauth2/api/v1/token?grant_type=client_credentials&token_format=jwt

    Note that you have already found out the following part of the URL in a previous step:
    https://oauthasservices-<consumer-account>.<landscape host name>/oauth2/api/v1/token

  2. For the POST HTTP request in Postman, specify the following settings: As Authorization choose Basic Auth, as User enter the ID, as Password enter the Secret (you have specified ID and Secret when registering the OAuth client).
  3. Choose Send to execute the request.
  4. As response, you get back the following message:
{
"access_token": "<access token>",
"token_type": "Bearer",
"expires_in": <expiration time>,
"scope": ""
}

Configure the Sender Adapter

Open the integration flow as described at HTTPS Adapter: Example Integration Flow and check that for the sender adapter as Authorization the option User Role is selected and that the role is specified that is also assigned to the user associated with the OAuth client (see above), for example, ESBMessaging.send.

Send a Message to Cloud Integration

In Postman (which simulates your HTTP client or sender system), configure HTTP requests that are addressed to the integration flow endpoint. The settings of the HTTP requests are explained in detail at Send the HTTP Request and Process the Integration Flow.

However, to configure OAuth authentication, do the following different settings (in both requests, the GET and the POST request):

  • As Authorization choose OAuth2.
  • As Access Token, enter the access token retrieved from the previous call to the authorization server.

More Information

Assigned Tags

      9 Comments
      You must be Logged on to comment or reply to a post.
      Author's profile photo frederick dimmer
      frederick dimmer

      Interesting scenario. I believe this should be included in the SCPI help documentation itself.

      Author's profile photo Peter Gutsche
      Peter Gutsche
      Blog Post Author

      hello Frederick, thank you for the feedback! It is a good idea! Indeed, in the meantime, we have enhanced the documentation about inbound connection/authentication options and provide more details, e.g., here for Cloud Foundry: Setting Up OAuth Inbound Authentication with Client Credentials Grant. But I take up your feedback to enrich this with more examples/scenarios.

      We also provide more and more examples with the help documentation, in particular, when you check out the design guidelines section.

      Best regards, Peter

      Author's profile photo Sunny Kapoor
      Sunny Kapoor

      Hi Peter Gutsche,

      This looks like a duplicate blog.

      https://blogs.sap.com/2018/03/12/part-1-secure-connectivity-oauth-to-sap-cloud-platform-integration/

       

       

      Author's profile photo Peter Gutsche
      Peter Gutsche
      Blog Post Author

      Hello Sunny,

      thank you for the hint!
      I have added a link to the blog mentioned by you also in my blog above. So the readers easily find another, enhanced scenario using the same authentication option.

      Best regards

      Peter

      Author's profile photo Dhira Jain
      Dhira Jain

      Hi,

       

      Thanks for blog, how we can add SCOPE in outh details.

       

      Br,

      Dhiraj

      Author's profile photo Philippe Addor
      Philippe Addor

      Hi all,

      If you are still on Neo and would like to use Postman's built-in Oauth 2.0 token fetch capability (instead of fetching the token with a separate Postman request), see my comment in this blog:

      https://blogs.sap.com/2018/03/12/part-1-secure-connectivity-oauth-to-sap-cloud-platform-integration/comment-page-1/#comment-618522

      Br,

      Philippe

      Author's profile photo Leenu Priya
      Leenu Priya

      Hello Peter Gutsche ,

      Thanks for the informative blog.

      Could you please help to acheive the higlighted point below from your blog.

      Go to Security > Authorizations and assign the user with name oauth_client_<client ID> to the role ESBMessaging.send. Alternatively, you can assign a custom role to this user in case you like to make sure that permissions to process messages on the runtime node should be defined per integration flow endpoint.

      Basically we are looking for option to control access to Iflows inbound endpoint with OAUTH.

      Tried creating a custom role in tenant, Created a Oauth client with the custom role assigned and also added the same role in Iflow sender adapter, but it is not working as expected.
      I was still able to hit the Iflow with token generated by any oauth client/secret combination with a different role.

      Thank you much.

      Author's profile photo Peter Gutsche
      Peter Gutsche
      Blog Post Author

      Hello Leenu,

      thank you for your comment! To understand it correctly, you are using SAP Cloud Integration in the Neo environment, right?

      Best regards,

      Peter

      Author's profile photo Leenu Priya
      Leenu Priya

      Hello Peter,

      Yes, you are right.

      Regards,

      Leenu.