Skip to Content
Technical Articles

Oauth for the NEO SAP Cloud Platform Odata Provisioning service – Part 1 : Authorization Code Grant

In the following blog article I want to show how you can protect the SAP Cloud Platform oData provisioning service with OAuth.

Details on OAuth and the possible OAuth flows can be found here.

Currently the NEO platform supports 2 types of OAuth flows, Client Credentials Grant and  Authorization Code grant as described in the SAP Help.

Both flows have different use cases.

The Authorization Code grant requires that the users is first authenticated (Identified) before he can receive his OAuth token that grants him access to the Odata provisioning service. On the other hand, this means that the user is identifiable inside SCP and so the user ID can be then forwarded for example to the SAP backend system using principal propagation.

The Client Credentials grant on the other hand is more alike a system/technical user. No user interaction is needed for the authentication, but on the other hand this also means that the principal propagation only has the technical user to work with.

The OAuth configuration can be accessed trough  the Security / OAuth menu

Then select the client tab to start the configuration by clicking on ‘Register New Client’.

 

In this first part , Ill describe the Authorization Code grant

Authorization Code grant

Configuration

Set the following fields :

  • Subscription : Make sure to select gwaas/gwaas    (Note: Another name for the SCP Odata Provisioning service)
  • Name : Select what you want, but preferably something descriptive
  • ID : you can use a generated ID or specify one yourself, but make sure its globally unique across sap cloud platform

Test using Postman

After opening postman enter the following

URL : The URL of the SCP Odata provisioning service you want to use

Authorization / Type  : OAUth2.0

We can now request our OAuth token by clicking on the ‘Get New Access Token’ button.

This takes us to the token request screen.

 

Make sure to Enter :

Callback URL : As specified in the OAuth client setup screen

client ID : As specified in the OAuth client setup screen

Auth URL  & Access Token URL : Take these from the ‘Branding’ tab on the OAuth setup screen

Now press the ‘request token’ button in postman.

Since we are using the authorization code grant you now first need to be authenticated against the SAML identity provider that is configured for this sub-account under Trust / Application Identity Provider.

Once authenticated , the consent screen appears. This screen requires the user to explicitly give his consent for granting the clientID access to the odata provisioning service.

Note 1 : You can brand this screen with your own logo etc. by modifying the ‘Branding’ tab on the OAuth settings

Note 2: You can skip the consent screen by specifying the option in the OAuth client settings

The resulting OAuth token can then be used inside postman for the Get request.

At any time, you can verify the OAuth tokens that are granted to the users and explicitly revoke them if needed. This can be done from the Security / Authorizations menu and then the ‘Token’ tab on SCP.

This concludes the first part of this small blog series. In the next part of this blog series Ill describe the client_credentials grant flow.

Bye,

D.

Be the first to leave a comment
You must be Logged on to comment or reply to a post.