The most sensitive data of any trading company flows between the online shop and the ERP: orders, customer master data, prices, stock levels and payment information. Yet many of these interfaces still run on a single static API key or on Basic Authentication with a hard-coded password. What starts out pragmatic becomes expensive as the attack surface grows and compliance pressure rises. Compromised credentials are among the costliest entry points of all: a data breach costs companies worldwide 4.44 million US dollars on average (IBM Cost of a Data Breach 2025), and faulty authentication ranks second as Broken Authentication in the OWASP API Security Top 10 (OWASP). At the same time, the BSI recently recorded around 309,000 new malware variants per day (BSI). This article shows how to secure the API layer between ERP and shop with OAuth 2.0: using the client credentials flow, sender-constrained tokens via mTLS and DPoP, short token lifetimes, rotation and scope minimization -- guided by the current security guidance IETF RFC 9700.
Why Static API Keys and Basic Auth Become a Risk
The appeal of a static API key is obvious: it is set up in minutes, copied into every HTTP call and works immediately. That very simplicity is what makes it a problem. Such a key is a permanent pass with no expiry date. It sits in plaintext in configuration files, in scripts, in developers' clipboards and not rarely in version control, where it was checked in by accident. Anyone who holds it can address the interface indefinitely -- without anyone noticing that the caller is no longer the legitimate one.
The economic dimension is substantial. The average data breach costs companies worldwide 4.44 million US dollars, down from 4.88 million the year before (IBM Cost of a Data Breach 2025). In the US the average is as high as 10.22 million US dollars (IBM Cost of a Data Breach 2025). For interfaces, what matters is less the average than the duration: it takes a mean of 241 days to identify and contain an incident (IBM Cost of a Data Breach 2025). A static key misused unnoticed during that time leaves the interface open for months. The BSI describes compromised credentials and identity theft as a persistently growing threat, especially against cloud infrastructures (BSI).
The static key is a permanent pass
OWASP lists faulty authentication as API2:2023 Broken Authentication in second place of the API Security Top 10 (OWASP). This explicitly includes weakly protected authentication endpoints that can be attacked by brute force or credential stuffing, as well as the insecure storage and management of tokens (OWASP). In first place stands broken object level authorization, where an interface returns records solely by an ID passed to it (OWASP). Both risks share a common root: too much trust in a single, long-lived secret. How these interfaces fit into the wider regulatory frame is covered in our article on the NIS2-compliant hardening of ERP interfaces -- here we look at the concrete authentication mechanisms beneath it.
OAuth 2.0 and the Client Credentials Flow for Machines
OAuth 2.0 is the established standard for delegated authorization. Instead of passing on a permanent password, a client obtains a time-limited access token from an authorization server and presents it on every call to the interface. OAuth knows several procedures, so-called grant types, depending on whether a human is involved in the browser or two systems talk directly to each other. For communication between shop, middleware and ERP -- machine to machine without an interactive user -- the client credentials flow is intended.
Why client credentials and not the authorization code flow
In the client credentials flow, the client authenticates directly at the authorization server's token endpoint and receives an access token in return. Authentication no longer happens through a plaintext password, but ideally through a client certificate. This is what such a token request looks like at its core:
POST /oauth/token HTTP/1.1
Host: auth.example.com
Content-Type: application/x-www-form-urlencoded
grant_type=client_credentials
&scope=orders:read inventory:write
# Response: short-lived access token with a narrow scope,
# bound to the client certificate (mTLS) or to a DPoP keyIn practice, the central place for this logic is the middleware: it fetches tokens, renews them in time, holds certificates and enforces the hardening uniformly, instead of implementing it anew in every single point-to-point connection. The access token the server issues is deliberately short-lived and carries only the permissions the respective process actually needs.
Bearer Tokens and Their Core Problem
A plain access token is initially a bearer token -- a holder token. The name says it all: whoever holds the token may use it, regardless of whether they are the legitimate client or an attacker who intercepted it. The server only checks whether the token is valid, not who presents it. A bearer token thus has the same conceptual weak point as a static key, only with a shorter lifespan. If it falls into the wrong hands -- through a leak in log files, a compromised proxy or a faulty error message -- it can be reused unhindered until it expires.
A bearer token is like cash: whoever finds it can spend it. Sender-constrained tokens turn this cash into a personalized cheque that is only valid with the matching ID.
Sender-Constrained Tokens: mTLS and DPoP
This is exactly where the current security guidance comes in. RFC 9700, the Best Current Practice for OAuth 2.0 security in force since January 2025, recommends binding access tokens to their sender (IETF RFC 9700). Such a sender-constrained token is only usable if the caller additionally proves possession of a certain secret -- a private key or a certificate. A stolen token alone then no longer helps an attacker. RFC 9700 names two standardized mechanisms for this: mutual TLS per RFC 8705 and Demonstrating Proof of Possession, DPoP for short, per RFC 9449 (IETF RFC 9700).
With mutual TLS, both sides identify themselves with certificates -- not only the server to the client, but also the client to the server. The issued token is bound to the public key of the client certificate; the resource server accepts it only over the same certificate-secured connection. DPoP pursues the same goal at the application layer: the client generates a signed proof per request with its private key, which the server checks against the key stored in the token. Both mechanisms render an intercepted token worthless, but differ in infrastructure and usage profile.
| Aspect | Mutual TLS (RFC 8705) | DPoP (RFC 9449) |
|---|---|---|
| Bound to | Client certificate | Public-private key pair |
| Layer | Transport layer (TLS) | Application layer (HTTP header) |
| Infrastructure | Certificate management, PKI needed | Feasible without client PKI |
| Typical use | Server-to-server in the data center | Clients without a stable certificate base |
| Proof per | Connection | Individual request |
For the classic server-to-server connection between middleware and ERP -- such as a SAP integration -- mutual TLS is often the obvious choice, because both sides are managed anyway and a certificate structure exists. DPoP plays to its strength where a full-blown client PKI would be too costly. What matters is not the choice of one mechanism or the other, but that tokens are bound to their sender at all, instead of wandering through the systems as freely transferable cash.
Short Lifetimes and Token Rotation
A sender-constrained token is already considerably harder to misuse. The second line of defense is its lifespan. RFC 9700 recommends short-lived access tokens to limit the window in which a compromised token is useful at all (IETF RFC 9700). Instead of a key that is valid for years, the client receives a token that expires after minutes and is fetched anew when needed. When a token expires, any unnoticed misuse ends automatically with it.
So that the client does not have to go through a full re-authentication on every call, refresh tokens come into play. These longer-lived tokens serve solely to obtain new access tokens. Because they thus become a worthwhile target themselves, RFC 9700 recommends refresh token rotation: on every redemption, the old refresh token is invalidated and a new one issued (IETF RFC 9700). If an already redeemed refresh token reappears, that is a clear sign of theft -- and the entire token chain can be blocked immediately.
- Short access token lifetime: minutes instead of months limit the misuse window to a minimum.
- Refresh token rotation: every redemption invalidates the previous refresh token and exposes reuse immediately.
- Sender-constraining refresh tokens too: the refresh token is also bound to mTLS or DPoP, so that theft alone is of no use.
- Automatic renewal: the middleware fetches tokens in time and without downtime, so short lifetimes do not disrupt operations.
- Immediate revocation: individual tokens or clients can be blocked specifically, without halting all integrations.
Short lifetimes need reliable renewal
Scope Minimization Following Least Privilege
Even a short-lived, bound token should be allowed to do only as much as necessary. That is exactly what scopes achieve: they restrict a token to a narrowly defined set of rights. A process that only needs to transfer orders from the shop into the ERP needs no token with full access to customer master data and prices. RFC 9700 explicitly advises keeping scopes minimal and granting only the permissions actually required (IETF RFC 9700). This least privilege principle limits the damage should a token be compromised after all.
The effect reaches all the way to broken object level authorization, which OWASP lists in first place of the API Security Top 10 (OWASP). A narrowly scoped token that only allows read access to orders cannot change prices or delete customer records, even if an attacker captures it. Scopes do not replace per-record authorization checks, but they considerably shrink the attack surface of each individual token. How such an authorization layer can be centralized is shown in our comparison of REST API and middleware.
One scope per task
Every integration process gets its own client profile with exactly the rights its task requires -- no more.
Separate read and write
A read-only access to orders gets no write permission. This way a compromised token cannot change any data.
No catch-all client
Instead of a universal access for all interfaces, each connection receives its own clearly delimited mandate.
# Order import shop -> ERP
scope=orders:read
# Stock feedback ERP -> shop
scope=inventory:write
# Price maintenance (separate client, own certificate)
scope=prices:writeWhat RFC 9700 Concretely Recommends
RFC 9700 bundles the current security guidance for OAuth 2.0. The Best Current Practice published in January 2025 updates the attacker model and summarizes what has proven secure over years of practical experience (IETF RFC 9700). For an ERP-to-shop interface, the core points translate into a few clear rules: sender-constrained tokens instead of plain bearer tokens, short lifetimes, refresh token rotation, minimal scopes and the avoidance of outdated procedures such as the implicit flow and the password grant.
| Aspect | Grown connection | Per RFC 9700 |
|---|---|---|
| Authentication | Static API key or Basic Auth | OAuth 2.0 client credentials flow |
| Token type | long-lived bearer secret | sender-constrained via mTLS or DPoP |
| Lifetime | unlimited, rarely rotated | short-lived, automatically renewed |
| Refresh | no concept | rotating, blocked on reuse |
| Permission | usually full access | minimal scopes per process |
| Revocation | only global key rotation | specific per token or client |
Security as a property of the interface, not an afterthought
The Path from Static Keys to OAuth 2.0
The path from a grown connection with a static key to a token-based interface can be taken step by step, without interrupting ongoing operations -- as part of an orderly system integration. At the start there is no big redevelopment, but a stocktaking: which interfaces exist, how do they authenticate today and what data flows across them. From this finding the order follows -- the connections with the most far-reaching rights and the most sensitive data first.
1. Take stock
Record all interfaces, their authentication, their data classes and their permissions. Static keys and Basic Auth connections become visible in the process.
2. Introduce an authorization server
Provide a token endpoint, set up client profiles per process and distribute certificates for mTLS or keys for DPoP.
3. Switch over gradually
Move each connection individually from the static key to the client credentials flow, test in parallel and only then shut down the old access.
4. Monitor and operate
Continuously observe token usage, error rates and revocations so that short lifetimes and rotation work reliably in continuous operation.
Anyone who embeds this hardening into a broader integration strategy will find further approaches in our article on connecting JTL-Wawi to the online shop as well as on the digital product passport under the ESPR -- both show that a secure API layer is the basis for new data flows. How to make token usage, error rates and anomalies visible in ongoing operation is deepened in the article on observability of interfaces.
Security is not a feature you bolt onto an interface afterwards. It is the way an interface organizes trust -- from the very first line.
Sources and Studies