Skip to Content
Author's profile photo Neha Soni

Create a destination to access a CF oData/service secured with oAuth2

This blog explains how a service deployed in CF can be accessed using a destination. For now, destinations can only be created in Neo. The destination in Neo will enable you to make the service/oData accessible through full stack webIDE. You should make sure that you are using the webIDE from the Neo account (not trial) and not from Canary. If you use full stack webIDE from CF, you will not be able to see the destination.

The service/oData exposed can be used to create UI application/Smart Template application as well as CAP full stack application.

First step which you need to do for creating a destination for a service/oData deployed in CF (protected by oAuth2), is to configure the trust between Neo and CF account. If you do not configure this, you will still be able to create the destination, but it will return 401 when you try to access the service/oData. If the service/oData is not secured, then you do not need to configure the trust.

Steps to configure the trust between Neo and CF: –

• Get admin rights on CF and Neo along with security admin rights. You should be able to see the security tab in the left side. Please note that being an administrator alone does not make you security admin.

• Go to the Neo sub account -> Security -> Trust -> Local Service Provider -> Edit -> Choose Configuration type as ‘Custom’ -> Change the name to an alphanumeric value (less than 15 characters) -> Save the file -> Click ‘get metadata’-> Append at the first line in the file -> Replace all the occurrences of SPSSO to IDPSSO -> Save the file.


• Revert the change in the Neo account to Configuration type ‘Default’ and save it.

• Go to the CF sub account -> Security -> Trust Configuration -> Upload the metadata file (downloaded from Neo account)-> Save. Once the metadata is uploaded (on save), all the fields will be filled automatically.

• You should be able to see the new trust configuration in the list in the CF account.


After establishing the trust between the Neo and CF account. You can create a destination in Neo account.

There are two ways in which a destination can be created.

1. From Neo full stack webIDE.

If your use case is to create a full stack application from webIDE then it is better to create the destination also from webIDE itself. This will help you save the effort you have to do to fill all the fields while creating the destination manually.
• Create an MTA project.
• File-> New->Project From Template -> Select Multi-Target Application -> Fill in the application name->Finish.
• Right click on the created project->New->HTML5 Module->Select the Template->Fill in the Basic Information Section->Select ‘Service URL’ in Data connection section->Click on ‘Create a New Destination’.

• Provide a name and description for the destination. Make sure you have provided correct username/password (can result in 500 internal server error). Select the Org, Space and the application which is exposing the oData. Click “Ok”. This will create a new destination in Neo account. You can verify it by checking the destinations in the Neo account.


• If the destination is created successfully, you can see it in the dropdown in the ‘Data connection’ tab.

• Provide the relative path (the URL can be checked in the destination created in Neo account. Adding the relative path to this URL should result in list of all the entities). Click on ‘Test’ should result in showing the entities from your service.

• You can select the entity and proceed with the project creation. The destination will be registered in the manifest file of the project.

2. Manually in the Neo account using destination tab in the left panel.

• Click on Destination -> New Destination -> Select ‘oAuth2SAMLBearerAssertion’ from Authentication dropdown ->Fill other details of the service (URL, Client Id, Client Key etc) for which you want to create the destination.


• Note that you can get the details like client key, Token service user, Token service password from the xsuaa (from vcap services) of your service. Token URL will be the URL which you use to access your service (when using postman). You might need to append ‘alias/sap-icbs.canary’ to the token URL when you create it manually.

Below is the details for the fields in destination creation.

o URL – URL of the service which is to be exposed via destination.
o Client Key – This is nothing but the client secret from the xsuaa of the service.
o Token Service URL – the URL to get the token for the service.
o Token Service User – This is the client id from the xsuaa.
o Token Service Password – This is the again the client secret from the xsuaa.

You will need to add few additional properties to the destination. This will make it available in the webIDE.

o TrustAll – True
o WebIDEEnabled – True
o WebIDESystem – CF
o WebIDEUsage – odata_gen


Please see the below blogs for more details about SAP Cloud Application Programming Model :-

Assigned Tags

      You must be Logged on to comment or reply to a post.
      Author's profile photo Manu Gupta
      Manu Gupta

      Hi Neha ,

      Nice blog. I followed the steps you described to create destination for my Odata service v4 which is deployed on CF and protected by oAuth using webide on Neo account. But if I check connection to created destination , it gives 401 unauthorised while I already maintained trust between NEO and CF. And if I try to use this destination for data connection while creating app template using webide it gives 403 response.Any help to get this resolved would be must appreciated.

      I have one doubt as well that Is it possible for UI app to communicate with Odata service app using destination if -

      1- Both are bind with different service instance of UAA ?

      2- Both are secured with different approuter ?


      Author's profile photo Neha Soni
      Neha Soni
      Blog Post Author

      Hi Manu,

      As per the example given by Fiori in CF, I have followed the approach of having two applications - one for the UI and another one having the service.

      Both of them are bound to two different instances of uaa. This is working.

      For UI, you will need an 'application' plan of the uaa, which in case of the service would be 'broker'. This is the end to end token flow from UI to service. When I had started the token flow, it was not completed by central team. But now this has been completed and i need to resume the topic.

      Maybe you could share the application and I can have a look that why it is giving 403 while creating the UI. If the trust is configured, ideally the UI should be able to access the destination.



      Author's profile photo Nikolai Angelov
      Nikolai Angelov

      Hello Neha,

      I tried to setup the destination according to the blog

      I think there might have been some changes in the process on trust configuration. Are these steps still relevant:  “Append at the first line in the file -> Replace all the occurrences of SPSSO to IDPSSO”?

      It is also not clear for me what should be the values for “Token Service URL” and “Audience”.

      Best regards

      Nikolai Angelov

      Author's profile photo Marc Mauri
      Marc Mauri

      Hi Nikolai Angelov ,

      did you get any answer for your questions? I have the same questions as you.

      Neha Soni , your answer will also be welcome ?

      Thanks in advance.

      Best regards,


      Author's profile photo Neha Soni
      Neha Soni
      Blog Post Author

      Hi Nikolai Angelov , Hi Marc Mauri,


      Sorry for the late reply. This blog is was written when Cloud Application Programming Model was in early phase. Many of the things might be outdated. I suggest you check out the documentation for Cloud Application Programming Model.