Claim-based rate limiting

[ArchPratik]

New Feature

Extracting claims from the token and use as a Client ID in the rate limiting.
Suggesting a new feature to implement the rate limiting based on the claims in the token.

Motivation for New Feature

Current rate limiting is based on the Client ID passed in the header from the request. There are chances that anyone can manipulate the request by updating headers and using APIs without any restriction.

So, instead of depending on the consumer to provide the Client ID in the header, we can use the claims from the token. Which is more secure and not modifiable. Considering this, a rate limit will be applicable for authenticated endpoints only.

Specifications

• Version: 18.1.0
• Platform: .NET 6

[raman-m]

@ArchPratik commented on Jul 18, 2022

Hi Pratik!
Welcome to the Ocelot world! 🐅

After team discussion we've decided to accept the issue! We agree that current Header solution is ugly.

• ClientRateLimitMiddleware.SetIdentity

We must switch to Remote IP to detect client's identity for anonymous routes...

I have no idea when we will start development, I hope in January'24. We still have a couple of professional senior developers who write high quality code... So, any your contributions are really welcomed!

[evilz]

Hello all,
Does someone work on this ?

What is the specification for the configuration if we want to use a claim value as clientId ?

Let me know if I should work on this ;p

[ArchPratik]

Hi Raman,

Thank you for accepting this proposal. I Apologise, for the delay in reply.

I am ready to work on this improvement, but let's clear the scope of this feature first.

I was suggested to implement claim-based rate-limiting for authenticated routes. For anonymous/unauthenticated routs we can relay on Remote IP as you suggested. Let me know if any changes in these requirements.

[evilz]

I think we should add a new property in RateLimitOptions like
ClientIdClaim or just Claim
If this property is set, it will try to get the value from Authorization header to override current clientId.

Seems good to you ?

[raman-m]

@ArchPratik You are assigned! Please start development!

I was suggested to implement claim-based rate-limiting for authenticated routes. For anonymous/unauthenticated routs we can relay on Remote IP as you suggested. Let me know if any changes in these requirements.

Correct! But why not do discuss more?..
What about options model?
Also, a callback for Rate Limiter will be a good design and extensibility approach...
And because the community worries about security, let's brainstorm security topics more. I can invite a rest of the team here...