Hey @thibaultcha!
I’m writing an application that uses Kong to help with user authentication. I have an API that has a sign up route that will create a new Kong Consumer for the user and there is also a log in route that will check a username/password in my database. If the password and username match, then my API will create a Kong JWT credential on the Kong Consumer object, use those values to issue a JWT token, and finally return it to the client.
My use case is that when a user clicks the forgot password button and updates their password, I want to delete all the existing JWT credentials as a way to log them out of all their current sessions. Currently, I don’t see a way to delete all the existing credentials in one call, so I’m just paginating through the list credentials route and calling delete on each one. Over time, as a user logs into different computers or mobile devices, they could end up having a lot of credentials, which just adds a lot of extra network traffic.
I would love a route like DELETE /consumers/:consumerId/jwt or something along those lines where I could delete all the credentials with one network call, and I’m happy to write the code for it given we can agree on what the route should look like.
Any thoughts on this? Does this use case make sense? Or am I completely missing an easy way to do this?
Hi @aloisbarreras,
Historically, we’ve been trying to stay away from “Bulk delete” operations in the Admin API. For starters, such DELETE /resources endpoints are generally considered as not being RESTful. If you make a quick search online, you’ll find plenty of literature debating the topic. Issues arise around cache-ability, possible timeouts in processing the request, etc…
Arguably, a case could also be made that bulk deletion of entities could be considered dangerous. Although this certainly applies more to the bulk deletion of Route entities (preventing Kong from proxying any traffic at all, if maliciously or erroneously executed), than to client credentials.
I do see the value in a bulk deletion endpoint for client credentials (note that deleting and re-creating a Consumer will work as well, since its associated credentials will be deleted; but I do understand the burden). Only before introducing the concept to Kong, it’d be valuable to establish the proper paradigms that will define how Kong will deal with bulk deletions, and avoid setting harmful precedents that tend to spread around (if we add bulk deletion of JWT credentials, other folks will request bulk deletion of other types of credentials, and so on). Again, online literature on the topic explores various solutions.
What would be your proposal? Happy to hear it or that of any other Konger who happens to stumble upon this thread 
Hey thanks for getting back to me so quickly!
As for deleting a Consumer, I wanted to stay away from that because then I would have to also re-add them to any ACLs and re-add and rate-limiting and so and so forth for anything added to a Consumer object. That just seems like a lot of extra steps and extra points of failure during a request that could be solved by deleting the credentials instead of the whole Consumer object.
I totally agree that a bulk delete isn’t RESTful. I wanted to open a discussion to try to figure out a good way to achieve this. I will go through some ideas I have and try to address some of your concerns.
I would argue that there are some edge cases where deviating slightly from being purely RESTful is fine. For example, a commonly debated scenario is handling a user requesting a password reset with a RESTful API. There is a pretty good SO discussion about it here. In my opinion, yes 99.99% of the time stick to the REST best practices, but every once in awhile it might be okay to have an API route that isn’t purely RESTful as long as it is clearly documented as to what it does.
As a real world example, it looks like Apigee offers the functionality I’m looking for here. Their route is POST /v1/organizations/{org_name}/oauth2/revoke, and you can pass in a userID to revoke all tokens associated with that user. We could easily adapt that similar signature to Kong at something like POST /consumers/:consumerId/jwt/revoke.
With this suggestion, that should also mitigate your fears of accidentally bulk deleting something you shouldn’t (I’m sure I would totally accidentally do that). And I agree that enabling a bulk delete route would open the floodgates to everyone wanting a bulk delete route. Maybe something like this is a good compromise?
I’d love to hear your thoughts!
Yes, a POST /.../<credential>/revoke seems like an reasonable proposal to me. And then I suppose it would return HTTP 202 as well and start some background job for the bulk deletion?
I for one would welcome more opinions on this sort of introduction to new paradigms in Kong, just to make sure we are not missing a specific use-case or concern.
@aloisbarreras You are probably already familiar with it, but if not, have a look at our CONTRIBUTING.md file to get you started with our git and Pull Request workflow