Hacktoberfest 2026: los issues que los mantenedores marcaron para octubre, abiertos y aptos para principiantes. Explorar issues de Hacktoberfest

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

Abierto Apto para principiantes
  • ¿Algo no está bien?
#19,996 0 comentarios 0 reacciones 0 asignados Ver en GitHub

Los mantenedores suelen responder en 1 día

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
2/5
Tiempo estimado
1-3 horas
Aptitud para principiantes
62/100
Tipo de issue
Documentación
Claridad
Bien especificado
Estado de actividad
Activo
Stack tecnológico
java, spring-boot
Área
authentication, documentation

Línea de trabajo

Encuentra la documentación de referencia de DPoP y el javadoc de DPoPProofReplayValidator.InMemoryCache que describe maxRequestsPerKey. Lee el valor predeterminado de clock-skew en DPoPProofJwtDecoderFactory, luego comprueba la fórmula de tasa, aproximadamente maxRequestsPerKey / clockSkew por segundo por nodo, contra los números del issue. Terminado cuando la documentación indique el límite superior y el efecto de warm-up; el mensaje de log distinto es un cambio de código y debería separarse. DPoPAuthenticationTests muestra cómo sobrescribir los límites para una prueba.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

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

Lenguaje dominante
Java
Estrellas
9.7k
Forks
6.4k
Merge medio
1 d 22 h
PR fusionados (30 d)
49

Preparar el entorno

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de spring-projects/spring-security

Todos los issues de spring-projects/spring-security

Issues similares

Más issues de Java

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.