Welcome to the third part of our SAP API Security journey. In second series, we learnt about Basic Authentication, OAuth definition and OAuth flows that SAP supports. Now lets gear up to OAuth authentication with some screenshots.

SAP got one of the best documentations in market. Wiki will give you end to end guide for OAuth implementation with SAP tailored made use case.

But for our use case, let’s see how to enable OAuth in the OData service we created and implement the OAuth authorization code flow.

Select the OData service under transaction /iwfnd/maint_service, click on OAuth from available menu. Once your services is under OAuth scope then a check mark will appear beside OData services.

Figure 10: Activate OAuth in OData Service

Create a generic user that will be used for all OAuth flows, to be specific it will be used to exchange tokens between consumers and service providers, but NOT for posting which is our goal.

At this point no need to assign any access/roles to this user. And this user must be setup as SYSTEM user type.

Figure 11: OAuth Generic user SAP profile

Now execute transaction SOAUTH2 to create OAuth client here is how it looks –

Figure 12: OAuth configuration in SAP

Client ID: It is generic user you created in earlier step “SECTEST99”

Client Authentication: User “Client User ID and Password” so that front-end application needs to provide generic user account id and password to exchange token.

Resource Owner Authentication: Select checkbox “Grant Type Authorization Code Active”

With that you must provide “Redirect URI”.

Question 3: What is Redirect URI

It is the location where the authorization server sends the user once the app has been successfully authorized and granted an authorization code or access token. The authorization server sends the code or token to the redirect URI, so it’s important you register the correct location as part of the app registration process.

Redirect URI: It is given to you by front-end application admin. For this exercise we will use Postman web as our front-end application, as like for Basic-Authentication we used Microsoft SharePoint. Postman has static Redirect URI for developers. Remember, Postman web has different redirect uri than Postman native app. For this exercise we are using Postman Web.

Refresh Allowed: It is another key feature in OAuth2.0 that SAP supports as well. In this blog series we are not going to use this feature so you can keep it unchecked.

Scope Assignment: Add the OData service that you created. Pre-requisite to appear your OData Service here to add under OAuth scope under transaction /iwfnd/maint_service. You can add multiple OData services under one client id.

Note: Remember Client ID is case-sensitive. I’ll recommend use upper case wherever it is prompted.

Now we will create an authorization role (Z:API_TEST_ROLE_OAUTH) with OAuth related object. This role is added to the user who uses this service as an OAuth and generic user, who has access to the service

Figure 13: SAP PFCG Role to access OAuth Client and Scope

Assign this role to generic OAuth user SECTEST99 and NO other access is needed as the purpose of this generic user is to exchange access token.

Figure 14: OAuth Generic user access

In this case, as data will be created in SAP using Mr. John’s account and not by any generic user, he must have SAP account with required permission. Required permissions are – OAuth role itself along with OData service role and permission to modify table ZOVBAK.

Figure 15: Business User account to access OData, OAuth scope and modify ZOVBAK Table

Let’s see practical in Postman app by calling OData service using “Get” Method.

For “Get” method we are using Basic-Authentication (although OAuth can be used as well), our goal is to get the x-csrf-token from Get method which we will utilize in “Post” method. For that under Headers I’m requesting (x-csrf-token = fetch) from OData service. After Status is 200 Ok then under response section of Header, we will get the x-csrf-token value.

Figure 16: Postman GET configuration

Let’s see “Post” Method configuration with OAuth2.0 authentication –

Figure 17: Postman OAuth2.0 configuration to fetch Access Token

Token Name: Give random name

Grant Type: Authorization Code

Callback URL: This url should match with redirect URI that is configured in SOAUTH2 transaction in SAP.

Auth URL: https://<hostname>/sap/bc/sec/oauth2/authorize

Access Token URL: https://<hostname>/sap/bc/sec/oauth2/token

Client ID: SAP ID of generic account

Client Secret: Password of generic account

Scope: Name of the OData service to generate token

Now hit on “Get New Access Token” button that will open a pop-up for you to authorize.

Figure18: End User step to authorize request

Figure19: Access Token details post end user authorized request

Figure20: POST headers and body configuration

Figure21: Result of POST operation

Status 201 means – entry is created.

These configurations made in Postman are technical specifications that we (SAP team) must provide to the administrator of the front-end application (be it SharePoint or ServiceNow or any other application). With that, the frontend administrator must deploy the configuration to the respective application to make a successful connection.

As far as Mr. John (or any business user) is concerned, he will simply enter the required details in the front-end application form and authorize the transaction using his SAP credentials, which should then publish the details in the SAP ZOVBAK table.

Figure 22: SAP ZOVBAK Table entry

You will notice that REMARK, which is added to the body of Postman or during Basic Authentication of SharePoint, is also changed. I have set up logic to update REMARK as SAP ID of the user creating a record in the table. This logic changes the REMARK specified in Body or SharePoint with the person creating the record.

The Outcome

With basic authentication, the table record is created by a generic service account, while with OAuth authentication, the record is created by Mr. John’s ID. By using OAuth authentication method ASDF’s both requirement is fulfilled:

1. Since ASDF has various customers around the world, the development should be robust enough to create records in the ZOVBAK table using one or more applications.

“https://<hostname>/sap/opu/odata/sap/ZTEST_API_TEST_SRV/SOHEADERSet” OData service is robust to utilize in any application that supports REST calls.

2. For the ASDF company, the ZOVBAK table is critical, so only authorized, and authenticated users are allowed to create records.

OAuth2.0 will ensure that only authorized, and authenticated users are creating records in table

This was the final series and ThankYou for reading it. I’ll be happy to answer your query or if you have any feedback for me.