An API token can be genuine, unexpired and issued to the right user, yet still carry more authority than the next service needs. That matters when an application calls several other systems to complete one task. Checking that a token is valid does not, by itself, establish who should be allowed to use it or which operations it should authorize.
For enterprise IT teams, API token security therefore involves two separate decisions: preventing misuse of a copied credential and limiting access as a request moves between services. DPoP and OAuth token exchange can support those decisions, but the security outcome depends on the policy, integration and testing around them.
Start with the service interaction
Consider an order portal that needs to retrieve shipment status. The user may also be entitled to change an order or manage account details, but the shipment lookup needs neither permission. Forwarding a broadly usable token can expose more authority than the task requires if downstream services accept it.
The design should establish which API is the intended recipient, which operation is allowed and which service is acting for the user. Audience restrictions define where a token may be accepted; scopes help express permitted operations. The receiving API must enforce those restrictions alongside its application-level authorization, including access to the particular customer’s records.
This is a useful review point during application modernization. As one application becomes several connected services, the number of places where credentials are handled grows. The dependency mapping described in Ahead’s application modernization and operational resilience article should therefore include identity and authorization flows, not only data and availability dependencies.
Make a copied token insufficient
A bearer token can be used by whoever possesses it. Demonstrating Proof of Possession, or DPoP, adds a different requirement: the client must provide a signed proof associated with the private key to which the token is bound. The receiving server checks the proof and its relationship to the request and token. RFC 9449 defines the mechanism.
This reduces the usefulness of a stolen token when the attacker cannot also use the corresponding key. It does not make a compromised application trustworthy. An attacker able to operate the legitimate client or access its signing capability may still make authorized-looking requests. DPoP also does not reduce the permissions in a token or replace HTTPS.
For a delivery team, the important questions concern key storage, rotation and enforcement at every relevant API. A proof requirement that is omitted from one access path can undermine the intended protection.
Issue downstream authority deliberately
OAuth token exchange provides a standard way to request another token using an existing one. In the shipment example, the portal could request a short-lived credential for the shipment API with permission to read status. That is a proposed authorization policy, not an automatic result of using the protocol.
The authorization server must decide which callers may exchange which credentials, for which destinations and permissions. It must reject requests outside that policy. RFC 8693 distinguishes acting as another party from delegation that preserves the actor’s identity; the choice affects what downstream systems can understand and audit.
A service should not gain permission merely because it holds somebody else’s token. Before exchanging an incoming credential, it must validate the incoming request and establish its authority to act. If the new token is also DPoP-bound, the design must identify which service holds its proof key. The original client’s proof is not a reusable credential for every later hop.
Treat framework support as a starting point
Spring provides a concrete implementation example, but these capabilities are not new simply because a project moves to Spring Security 7. Spring documented Token Exchange support in Spring Security 6.3 and Spring Authorization Server 1.3, while Spring Security 6.5 introduced DPoP support.
Check the exact versions and configuration used by the authorization server, clients and receiving APIs. One operational detail illustrates why: Spring’s documented default in-memory DPoP replay cache is limited to a single-node setup. A clustered deployment needs a suitable approach to shared replay detection. A successful test against one development instance does not establish production-wide enforcement.
Require evidence from failure tests
Before approving rollout, ask the delivery team to demonstrate rejection as well as success. A practical acceptance test set should show that:
- A copied DPoP-bound token fails without the correct proof key, including when presented through an unintended bearer-token path.
- The shipment API rejects a token intended for another service and refuses operations outside its permitted scope.
- An unauthorized service cannot exchange a user’s credential into access it should not receive.
- Reusing a proof is detected across application nodes, not just on the instance that saw it first.
- Proxy routing, clock differences, retries and key rotation do not create acceptance gaps or unexplained outages.
Operations should also be able to trace the user, acting service and authorization decision without collecting raw access tokens or private keys in logs. Agree who investigates failures and what happens if a replay-detection dependency becomes unavailable. Those are production design decisions, not details to leave until handover.
Roll out one controlled path first
Start with one important service interaction. Record its existing token flow, intended permissions and owners. Agree the acceptance tests before implementation, then measure authentication failures, exchange latency and business-transaction success in a representative environment.
Expand only after the path is proven. The rollback plan should state how required protection is maintained; silently accepting unrestricted bearer tokens is not an equivalent fallback. For international enterprises operating in Japan, make ownership between local application teams and global identity-platform teams explicit before the change window.
Where Ahead fits
Ahead Group provides IT consulting, system integration and project delivery for international enterprises in Japan. An API security change needs those teams working with identity and application owners on the same acceptance criteria. If you are planning an integration or modernization project, contact Ahead to discuss the architecture, delivery scope and validation work it requires.