Understanding OAuth 2.0 Behavior in SAP Datasphere’s Generic OData Connection

[marcw15]

The Generic OData Connection in SAP Datasphere offers a standardized method for integrating any OData-compliant service. It enables seamless access to remote tables and supports data flows without requiring extensive configuration. However, due to gaps and ambiguities in the official documentation, this article aims to clarify some limitations and technical constraints that may impact implementation and operational stability when using OAuth 2.0 authentication.

Note: Recently, KBA 3586535 was published, briefly describing this issue and indicating that a fix will be available soon. This article aims to provide additional context to both the KBA and the official documentation, as especially the latter still contains some gaps.

SAP Datasphere supports multiple authentication types for the Generic OData connection: No Authentication, Username and Password, and OAuth 2.0, the latter being the default and most secure option. In this article, we focus on OAuth 2.0 with the Client Credentials grant type.

One configurable setting in this context is the OAuth Token Request Content Type, which determines the format in which token request parameters are sent to the authorization server (and the server needs to accept as he has to handle the request with this content type). SAP Datasphere provides two options:

• URL Encoded (application/x-www-form-urlencoded)
• JSON (application/json)

Now, let us consider a scenario where the target system (authorization server) expects a different content type, such as multipart/form-data. Since SAP Datasphere does not support this format natively, one might attempt to define it manually using custom HTTP headers.

At this point, a critical limitation becomes evident: although custom headers can be added to the OData connection, they do not override the internally managed OAuth Token Request Content Type. Even if a custom header explicitly sets Content-Type: multipart/form-data, the request will still be constructed and executed according to the selected value in the Datasphere configuration (e.g., application/json).

When tracing the communication between SAP Datasphere and the HANA OData Adapter (which is responsible for sending the token request to the authorization server), logs reveal entries such as:

extraHeaderParameters: Accept: */*;Content-Type: multipart/form-data;cache-control: no-cache
OAuth Token Request Content: application/json

Despite the presence of a custom Content-Type header, only the configured value (application/json) is actually used in the request. This behavior can only be confirmed through internal HANA OData Adapter logs, which are accessible solely by SAP Support.

This limitation is not clearly addressed in the official documentation. While SAP states that “security-relevant headers such as ‘authorization’ are not allowed,” it does not emphasize that this restriction implicitly includes Content-Type as well.

Credential Placement and OAuth Token Request Behavior

A second, and more critical, limitation concerns the placement of client credentials. Regardless of the content type selected, client_id and client_secret are never included in the body of the token request.

According to SAP's documentation, parameters should be included in the body based on the selected format (URL Encoded or JSON). However, this does not apply to client credentials. Log entries from the HANA OData Adapter show that only the grant_type is included in the request body.

2025-XX-XX 10:14:03.009360 D HttpClient WebRequestInternal.cpp(00XXX) : Sending the following body to server
CLOB START (Addr: 0x00007fexxxxxxx Len: 35)
0x00007fexxxxxxx {"grant_type": "client_credentials"}
CLOB END

At this point, debugging becomes challenging. SAP has confirmed that neither the client_id nor the client_secret are logged - not in the body, nor in the headers - due to security restrictions imposed by the HANA OData Adapter. This means there is no way to verify, via logs, whether client credentials were transmitted at all.

Through communication with SAP Support, we were able to clarify the system behavior: client credentials are always sent via the HTTP headers, never via the request body. If the target authorization server expects the credentials in the body the request will fail, as the body fields remain empty. This behavior is fixed and cannot be modified.

Implications for Integration Design

These two limitations, if unrecognized, can lead to difficult-to-diagnose errors during implementation:

• Custom headers do not override the actual content type used in the token request body.
• Client credentials are always transmitted via headers, regardless of the selected OAuth Token Request Content Type.

These nuances are not sufficiently addressed in the official documentation. In particular, statements such as:

"OAuth2 token request parameters will be in JSON format and included in the HTTP request body."

may lead to the incorrect assumption that client credentials are included in the body as well.

Alignment with RFC 6749: The OAuth 2.0 Authorization Framework

RFC 6749, Section 2.3.1, defines two valid methods for transmitting client credentials in the Client Credentials Grant flow:

• HTTP Basic Authentication – where client_id and client_secret are passed in the Authorization header.
• Request Body Parameters – where the credentials are included in the body using application/x-www-form-urlencoded.

SAP Datasphere's current implementation behaves in a somewhat rigid manner. While the system allows users to configure the OAuth Token Request Content Type as application/x-www-form-urlencoded, SAP Support has confirmed that the Generic OData Adapter transmits the client credentials exclusively via the HTTP header. They are never included in the request body, regardless of the configured content type.

This behavior appears to reflect the cautionary guidance in RFC 6749, which states:

"Including the client credentials in the request-body using the two parameters is NOT RECOMMENDED and SHOULD be limited to clients unable to directly utilize the HTTP Basic authentication scheme."
— RFC 6749, Section 2.3.1

In other words, when application/x-www-form-urlencoded is selected, it is standard and expected - according to the specification - that parameters such as client_id and client_secret be passed in the request body, unless the client is using HTTP Basic Authentication.

Therefore, SAP Datasphere’s behavior, while technically compliant with RFC 6749, lacks the flexibility explicitly allowed by the standard. It does not support a fallback to body-based credential transmission, which may lead to confusion or incompatibility with OAuth endpoints that expect credentials in the request body when this content type is used.