Spring Security 7.1 resource servers stop enforcing DPoP until the app calls .dPoP()
Spring Security 7.1 no longer applies DPoP verification on resource servers automatically, so upgraded apps stop enforcing it until they add .dPoP(). InfoQ's walk-through calls the failure silent and the rest of the upgrade a version bump.
The Engineer · Build desk
What happened
- Spring Authorization Server now lives inside Spring Security 7 under the same Maven coordinates, so the article calls the move off the 1.5.x branch a version bump.
- Spring Security 7.1.0 shipped in June 2026 with Spring Boot 4.1, and 7.1.1 followed in August 2026 at org.springframework.security:spring-security-oauth2-authorization-server:7.1.1.
- Spring binds the JWK thumbprint through cnf.jkt and handles the refresh token for public clients itself, leaving the nonce policy and the jti replay cache to the identity provider.
- The jti replay cache defaults to an in-memory, single-node implementation that the article says may need replacing with a distributed one across a cluster.
Why it matters
- decision Every resource server on the upgrade path now needs an explicit yes or no on DPoP, because the framework no longer makes the choice for it.
- constraint Clustered deployments that want a shared replay cache cannot get one on 7.1.0 and have to reach 7.1.1 first.
- contradiction The article calls DPoP and Token Exchange production-ready in official components for the first time, yet its own takeaways say DPoP already worked end to end on Spring Security 6.5.
A client that sends a valid DPoP proof gets a normal response whether or not the server checks it. We'd expect a happy-path integration test to pass on both sides of the upgrade. Catching the regression takes a negative test: a DPoP-bound token presented with no valid proof, with a rejection expected.
The explicit call arrived with 7.1.0 [7], so the break lands on any app crossing from an earlier release. According to the article, the Boot 4 migration guides cover Jackson 3, the lambda DSL and package relocations, then stop at OAuth 2.0 [12]. We'd expect a team that follows them to the end to have no reason to open its resource-server configuration.
The default replay cache matters in a cluster. On a multi-node deployment we'd expect a proof replayed against a different node to meet an empty cache [5].
The article's larger argument is a pairing. It says service-to-service and agentic architectures keep reaching for one pattern: swapping a DPoP-bound subject token for a downstream token that is narrower and limited to a specific audience. It adds that the combination is only as safe as the exchange policy and token customizer you write [9]. In our view, a service that lost its DPoP check in the upgrade is a hop in that chain where the binding goes unverified.
All of this rests on InfoQ's account of the 7.1 line. The article's authors and the Spring release notes are the place to confirm the exact configuration before changing a production resource server.
What to watch
- Spring Security 7.1 reference docs or release notes confirming the .dPoP() opt-in and what a resource server does without it.
- Whether a distributed jti replay cache implementation ships with Spring or stays something each operator builds.
- Whether the Spring Boot 4 migration guides add the DPoP change, since the article says they stop at OAuth 2.0.
Clarity's read
What the record supports and how the coverage leans. The claims behind it follow.
Reality
- Evidence55
- Adoption
- Insufficient
- Hype gap+10
- Incentives
- Insufficient
- Confidence55
Claim ledger
Ranked by verification strength, evidence, and original report placement.
- [1]
Demonstrating Proof of Possession (DPoP, RFC 9449) already worked end-to-end on Spring Security 6.5 with Spring Authorization Server 1.5.
- [2]
Spring Authorization Server now lives inside Spring Security 7 under the same Maven coordinates, so moving off 1.5.x is a version bump.
- [3]
On the 7.1 line, resource-server DPoP verification is no longer automatic, so an app that relied on the old auto-applied behavior silently stops enforcing DPoP after upgrading until it adds the new .dPoP() call.
- [4]
Spring binds the JWK thumbprint via cnf.jkt and the refresh token for public clients on its own, leaving two decisions to the identity provider: the nonce policy and whether the jti replay cache needs to be swapped for a distributed one.
- [5]
The jti replay cache defaults to an in-memory, single-node implementation and may need to be swapped for a distributed one across a cluster.
- [6]
Spring Security shipped 7.1.0 in June 2026, paired with Spring Boot 4.1, then 7.1.1 in August 2026; the current coordinates are org.springframework.security:spring-security-oauth2-authorization-server:7.1.1.
- [7]
The resource-server .dPoP() opt-in is new in Spring Security 7.1.0.
- [8]
The pluggable jti replay cache is new in Spring Security 7.1.1.
- [9]
A DPoP-bound subject token exchanged for a narrowed, audience-restricted downstream token is the pattern service-to-service and agentic architectures keep reaching for, but the combined pattern is only as safe as the exchange policy and token customizer you write.
- [10]
A clustered deployment on Spring Security 7.1.0 cannot swap in a distributed jti replay cache; it needs 7.1.1 or later.
- [11]
DPoP (RFC 9449) and Token Exchange (RFC 8693) are both production-ready in official components for the first time.
- [12]
The Spring Boot 4 migration guides cover Jackson 3, the lambda DSL and the package relocations, then stop at OAuth 2.0.
Get this ledger inside ChatGPT. Ask about any of our stories and the answer brings its figure, each claim’s verdict and the sources. Free, no account.
Sources
1 independent publisher whose own reporting we read for this story.
- infoq.comArticle: Server-Side DPoP and Token Exchange in Spring Security 7
1 article · October 15, 2026
Topics and entities
Follow any of these and your For You feed starts watching them — no settings page required.
Topics
Entities
- Spring SecurityFollow
- Spring Authorization ServerFollow
- Spring BootFollow
- RFC 9449 (DPoP)Follow
- OAuth 2.0 Token Exchange (RFC 8693)Follow
- InfoQFollow