feat(jans-auth-server): Add configurable rate limiting for authentication endpoints to prevent brute-force attacks #12664

[yuriyz]

Description

feat(jans-auth-server): Add configurable rate limiting for authentication endpoints to prevent brute-force attacks

Target issue

closes #12664

Test and Document the changes

• Static code analysis has been run locally and issues have been fixed
• Relevant unit and integration tests have been added/updated
• Relevant documentation has been updated if any (i.e. user guides, installation and configuration guides, technical design docs etc)

Summary by CodeRabbit

• Refactor

  • Consolidated rate-limiting validation logic from the filter layer into a centralized service, removing per-endpoint registration request handling.

• New Features

  • Added feature-flagged rate limiting for the registration endpoint with per-key enforcement. Rate limit keys are derived from software statement or first redirect URI, enforced via in-memory buckets.

_{✏️ Tip: You can customize this high-level summary in your review settings.}

[mo-auto]

✅ Snyk checks have passed. No issues have been found so far.

Status	Scanner	Critical	High	Medium	Low	Total (0)
✅	Open Source Security	0	0	0	0	0 issues

💻 Catch issues earlier using the plugins for VS Code, JetBrains IDEs, Visual Studio, and Eclipse.

[coderabbitai]

Important

Review skipped

Draft detected.

Please check the settings in the CodeRabbit UI or the .coderabbit.yaml file in this repository. To trigger a single review, invoke the @coderabbitai review command.

You can disable this status message by setting the reviews.review_status to false in the CodeRabbit configuration file.

📝 Walkthrough

Walkthrough

The PR refactors rate limiting logic by relocating feature-flag guarded register endpoint rate limiting from RateLimitFilter to RateLimitService. RateLimitFilter now delegates all rate limiting to a single service call, while RateLimitService.validateRateLimit() handles request validation, body parsing, and per-key rate limit enforcement using SHA-256 hashing.

Changes

Cohort / File(s)	Summary
Rate limit filter refactoring jans-auth-server/server/src/main/java/io/jans/as/server/rate/RateLimitFilter.java	Removes internal rate-limiting logic, feature-flag guards, register request parsing, and ErrorResponseFactory injection. Delegates all rate limiting to rateLimitService.validateRateLimit(httpRequest) and eliminates the private validateRateLimit() method.
Rate limit service enhancement jans-auth-server/server/src/main/java/io/jans/as/server/rate/RateLimitService.java	Adds new public method validateRateLimit(HttpServletRequest) that includes feature-flag guarded rate limiting for /register endpoint. Parses Registration request body, derives SHA-256-based rate limit key from software statement or redirect URIs, enforces per-key limits via in-memory bucket, and wraps the request accordingly.
Test scaffolding expansion jans-auth-server/server/src/test/java/io/jans/as/server/rate/RateLimitServiceTest.java	Adds @Mock field for ErrorResponseFactory dependency to test class.

Estimated code review effort

🎯 3 (Moderate) | ⏱️ ~25 minutes

• Request body parsing logic: Ensure correct extraction of software statement and redirect URIs from Registration request
• SHA-256 hashing and key derivation: Verify hashing strategy and key generation logic for rate limit bucket lookup
• Feature flag integration: Confirm RATE_LIMIT feature flag behavior and short-circuit logic
• Request wrapping mechanism: Validate that wrapped request preserves original request properties and doesn't interfere with downstream processing
• In-memory bucket state management: Review bucket initialization, key management, and rate limit enforcement across invocations

Suggested labels

comp-jans-auth-server, kind-feature

Suggested reviewers

• yurem
• yuriyzz

Pre-merge checks and finishing touches

❌ Failed checks (2 warnings, 1 inconclusive)

Check name	Status	Explanation	Resolution
Description check	⚠️ Warning	The description is largely incomplete. It reuses the title, provides only the issue number, and has unchecked checkboxes for code analysis, tests, and documentation with no details provided about what was actually done.	Add implementation details explaining how rate limiting was implemented, confirm which tests were added/updated, and clarify whether documentation changes were made or confirm no docs impact.
Docstring Coverage	⚠️ Warning	Docstring coverage is 0.00% which is insufficient. The required threshold is 80.00%.	You can run @coderabbitai generate docstrings to improve docstring coverage.
Linked Issues check	❓ Inconclusive	The PR partially addresses the linked issue #12664. Code changes implement per-endpoint rate limiting with feature-flag protection, but the PR does not demonstrate admin UI configuration, comprehensive metrics/logging, or multiple scoping strategies (IP, user account, client_id), limiting compliance with all requested features.	Clarify in the description which requirements from #12664 are addressed in this PR and which are deferred to future work, or confirm that all features are implemented.

✅ Passed checks (2 passed)

Check name	Status	Explanation
Title check	✅ Passed	The title directly and accurately summarizes the main change: adding configurable rate limiting for authentication endpoints to prevent brute-force attacks, which aligns perfectly with the code changes in RateLimitFilter and RateLimitService.
Out of Scope Changes check	✅ Passed	All code changes are directly related to implementing rate limiting for the /register endpoint and integrating it into the filter chain, which is in scope with the linked issue #12664 objectives.

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[coderabbitai]

Actionable comments posted: 4

Caution

Some comments are outside the diff and can’t be posted inline due to platform limitations.

⚠️ Outside diff range comments (1)

jans-auth-server/server/src/main/java/io/jans/as/server/rate/RateLimitFilter.java (1)

44-50: Major: IOException bypasses rate limiting.

When an IOException occurs (e.g., reading the cached request body fails), the exception is caught, logged, and the request continues through the filter chain. This means rate limiting is completely bypassed for requests that trigger IO errors.

An attacker could potentially craft requests that trigger IO exceptions to bypass rate limits. Consider one of these approaches:

1. Fail closed: Return HTTP 500 or 429 on IOException
2. Apply stricter default rate limiting: Use IP-based rate limiting as fallback

🔎 Proposed fix - fail closed approach

         } catch (RateLimitedException e) {
             sendTooManyRequestsError(httpResponse);
         } catch (IOException e) {
             log.error(e.getMessage(), e);
-            chain.doFilter(httpRequest, httpResponse);
+            sendResponse(httpResponse, Response.Status.TOO_MANY_REQUESTS, TOO_MANY_REQUESTS_JSON_ERROR);
         } catch (Exception e) {

📜 Review details

Configuration used: Organization UI

Review profile: ASSERTIVE

Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between 181c408 and 5985016.

📒 Files selected for processing (3)

• jans-auth-server/server/src/main/java/io/jans/as/server/rate/RateLimitFilter.java (1 hunks)
• jans-auth-server/server/src/main/java/io/jans/as/server/rate/RateLimitService.java (2 hunks)
• jans-auth-server/server/src/test/java/io/jans/as/server/rate/RateLimitServiceTest.java (2 hunks)

🧰 Additional context used

🧠 Learnings (1)

📓 Common learnings

Learnt from: yuriyz
Repo: JanssenProject/jans PR: 12596
File: docs/script-catalog/tx_token/txtoken.md:21-27
Timestamp: 2025-11-19T13:23:56.185Z
Learning: In the Janssen project, yuriyz prefers to skip trivial improvements and nitpicks during code reviews.

⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (2)

• GitHub Check: sonar scan (jans-core)
• GitHub Check: sonar scan (jans-auth-server)

🔇 Additional comments (2)

jans-auth-server/server/src/main/java/io/jans/as/server/rate/RateLimitFilter.java (1)

24-26: Verify filter scope matches PR objectives.

The filter is registered only for "/restv1/register", but the PR objectives mention rate limiting for "/token, /authorize, /userinfo" endpoints. Confirm this limited scope is intentional.

Based on the PR description, this appears to be Phase 1 focusing on /register only. If that's the case, consider updating the PR title and description to reflect the actual scope delivered in this PR.

jans-auth-server/server/src/main/java/io/jans/as/server/rate/RateLimitService.java (1)

53-84: Clarify scope: rate limiting currently limited to /register endpoint only.

The commit message indicates "authentication endpoints" but implementation covers only /register. Confirm whether this is intentional Phase 1 scope or if the PR description should be updated to reflect the actual implementation scope.