Skip to Content

Configuring OAuth 2.0 between SAP Hybris Cloud for Customer and SAP Cloud Platform


This blog describes the steps necessary to configure user-propagation (a.k.a. Single-Sign-On or SSO) between an extension app running on SAP Cloud Platform (SCP) and SAP Hybris Cloud for Customer (C4C) based on the User ID of the user logged in to SCP. (Soon, I will write another blog to show the configuration based on the email address of the user logged in to SCP)

SAP Hybris Cloud for Customer supports OAuth 2.0 SAML Bearer Assertion Flow.

For more up-to-date information on this topic, please refer to this online help page.


  • The OAuth 2.0 based authentication between SCP and C4C requires the same user-id to exist in both SAP Cloud Platform and SAP Hybris Cloud for Customer.
  • In C4C:
    • An OAuth Identity Provider is configured.
    • An OAuth client is registered to be used by the destination created in SCP.
  • In SCP:
    • A destination pointing to the OAuth client registered in C4C.
    • The App uses the destination created in the previous step.

Configuring SAP Hybris Cloud for Customer

Capturing the required information from SAP Cloud Platform

In order to configure the OAuth Identity Provider in C4C, you will need some information from the respective SCP tenant. Hence, in a separate browser window, go to SAP Cloud Platform Cockpit and open Trust under Security.

Then follow the steps below:

  1. Temporarily change the Configuration Type to “Custom”.
  2. Copy “Local Provider Name” to provide as the value for “Issuing Entity Name” while configuring the OAuth 2.0 Identity Provider in C4C.
  3. Copy the text under “Signing Certificate” and save it as a .cer certificate file.

The Certificate file mentioned above should have the following format:

<The text copied from the Signing Certificate box in Trust Management screen in SCP>

Make sure to click on Cancel to discard any changes you might have made in the “Trust Management” screen.

Creating an OAuth Identity Provider

Open Configure OAuth 2.0 Identity Provider under ADMINISTRATOR à COMMON TASKS and click on New OAuth 2.0 Provider.

Then follow the steps below:

  1. Set “Issuing Entity Name” to the value of “Local Provider Name” copied from Trust Management screen in SCP Cockpit.
  2. Set the .cer certificate file created in the previous topic, to “Primary Signing Certificate”.
  3. Marking Email Address in the above screen has no effect. Hence, leave it as is.


After successful configuration, OAuth 2.0 Identity Provider should be listed as active.

Registering an OAuth 2.0 Client



Then follow the steps below:

  1. Client ID is automatically generated.
  2. Enter a value under Client Secret.
  3. Provide a suitable description for your client registration.
  4. Choose the previously defined OAuth 2.0 Identity provider, as the Issuer Name.
  5. By default, OAuth token will be valid for 3600 seconds (i.e. 1 hour). Feel free to change this value, if you need.
  6. Under scope, select the desired value(s). UWC:CC_HOME should work for most.

Configuring SAP Cloud Platform

Capturing the required information from SAP Hybris Cloud for Customer

In C4C, go to ADMINISTRATOR à COMMON TASKS à Configure Single Sign-On. The value under Local Service Provider should be assigned to Audience in the respective SCP destination.

Defining an OAuth 2.0 destination in SAP Cloud Platform

In SAP Cloud Platform, destinations are the ports that allow access to external systems based on various options. Extension apps then refer to these destinations to connect to their desired external systems.

In order to create a new OAuth 2.0 destination pointing to your C4C tenant, in SAP Cloud Platform Cockpit, under Connectivity, choose Destinations. Then, Click on “New Destination”

Following table describes the parameters required for configuring an OAuth 2.0 destination in SCP.

Parameter Value
Name A descriptive name uniquely identifying the newly created destination

OData Service URL


Proxy Type Internet
Authentication OAuth2SAMLBearerAssertion
Audience “Local Service Provider” from C4C SSO Configuration screen
Client Key Generated “Client ID” of the registered OAuth 2.0 Client in C4C
Token Service URL https://my<tenantID>
Token Service User Generated “Client ID” of the registered OAuth 2.0 Client in C4C
Token Service Password “Client Secret” of the registered OAuth 2.0 Client in C4C


Additional Parameter Value
authnContextClassRef urn:none
nameIdFormat urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified
scope Required scope in C4C. E.g. UIWC:CC_HOME


Here is an example for a destination definition named “OAuth2” with standard and additional parameters:

Please note that modifications to an existing destination will take several minutes to take effect. In order to avoid possible issues, you may want to stop your app and restart it before testing your changes in the destination.

As there are several steps, it is rather easy to make mistakes while configuring the OAuth between SCP and C4C. Hence, please take your time in following the steps above.


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

    Great document – with a lot of valuable information.

    You are using SCP as the platform for your extension app – but do you know if the same can be achieved when using Azure as the platform. We are using Azure as IdentityProvider for both the extension app and for C4C (set up as SSO IDP).

    What I would like is when my users are authenticated to the extension app, then the app should be able to extract data via oData from C4C with the user’s credentials without the user having to sign in to C4C.

    The extension app is developed in .net, and used from a browser (IE/Chrome).

    Will this be possible?


    Best regards

    Anders Brødsgaard/Vestas Wind Systems


    • Hi Anders,

      OAuth 2.0 being an industry standard, I don’t see any issue from the C4C side to support your Azure based app. Essentially, when your non-SAP IdP is defined as an OAuth IdP in C4C, and the associated users exist on both systems (C4C and Azure), it should work – assuming that Azure supports OAuth 2.0 SAML Bearer flow.


      • Hi Mustafa,

        Thanks for the reply!

        I need to check up on the Azure capabilities, but according to their documentation “Azure AD supports the OAuth 2.0 and OpenID Connect standards that make extensive use of bearer tokens, including bearer tokens represented as JWTs.”

        I’m not sure how if a JWT token differs from flow SAP is using?




        • Hi Anders,

          JWT and SAML bearer flow are not the same. Please note that if Azure doesn’t provide built-in support for OAuth 2.0 SAML Bearer flow, you can always implement it within your application.

          Please refer to the sample app on C4C OData API Developer’s guide – Possibly, you can also find a .net example on the Internet.




  • Hi Mustafa,

    Thanks for the great article shared!

    I’m newbie learning cloud mechanism and finding solutions for this.

    Currently I’m configuring the OAuth2.0 for consuming C4C Odata from SCP Apps following the same steps provided but encounter the error: Response returned: “401: Unauthorized” when check connection. From my side, notice that the audience url pattern with https://<tenant-id> which is slightly different.

    Also, as mentioned that prerequisites of same user-id have to exist in both C4C and SCP, can you please provide some input on how user-id will be called from html5 apps as we doesn’t provide user-id in the setting?

    Thanks in advance.

    • We also encountered the same error.  We have an S-user in the Cloud Platform and we cannot create a user with the same user ID in C4C.  Do the user ids need to match?




      • We changed the Cloud Elements userid to match the SCP Hana trial account.  Do you have some steps in terms of testing this out?  E.g. from Postman?




        • Hi Jay,

          After the configurations, try to access your Web App. This should take you to the IdP’s login page and after successful login (with the user configured between your app and C4C) to your Web App. If the configuration is correct, your app can make OData calls without additional authentication dialogs. These calls will be made under the same user id authenticated by the IdP.



          • Hi Mustafa,

            I was able to get the application to work with the Basic authentication.  I had to make some slight code changes to make it work.  It looks like the SAP UI5 version update causes some issues but I got past that.

            I created a copy of the application and pointed to the OAuth destination but it did not work.  When I analyze this, I see an error when the application tries to connect to the destination.

            Request URL: https://webidetesting7025003-s**********$metadata
            Request Method: GET
            Status Code: 500 Internal Server Error
            Remote Address:
            Referrer Policy: no-referrer-when-downgrade
            HTTP Status 500 - Internal Server Error







          • Hi Mustafa,

            Here is the SAP UI5 working with Basic Authentication.


            For the copy of the application but pointing to the destination using OAuth 2.0, it errors in the metadata call with HTTP Status 500 – internal server error:

            And here is our destination:









          • Hey Jay Malla,


            I have the same issue when trying to configure my destination to C4C OData with OAuth 2.0. Did you manage to find a solution to the 500 internal server errors?


            Kind regards,

            Jan De Roeck