Rate limit API calls via API keys (or lack thereof)

[pveeckhout]

Is your feature request related to a problem? Please describe.
Our Spring Boot application's REST API is currently open for unlimited usage and there is no way to track and limit requests made by individual users. This exposes our system to the potential risk of being overwhelmed by a high number of requests, which can lead to service degradation or even a total outage.

Describe the solution you'd like
We need to implement a rate limiting system that uses API keys for authentication. Each registered user will be assigned an API key which they must provide with each request. The rate limiting system will then ensure that each API key can only make a certain number of requests within a specified time period.

In addition to this, we should also have a rate limiting system in place for public (unauthenticated) access to our API. This ensures that even users without an API key cannot overwhelm our system with requests.

Describe alternatives you've considered
We have considered implementing a simple IP-based rate limiting system, but this approach does not provide the granularity of control that API keys offer. Additionally, it can lead to unintended blocking of users if multiple users are connecting from the same IP address (e.g., users on a shared network or VPN).

Another alternative that we considered was implementing rate limiting using JWT (JSON Web Tokens) or Basic Authentication. In this scenario, upon successful authentication, the server would return a token that the client can use for subsequent requests. This token would also incorporate a user's rate limit status, allowing us to control the number of requests the user makes.

JWT tokens have the advantage of being stateless and self-contained, meaning they contain all the necessary information for authentication without needing to query a database. They also provide a high level of security when properly implemented.

However, one of the significant disadvantages of this approach is the user experience. Tokens, especially JWTs, have an expiration time for security reasons. When a token expires, the client needs to re-authenticate to get a new token. If the expiration time is short, this could result in a lot of friction for the client, as they would have to frequently re-authenticate. This can be somewhat mitigated with refresh tokens, but that adds another layer of complexity to the system.

Basic Auth also has its drawbacks. While it's one of the simplest methods to implement, it doesn't inherently support any form of rate limiting or request quota out of the box. Additionally, it's less secure than JWT, as it requires sending the user's credentials with each request unless combined with other mechanisms like tokens.

These factors led us to the conclusion that while JWT and Basic Auth could be used for rate limiting, the impacts on user experience and the additional complexities required to make these solutions work effectively make them less appealing than the API key approach. API keys provide an effective way to manage request quotas per user, and they do not need to be refreshed periodically like JWT tokens, offering a better balance between usability and control.

Another option is to use an off-the-shelf API gateway service that includes rate limiting features, such as AWS API Gateway or Google Cloud Endpoints. However, these services incur additional costs and may not provide the flexibility that we need for our specific use case.

Additional context
Implementing this feature will require integration with a rate limiting library (e.g., Bucket4j) and potentially changes to our user registration and authentication system to generate and validate API keys. This feature is a crucial aspect of our system's reliability and should be prioritized accordingly.