PTV Logistics Product Forum

Hi SAP folks,

these days a SAP driven customer described the following concern - maybe someone from you can provide some advice how to tackle this?

As we all know the secret token aka ApiKey has to be sent with each call as part of the header or the request URL.
Is there a standard mechanism in SAP that stores the token in a proper vault from which it can be retrieved by the C++ / the masquerading layer? I am afraid that someone with someone with sufficient access can gather the secret.
How do other customers ensure the privacy of a token?

The answers I found within ChatGPT are:

• SAP Secure Store (SSFS/SECSTORE) is intended for SAP internal components (RFC credentials, SNC keys, etc.), not for custom applications.
• Exposing a secret directly in the C++ or masquerading layer makes it vulnerable (file system access, memory dumps, debugging).
• The goal should be to avoid storing long-lived secrets there at all.

Practical solution patterns:

• 1. Do not persist the secret in the C++ layer. This way, no permanent secret ever resides in the C++ environment.
  • Use a token broker service pattern
    • The broker is a small, privileged component that fetches or renews tokens from a secure backend (Vault, SAP Credential Store, etc.).
    • The C++ layer authenticates to the broker via mTLS or Kerberos, not with stored credentials.
    • The broker returns only short-lived tokens in-memory.
• 2. Use a proper Secret Store
  • On-premise options: HashiCorp Vault, CyberArk, OS-native keystores (Windows DPAPI / Linux kernel keyring).
  • SAP BTP option: SAP Credential Store service (if hybrid scenarios are allowed).
  • The store manages lifecycle: rotation, auditing, policy-based access.
• 3. Harden Runtime Security
  • Keep tokens in memory only; never in files, ENV variables, logs, or dumps.
  • Apply memory zeroization after use.
  • Run the C++ service under a dedicated OS account with minimal privileges.
  • Enforce certificate-based authentication to the broker or vault.
  • Enable auditing and anomaly detection for secret requests.
• Recommended Architecture
  • C++ service → Token Broker (via mTLS).
  • Broker → Vault/Keystore (fetches or rotates tokens).
  • Token delivered in-memory only, with TTL (2–10 min).
  • Broker/Vault manages refresh tokens or root secrets securely.
  • Full audit trail on every fetch.
• Key Takeaways
  • SAP’s own secure storage mechanisms are not for custom app secrets.
  • The correct way is to externalize secret management into a vault/credential store and expose only ephemeral access tokens to the C++ layer.
  • This removes the need to store a sensitive “secret” where any privileged user might access it.

Hi,

You've got some great ideas there.

Just a quick question: is it possible for PTV to restrict an API key to one or more specific domains/IPs?
For my use case, it makes a lot of sense to trigger a request to PTV directly from the client.

If we could impose such a restriction, it would remove a lot of the security burden.

This removes the need to store a sensitive “secret” where any privileged user might access it.

Thank you,
Octav

Hello Octav,

let me first recap the status...

• We deal with an API that requires an API KEY and is available only through HTTPS.
• The services are available from anyone participating in the public internet who has a valid key, whether it is
  • a mobile app
  • desktop application
  • web based application
  • a database which supports such calls
  • or what so ever

Today there's no further level of protection in the services:

• No firewall rule that restricts clients to send requests from certain IP addresses / ranges
• No client check for "comes from the following referrer url"

So what you request is not implemented. As of now.

These additional layers have been used in the past when the cloud wasn't even named the cloud but nowadays we rely on

• Each communication channel / network has to use secure, state-of-the-art protocols (e.g. latest TLS, no HTTP only...)
• Administrators who host such channels are in charge of ensuring that no player with direct access to such a channel can sniff it.
• Each component in the network that stores a "secret" has to use secure, state-of-the-art containers (encrypted databases, encrypted files, dedicated valuts...), to ensure that information is not visible to players who should not have it. (principle of least privilege)

I am not sure what scenario you want to consider on top of that by adding the layers you mentioned above.
Unfortunately I am not an SAP expert but I will redirect your concerns to some buddies who could comment on this.

Bernd

Hello Bernd,

Thank you for the detailed explanations. I'd like to elaborate on my specific situation, as it highlights the challenges of integrating modern APIs within a traditional on-premise SAP environment.

Our company uses SAP R/3 on Netweaver 750, and I am migrating a process from the old PTV XServer (SOAP) to the new PTV Developer API.

The previous SOAP protocol used Basic Authentication (username & password), which allowed us to store the credentials securely in the standard SAP Secure Store via an RFC Connection (Type G). With the new Developer API, every request requires an API key, and I haven't found a standard SAP method for securely storing such a key in an on-premise system.

This leads to two challenging scenarios:

1. Backend Security: For server-to-server calls (e.g., validating a partner's address from ABAP), the API key must be stored somewhere on the backend. While a standard user can't access it, privileged users like consultants or developers could potentially retrieve the key if it's not stored in a proper vault.

2. Frontend Exposure: For our users, we need to render PTV maps in the browser. Our goal is to use our standard technology (SAPUI5) for client-side rendering. However, this approach would require embedding the API key in the JavaScript code, making it visible to anyone who opens the browser's developer tools (F12).

The solutions you described, like a token broker or external vault, are ideal but can be complex to integrate with a legacy on-premise SAP system.

Given these constraints, is there a recommended best practice for securely managing a PTV API key for both backend and frontend use cases within this SAP context?

Thank you for any insights you or the community can provide.
Octav