I appreciate you taking the time to look into this Michael, and I understand the reasoning behind never deleting access tokens. However this causes some problems in our use case, and I suspect we may not be alone in that. There is also another problem which helps compound the first one, which is that when you fetch the list of tokens via the API, you will only get a maximum of 20 returned, and there doesn’t seem to be any provisioning for paging, meaning if you have over 20 tokens, there’s no way to be sure you can revoke them all via the API.
To further add to the confusion, pressing the “Revoke” button in the UI actually does seem to delete - not just revoke - the token. So we have a situation where the “Delete” function via the API actually performs a revoke, and the “Revoke” function in the UI actually performs a delete. I understand that it’s not always easy to maintain consistency in these sort of things when building systems, but I would just like to point out that this is not ideal from a user experience perspective and it would probably be good if it was changed somehow.
To go back to the more central issue, I understand that it might be desirable to never allow deletion of tokens, and I think our use case would be resolved if it was possible to query the token list with a parameter filtering out all of the revoked tokens. I understand that it’s possible to do this client side, but that results in a lot of data being shuffled needlessly which slows down operations.
Something would probably also have to be done for the list of tokens in the UI, to keep it manageable when it contains hundreds or thousands of tokens.