Hacktoberfest 2026:メンテナが10月に向けて印を付けた、オープンで初心者向けの issue。 Hacktoberfest の issue を見る

DPoP InMemoryCache: document the request-rate ceiling implied by maxRequestsPerKey

オープン 初心者向け
#19,996 コメント 0 件 リアクション 0 件 担当者 0 名 GitHub で見る

メンテナーはふだん 1 日以内に返信

まだ誰も着手していません。

評価

難易度
2/5
見積もり時間
1〜3時間
初心者へのやさしさ
62/100
issue の種類
ドキュメント
明瞭さ
明確に書かれている
活発さ
活発
技術スタック
java, spring-boot

調査の方向性

DPoP のリファレンスドキュメントと、DPoPProofReplayValidator.InMemoryCache の javadoc で maxRequestsPerKey を説明しているものを探してください。DPoPProofJwtDecoderFactory の clock-skew のデフォルト値を読み、次にレート式(おおよそ maxRequestsPerKey / clockSkew 毎秒毎ノード)を issue の数値と照らし合わせて確認してください。ドキュメントに上限とウォームアップ効果が記載されていれば完了です。個別のログメッセージはコード変更であり、分離すべきです。DPoPAuthenticationTests はテスト用に制限を上書きする方法を示しています。

索引モデルが issue の本文から書いたものです。

説明

status: waiting-for-triage

Expected Behavior

The DPoP reference documentation states the request-rate ceiling that DPoPProofReplayValidator.InMemoryCache's per-key limit implies for a single client key: about maxRequestsPerKey / clockSkew accepted requests per second per node. A request rejected because of that limit can be told apart from an invalid or replayed proof, for example by a distinct log message.

Current Behavior

Spring Security 7.1.2 (Spring Boot 4.1.2), one resource-server node, .dPoP(Customizer.withDefaults()), Keycloak 26.6.1 issuing DPoP-bound tokens. One client key sending unique proofs at a constant rate for 70 s:

rate (req/s) accepted rejected (401) first rejection accepted, last 30 s
24 1680 0 – 24.0
26 1802 18 39.4 s 25.9
32 1976 264 31.8 s 31.9
40 2015 785 25.0 s 33.3
50 2012 1488 20.0 s 33.3

With the defaults (maxRequestsPerKey = 1000, 30 s clock skew in DPoPProofJwtDecoderFactory), one client key is capped at about 33 accepted requests per second per node. Above about 25 req/s it is also rejected for a while after it starts, from t ≈ 1000/R, because its quota fills before its first entries expire. The 1000-per-key default is documented; the rate ceiling it implies is not.

Context

Replay protection itself works as intended; this is about availability for honest high-rate clients, such as a backend service that uses one DPoP key. The limit can be raised as in DPoPAuthenticationTests (an ObjectPostProcessor<DPoPAuthenticationProvider> that installs a DPoPProofJwtDecoderFactory built with createDefaultJwtValidatorFactory and a DPoPProofReplayValidator whose InMemoryCache has a larger setMaxRequestsPerKey). The ceiling then scales with both settings: the test's values (500 per key, 60 s skew) give about 8 req/s per key. Happy to submit a docs PR if this is welcome.

Minimal reproduction (Spring Boot app + Keycloak, one command), predictions committed before the run, and raw data: https://github.com/sergioemancinas/dpop-replay-threshold/tree/main/spring-7-followup

主要言語
Java
スター
9.7k
フォーク
6.4k
平均マージ
1日 22時間
マージ済み PR(30日)
49

環境構築

はじめの一歩

  1. issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
  2. 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
  3. リポジトリをフォークし、ブランチを切って変更します。
  4. issue 番号を参照したプルリクエストを送ります。

spring-projects/spring-security のほかの issue

spring-projects/spring-security の issue をすべて見る

似ている issue

Java の issue をもっと見る

新しい issue をメールで受け取る

初心者向けの GitHub issue を短くまとめたダイジェスト。