Skip to Content
Technical Articles
Author's profile photo Dayana Pankova

OAuth 2.0 Authentication for SAP PI/PO REST Sender Channel

With NetWeaver 7.50 SP25, SAP PO/PI REST adapter provides support for OAuth 2.0 authentication on Sender side based on RFC 6749 “The OAuth 2.0 Authorization Framework” ( ).  This allows REST clients which support OAuth 2.0 Client Credentials grants flow to authenticate and access REST resources provided by the SAP PO/PI REST Adapter.

This blog post provides a detailed description and sample scenario of OAuth 2.0 for REST Sender channel in SAP Process Integration/Process Orchestration.


This feature has been introduced with SAP NetWeaver 7.50 SP25. The system must be on SP25 or higher. Details can be found in SAP Note 3140397 and SAP Note 3163712


SAP PO/PI REST Adapter authentication flow for OAuth 2.0

The following diagram provides information on the exact flow of OAuth 2.0 in the PO/PI REST Sender:


Diagram of the OAuth 2.0 functionality in the PO/PI REST Sender Channel


      0. Register user – a client has to be registered using the REST OAuth Server User Interface. It is accessible in the SAP NetWeaver Administrator -> SOA -> Monitoring  -> REST OAuth Server. At this stage the Client ID, Client Secret and Scope parameters are registered.

  1. In your REST client you can configure fetching the OAuth Access token by calling the Authorization server URL – http://<host>:<port>/RESTAdapter/OAuthServer

with the following parameters:

grant_type – client_credentials

client_id – the one registered on step 0.

client_secret – generated from step 0.

scope (optional) – the channel name, for which access token will be requested. If omitted, applies to all channel for which this client is assigned during step 0.

  1. You can now make a POST HTTP request to the REST Sender channel using the acquired access token from the previous step – the token should be sent as an HTTP header:

Authorization: Bearer <access_token>

  1. REST OAuth Login module is automatically configured for the sender channels with enabled OAuth 2.0 authentication. This login module requests access token validation and receives mapped NetWeaver user from the REST OAuth Authorization server.
  2. REST OAuth Login module perform authentication with the received NetWeaver user.
  3. The request is passed to the SAP PI REST adapter.

Sample Scenario and Step-by-Step Configuration

At this section we will go through the required configuration from start to finish and create a sample scenario together.

  1. Create a REST Sender channel with OAuth 2.0 enabled.

The PO/PI REST Sender channel(s) must be created, activated and started in PO Channel Monitoring with OAuth 2.0 enabled in the REST Sender channel.

The first step is to create a REST Sender channel and enable OAuth 2.0 by selecting the Enable OAuth 2.0 Authentication for incoming requests checkbox. Then we need to select the OAuth 2.0 Grant Type – currently only the Client Credentials Grant is being supported so this is what we select. Save and activate the channel.

Disclaimer: Please note that the channel and its endpoint are created for testing purposes only and are sample values. The actual endpoint should be as the customer scenario requires.

Snapshot of PO Testing System – configuring REST Sender channel

  1. Register a client in the REST OAuth Server User Interface

For this step we need to go to http://[host]:[port]/nwa to open the SAP NetWeaver Administrator

From there, we need to navigate to SOA -> Monitoring -> REST OAuth Server -> Clients and click on Create Client.

Snapshot of PO Testing System – SAP NetWeaver Administrator -> SOA -> Monitoring -> REST OAuth Server

At this point we need to fill in the following parameters:

  • Client ID is the client_id we will be using later in the call to the authorization server.
  • SAP NetWeaver User should be selected by clicking the Select User button. Using the Search button, you can navigate through the available NetWeaver users and choose the appropriate one. This REST OAuth Login module will later use the selected user to perform authentication.
  • Secret is the client_secret later used in the call to the authorization server. It is automatically generated by clicking the Generate Secret button.

Important! The client secret will only be displayed once – please make sure to record it. Otherwise, you will need to generate a new client secret by using the Edit Client option.

  • Token expiration is the time the token expires in (in seconds). The default is 3600 but you can customize it.
  • The Restrict to Specific Channels checkbox corresponds to the scope parameter in the call to the authorization server, which is optional. This functionality allows you to limit to which REST Sender channels an OAuth 2.0 token generated with this specific client is valid. If you leave this box unchecked, by default it can be used with all REST Sender channels with OAuth 2.0 enabled.

Please note! Only REST Sender channels with selected Enable “OAuth 2.0 Authentication for incoming requests” checkbox that were saved, activated and started will be visible in “Restrict to Specific Channels”.

What happens if you forget your client secret?

You need to generate a new one. Select the client, click on the Edit Client button and then on Generate New Secret. Make sure to record the updated client secret and click on the Save button.


Snapshot of PO Testing System – Editing a Client to generate a new client secret

  1. Call the Authorization server and obtain a token

In this step we call the Authorization server at the URL – http://<host>:<port>/RESTAdapter/OAuthServer


Snapshot of Postman – obtaining a token with scope



Snapshot of Postman – Obtaining a token without scope


Using the following query format:




Where the values for client_id and client_secret are the ones you have selected earlier when creating the Client in the REST OAuth Server User Interface.

The scope parameter is optional. The Bearer token generated with this call will only be valid for authentication when attempting to call the specified channel.

If the scope parameter is not used, then by default the generated token can be used with all channels selected in the Restrict to Specific Channels step when creating the client. If the client is not restricted to any specific channels (the checkbox is left blank) and the scope parameter is not used, then the token generated will be valid for all REST Sender channels with OAuth 2.0 enabled.

  1. Use the acquired token for authentication

Now we can make a call to the REST Sender channel and authenticate using the token we just generated.


Snapshot of Postman – using the acquired token for authentication when calling the REST Sender channel

The token has to be passed as an HTTP Header using the format Authorization: Bearer <access_token>

We include the Authorization header in the HTTP request and make a successful POST call to the REST Sender channel we created earlier.

  1. Check and delete expired tokens

It is possible to check which token have expired and delete them by going to

SAP NetWeaver Administrator->  SOA -> Monitoring -> REST OAuth Server -> Tokens

The Delete Selected button allows you to delete specific tokens, whereas the Delete All Expired button automatically deleted all expired token for you.



I hope this blog was helpful to understand how OAuth 2.0 can be used in the REST Sender channel. Please do not hesitate to share your feedback or thoughts in a comment.


SAP Documentation:

RFC 6749 “The OAuth 2.0 Authorization Framework”:

For SAP NetWeaver related questions and answers, please see:

For other blog posts on SAP NetWeaver, please see:

Assigned Tags

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

      Great blog on the new features this will help on-premise PO systems to have rest based integrations.

      Author's profile photo Stephen Kangethe
      Stephen Kangethe

      Great blog on the OAuth REST Sender feature. Been waiting for a while to have this and will be implementing it as soon as we upgrade to SP25.

      Author's profile photo JULIO DAVID CADAVID OSORIO

      Hi, Excellent blog many of us were waiting for this new functionality to protect SAP PI/PO REST Sender Channel.

      @Dayana pankova the current platform where I am developing does not have the SOA -> Monitoring -> REST OAuth Server options.

      Is it only apply SAP Note 3140397 and SAP Note 3163712?

      This is the version of the current platform:


      SAP_XIESR 1000.


      Author's profile photo Dayana Pankova
      Dayana Pankova
      Blog Post Author

      Hi Julio,

      Thank you for your comment!

      OAuth 2.0 in the REST Sender channel is available for SP25 onwards. So yes, in order to be able to use this functionality you need to be on SP25 or newer.

      Author's profile photo fei lu
      fei lu

      Great blog on the OAuth REST Sender feature. Thanks for sharing. Been waiting for it for centuries !

      Author's profile photo Midhun M
      Midhun M


      I am facing an issue while token caching in RESt reciever channel. Token is not retrieving automatically while doing end to end testing of interface. When i ping the REST receiver channel manually ,after that message is getting success. Otherwise Messages are getting failed with Error:

      " Exception caught by adapter framework: HTTP Communication Error. Could not retrieve oAuth Token"

      Kindly advice something



      Midhun M

      Author's profile photo JULIO DAVID CADAVID OSORIO

      Hi, @Dayana pankova I have managed to implement the information shared from your blog and it works very well in a (synchronous) RFC to REST scenario; however I need your help on how can I schedule the deletion of the messaging history to (1 day) as I have searched and made some configurations and still it keeps appearing, I have been guided by these articles but it still does not work:

      I have also configured:

      The messaging from last month that should no longer exist still persists, I would appreciate your guidance or help to not affect the performance of the server and its database.

      I remain attentive thank you very much.