Skip to Content
Product Information

SAP Cloud Integration – OAuth2 Client Credentials Support in OData V2 Adapter


SAP Cloud Integration version 2.43.x comes with enhancement in OData V2 receiver adapter with support of OAuth2 Client Credentials. If you have an OData V2 endpoint to consume, with OAuth2 Client Credentials grant type authentication, you can invoke it.

This blog describes about the new enhancement.

OAuth2 Client ID and Client Secrete

The consumption of this feature starts with registering a client with OAuth2 token service provider. Since different applications have different way of registering the OAuth2 client, I will not be covering on how to register it. But, the outcome of any OAuth2 client registration process is that you get a client ID and client secrete along with an optional scope information.

OAuth2 Security Artifact Deployment

You need to deploy the OAuth2 security artifact before consuming this information in the OData V2 receiver adapter. Below steps describe on how to deploy OAuth2 security credentials.

  1. In your SAP Cloud Integration Web UI, click on Monitoring -> Manage Security ->Security Materials -> Add -> OAuth2 Credentials. Sample screenshot below


This opens the OAuth2 credentials dialog window as below

Parameters information:

  1. Name: Any name of your choice, this is also called as alias, to be used in the Credential Name field of OData V2 receiver adapter.
  2. Grant Type: Select the grant type. Two grant types available
    1. Client Credentials
    2. OAuth2SAMLBearerAssertion
  3. Select Client Credentials grant type for our scenario
  4. Authentication URL: Provide the URL of OAuth2 token server which shall generate the token and returns it.
  5. Client ID: Client ID of registered OAuth2 client
  6. Client Secret: Client Secret of registered OAuth2 client
  7. Client Authentication: Two values available. Based on the way OAuth2 token service requires the client ID and secret to be sent as part of request, select the one relevant
    1. Send as Body Parameter: Sends client ID and secret as request body in JSON format
    2. Send as Request Header: Sends the client ID and secret as part of the request header
  8. Scope information: If your OAuth2 token service requires scope to be sent, the select the check box of Include Scope
    1. Scope: The scope information
    2. Content Type: One of the two values to be selected
      1. application/json: In case of scope is in json format
      2. application/x-www-form-urlencoded: In case of scope is in x-www-form-urlencoded format

Click on Deploy button


Design Integration Flow

Steps of complete design of integration flow shall be excluded as the expectation is that you know how to design the integration flow in SAP Cloud Integration already.

Consider the below integration flow with OData V2 receiver adapter.

In the OData V2 receiver adapter, the Authentication drop-down control has a new entry for OAuth2 Client Credentials. Select this option. In the Credential Name field, provide the name, i.e. alias what you have used at the time of deploying the OAuth2 Client Credentials security artifact (cover under the section OAuth2 Security Artifact Deployment). When the message processing starts, the OData V2 runtime adapter reads the alias, gets the client ID and secret, makes an HTTP request call to OAuth2 token service URL – along with scope if provided – and upon receiving the OAuth2 token, OData V2 runtime adapter sets this token to Authorization bearer header and invokes the OData V2 endpoint provided in the Address field.

You must be Logged on to comment or reply to a post.
  • Hi Deepak

    Thanks for the very informative blog. Does the OData adapter support OAuth for inbound messages? Can you share some information on this.

    Best Regards

    Muhammad Ahmed


    • Hi Sriram,

      The Address field (of OData V2 outbound connector properties) should have the OData V2 service root endpoint. It is not the OAuth2 token service URL.

      OAuth2 token service URL should be part of the credential deployment dialog, and should be part of Authentication URL field of the dialog. And we will correct the UI label from 'Authentication URL' to 'Token Service URL'

      I hope this answers your question.




  • Hi Deepak,

    is there a way to use grant_type or any other key / value in Manage Security Material for OAuth2 credentials? Typically for grant_type values such as  “client_credentials” or “password”, etc. would be really nice to have, as these are usually mandatory for OAuth 2.0.

    So we do not have to follow posts like this :

    thank you in advance for your answer.



    • Hi Marek,

      Sorry for the very late reply, somehow I missed your comment.

      Are you looking for a generic key/value pair persistence? For OAuth2 client credentials, I think the current dialog for OAuth2 for deployment of client ID and client secrete would be sufficient.




      • Thanks I would also believe it was.


        We have some issues with exactly that, maybe we're doing something wrong, we have a hard time trying to debug it.


        I would expect grant_type=client_credentials to be passed in the request body.

        With cUrl it would look like:

        curl -X POST -H "Authorization: Basic [base64 usename:password]" -H "content-type: application/x-www-form-urlencoded" -H "Accept: application/json" -d "grant_type=client_credentials" https://......./oauth2/token

  • Hi Deepak

    We have tried "Send as Request Header", and it still does not work.

    Then also checking "Include Scopes", adding a blank/space as scope value (we do not utilize scopes) - then it seems to work.

    This behavior is rather strange?

    Best Regards


    • Hi,

      Even I have tried many ways to use the oauth 2(as body,as header, as json, as url) - by declaring in security materials .. However I am not able to get this work. I have noticed the below error in log. , why it is missing the authorization in header if we mention authentication as Oauth2 client credentials?

      I have implemented oauth2 token generation / bearer token inside flow and called my actual url and it worked without issues....

      Seems some limitation / wrong type of execution / configuration is occurring when we consider oauth2 via security material artifact ? Do we have any mock endpoint / interceptor where we can see the headers / data which is being passed to the URL from http channel and can we monitor how the token call is taking place?




    • Hi Morten,

      Thanks for the update.

      Setting the drop-down entry to Send as Request Header is expected to work.

      I am not able to relate this with selecting include scopes and adding a blank/space as scope value.

      Nevertheless, I am in touch with development team to crosscheck this behaviour and will update you.




  • Dear Deepak

    Thanks for responding to the forum!

    Just have a query, lets say a Bearer Token is configured to be valid for 60 minutes, once CPI fetch the token value, can you please suggest if CPI automatically caches the valid token value till 60 mins or each time the iflow is executed, a call is made to token bearer OAUTH API irrespective of 60 mins duration?

    Sample scenario:

    Step 1: Source system sends 10 Records

    Step 2: SAP CPI needs to sends the data to target system by performing a Request Reply call for each record (via OAUTH credentials configured in Request-Reply Channel)

    Step 3: Enrich the content with the source data

    Step 4: Delivery message to target system with 10 enriched records

    Many Thanks!

    Vijay Devulapalli

    • Hi Vijay,

      As of now, OAuth2 token caching is not done.

      But, we are currently working on to support the OAuth2 caching.

      I will update this blog once the token caching mechanism in introduced.




      • Thanks Deepak for your prompt response.

        As caching is the key to avoid the number of API calls within the bearer token time limit, this would really help considering the performance impacts.

        Waiting for the update 🙂

        Thank you!

        Vijay Devulapalli

  • hi,

    • is there a document explaining the difference between OAuth vs OAuth2?
    • is OAuth2 now the recommended method for CPI ?
    • Does this also support SOAP Adapter on CPI ? I have seen on other threads that it does not but these threads were 2 years old
    • Hi Chandrakanth,

      • From SAP Cloud Platform Integration perspective, we provide documentation on the product, and for the difference between OAuth and OAuth2, you need to check on the specifications of OAuth online.
      • It depends on your integration scenario from CPI to outbound connectivity. If your backend supports OAuth2, then it is recommended over Basic Authentication.
      • As of now, there is not support for SOAP outbound adapter in CPI. Do you have such a scenario to connect to SOAP backend from CPI with OAuth2 authentication?




  • Hi Deepak,

    We followed the steps you provided above but the third party system mentioned that we still have the 401 error because there is no bearer/authorization. Can you please help on what else do we need to setup? Thanks!