Okay, thank you for the information, reference, confirmation.
Pardon my ignorance (im new to auth in general so still feeling my way around), but isn’t this ability to query refresh tokens for a user and revoke a token a primitive functionality to maintain a secure application?
For example, I’m prototyping an application that issues tokens to users for use in a web-interface and external scripting tools (i.e. public python api for my backend). For a user to maintain a “good security posture”, they should know what refresh tokens are still valid for their account.
I can track tokens as they are issued with my backend database; however, if my database and Auth0 database get out of sync somehow, a refresh token can “leak” (meaning Auth0 still thinks a refresh token is valid, but my backend database is not aware of it).
I see that the “refresh token rotation” could be an alternative to mitigating the “persistent access with leaked refresh token” risk here. However, I’m currently using the refresh_token itself as an identifier to track the token in my backend database. Which then means, my backend database needs to be a middle man for any refreshing of tokens. Is there a better recommended strategy to generically “identify” a token in my database.
I guess the crux of my statement is that, to minimize risk to “leaked” tokens, I have to attempt to mirror the state of the Auth0 database…which seems complex and error-prone (especially not desireable in the security part of an app 
).
Is there a technical limitation/financial reason/etc why Auth0 does not provide the refresh token list/revoke functionality for non-enterprise?
I appreciate your patience and any guidance here while I learn!