Hi @sarayourfriend, this is my first attempt at navigating this issue, many thanks for the headstart! I was able to get the tests in test_auth.py to pass by making a simple tweak in the rate limiting test parameters. Again, this was more like a workaround as my current knowledge of how everything ties together is still pretty limited so feel free to point out what can be improved.
Also, I kept running into some weird recursion issues whenever I added the rate-limit-checking condition in conf/oauth2_extensions.py/OAuth2Authentication/authenticate() not sure why that was happening or how to fix yet.

Furthermore, I have a few questions as to how things work. First is, how are we able to get the new RevokedOAuth2IdRateThrottle to work without necessarily overriding allow_request to return False in the new class(this is my assumption though cos you didn’t explicitly point it out). Also, how are we able to apply this new rate limiting rule without also explicitly including it in the throttle_classes of the relevant views/viewsets, I recall you mentioned this can somehow be done dynamically through Django admin but essentially I’d like to know how it works under the hood.

Also, how are we able to apply this new rate limiting rule without also explicitly including it in the throttle_classes of the relevant views/viewsets, I recall you mentioned this can somehow be done dynamically through Django admin but essentially I’d like to know how it works under the hood.

The questions you're running into are good ones, and I think expose the fact that maybe a throttle isn't the right place to handle authorisation. The use of a throttle was a bit of a hack, and actually I'm realising that a new throttle class isn't necessary at all, because the revoked rate_limit_model would never actually allow any request at the start of the request and throttle classes would never run. That authentication class runs before throttling (which makes sense, because throttling depends on authentication to identify the rate limit).

For what it's worth, if we did need the throttle class to run, it would need to be added to the DEFAULT_THROTTLE_CLASSES tuple here:

We don't define specific throttle classes on any routes except on a few routes that are more restrictive like thumbnails.

However, with your questions in mind, it really seems to me a throttle scope isn't the right choice, and a new boolean field on ThrottledApplication, checked in the same authentication method we were checking the rate limit model, would be clearer. There wouldn't be these dangling questions of "how does this throttle class get used" for a throttle class that indeed, never would.

I kept running into some weird recursion issues whenever I added the rate-limit-checking condition in conf/oauth2_extensions.py/OAuth2Authentication/authenticate() not sure why that was happening or how to fix yet.

This makes sense, I hadn't realised it would happen, but I see now that it's unavoidable with the exact conditional check I suggested.

The problem is that request.auth is a property that runs the authentication schemes for the application.

https://github.com/encode/django-rest-framework/blob/HEAD/rest_framework/request.py#L247-L256

https://github.com/encode/django-rest-framework/blob/HEAD/rest_framework/request.py#L377-L394

Those are the two code places to keep in mind.

So the authentication runs the first time some code accesses the request.auth property. The authentication routine includes calling into OAuth2Authentication::authenticate to do the authentication. But then in there, I suggested we access request.auth... This access request.auth in the middle (as it were) of request.auth already trying to resolve!

We can get around this by knowing that authenticate returns a tuple of user, auth, that each get assigned to the respective properties on request. So in the authenticate method, request.auth is result[1] would eventually be true. Instead of keeping result as an anonymous result, we can unpack the tuple knowing that the rest framework authentication API is stable. Then instead of request.auth.application, use auth.application.

diff --git a/api/conf/oauth2_extensions.py b/api/conf/oauth2_extensions.py
index 2ece1b497..4ebe41a45 100644
--- a/api/conf/oauth2_extensions.py
+++ b/api/conf/oauth2_extensions.py
@@ -11,7 +11,7 @@ class OAuth2Authentication(BaseOAuth2Authentication):
     keyword = "Bearer"
 
     def authenticate(self, request):
-        result = super().authenticate(request)
+        user, auth = super().authenticate(request)
         if getattr(request, "oauth2_error", None):
             # oauth2_error is only defined on requests that had errors
             # it will be undefined or empty for anonymous requests and
@@ -19,7 +19,11 @@ class OAuth2Authentication(BaseOAuth2Authentication):
             # `request` is mutated by `super().authenticate`
             raise AuthenticationFailed()
 
-        return result
+        if application := getattr(auth, "application", None):
+            if application.revoked:
+                raise PermissionDenied()
+
+        return user, auth
 
 
 class OAuth2OpenApiAuthenticationExtension(TokenScheme):

To summarise: your questions are excellent and expose a deep problem with my suggested implementation. Instead of a new throttle class, let's add a boolean revoked to ThrottledApplication, and check that in the authenticate method. I think the Django admin for ThrottledApplication will automatically allow making changes to revoked, but if not, here's where that model's admin is declared:

Sorry for leading you astray with my implementation suggestion! Please let me know if this new approach makes sense, and thank you very much for asking these questions. I wouldn't have realised the problem with my suggested implementation otherwise.

Hi @sarayourfriend, Once again, thank you for this detailed insights and explanations. Glad to hear my question helped make things more clearer. And yes, your new suggested approach is very clear and intuitive.

Hi @sarayourfriend all suggested changes have been implemented and I can confirm that things work as expected locally. Would go ahead and undraft this PR.

I can see this response leading to folks generating new credentials. Maybe something like

To be fair, either response would provoke a bad actor to do so; this is really just a signal of "we're aware of your behaviour" more than anything.

I don't think we necessarily need to give the reason why the request was forbidden, and we should discuss internally what the policy would be if someone asked us directly about a specific client application.

@madewithkode this just needs a rebase to resolve the conflict. I'll do that later during my workday today (it's 10 AM here for me) if you don't get to it first, then I'll merge afterwards.

Thanks again!

@sarayourfriend rebased and pushed the changes.

Thanks! Sorry I wasn't able to get to it yesterday in the end. Merged 🚀