Kanishk Kaushik - May 15, 2025

🔐 SAP API OData Security with OAuth 2.0: A Beginner-Friendly Guide

In today’s interconnected enterprise landscape, secure access to SAP OData APIs is a foundational requirement. Whether it’s for third-party integrations, internal services, or customer-facing portals, ensuring that only authorized data is accessible is key to protecting sensitive business information.

One of the most robust and scalable approaches to API security in SAP is OAuth 2.0, a widely adopted authorization framework that enables controlled access to resources without exposing user credentials.

This blog provides a clear overview of how OAuth 2.0 works in the SAP ecosystem, including role-based access configuration, important transactions, prerequisites, and a realistic example using a customer portal scenario to illustrate how token-based access works at runtime.

🔍 What is OAuth 2.0?

OAuth 2.0 is an open authorization protocol that allows applications to access resources on behalf of a user or system, without sharing the user’s credentials. It achieves this by issuing access tokens that are scoped to specific permissions.

Key roles in OAuth 2.0:

• Resource Owner: The user who owns the data (e.g., Customer A or B).
• Client: The application (e.g., a React/Java-based portal) requesting access.
• Authorization Server: Issues tokens after successful authentication.
• Resource Server: SAP system hosting the protected OData services.

🏗️ How OAuth 2.0 Works in SAP

Here’s a simplified view of the OAuth 2.0 flow in an SAP environment:

1. Client Registration: Register a third-party app as an OAuth client using transactions like SOAUTH2 or OA2C_CONFIG.
2. Token Request: The app requests an access token using credentials.
3. Token Issuance: The authorization server validates the request and issues a JWT (JSON Web Token) containing scopes.
4. Access Control: The SAP backend validates the token and grants access based on defined scopes and roles.

🛠️ Key SAP Transactions for OAuth Configuration

✅ Prerequisites

Before setting up OAuth 2.0 in SAP, ensure the following:

• SAP Gateway or S/4HANA embedded Gateway is operational.
• SSL/TLS is enabled and functional (OAuth requires HTTPS).
• You have administrative access to manage roles and services.
• OData services are activated and tested.
• Proper backend roles and authorizations are defined.

🔐 Real-World Scenario: Customer Account Access via Web Portal

Imagine a scenario where an enterprise provides a web-based customer portal developed using React or Java. This portal allows customers to log in and view their own account details.

Let’s consider two customers:

• Customer A logs in and should only see Customer A’s account data.
• Customer B logs in and should only see Customer B’s account data.

The same application code is used for both customers, but access is securely controlled through OAuth 2.0.

🔄 How It Works

Login and Token Retrieval:

• When Customer A logs in, the portal authenticates with SAP using the customer’s credentials.
• The authorization server issues a JWT token containing scopes or claims specific to Customer A.

Accessing the OData Service:

• The portal sends this token in an API call to the SAP OData service (e.g., /sap/opu/odata/sap/ZCUSTOMER_ACCOUNT_SRV).
• The backend validates the token and checks that the token’s scope only allows access to Customer A’s data.

Authorization Enforcement:

• The backend role (assigned via PFCG) ensures the response only includes data relevant to Customer A.
• If Customer A’s token is used to access Customer B’s data, access is denied.

Repeat for Customer B:

• Customer B follows the same flow.
• Their token allows only access to their own data.

🛡️ Role & Scope Configuration in SAP

To make this scenario work, follow these steps:

1. Define Backend Roles (PFCG)

   Create roles like:

   • Z_CUST_A_ACCESS: Grants access to Customer A’s data.
   • Z_CUST_B_ACCESS: Grants access to Customer B’s data.

   Use authorization objects like S_SERVICE, S_SCOPE, or data-level controls like S_TABU_DIS.

2. Assign Roles to Users

   Use SU01 to assign the correct role to the backend user or technical user.

3. Map Roles to OAuth Scopes

   In SOAUTH2, define scopes like:

   • cust_a_scope → maps to Z_CUST_A_ACCESS
   • cust_b_scope → maps to Z_CUST_B_ACCESS

4. Register OAuth Clients

   Using OA2C_CONFIG, register clients (React/Java apps) and assign scopes based on login.

🧾 Sample Token Request

Here’s a sample curl request to get a token for Customer A:

curl --location 'https://your.sap.system/sap/bc/sec/oauth2/token' \
--header 'Content-Type: application/x-www-form-urlencoded' \
--data-urlencode 'grant_type=client_credentials' \
--data-urlencode 'client_id=CLIENT_ID_CUST_A' \
--data-urlencode 'client_secret=CLIENT_SECRET_CUST_A'

📋 Conclusion

OAuth 2.0 provides a flexible and secure mechanism to protect SAP OData services, especially in multi-tenant or customer-facing applications. By combining scopes, roles, and token-based access control, organizations can:

• Enforce granular data access policies,
• Safely expose services via web or mobile applications,
• Stay compliant with modern security best practices.

With proper configuration, the same application can serve multiple customers securely—without ever risking data leaks or unauthorized access.

Need a walkthrough? Contact your Customer Success Manager or email us at info@bluefunda.com.