API Subscription missing entitlement - feature_not_enabled - /api/v2/users/{user_id}/refresh-tokens

[oe155]

Hello,
I have found this endpoint which would be a valuable reference for my custom revocation management - Auth0 Management API v2

However, i seem to get this response when testing it

{
  "statusCode": 403,
  "error": "Forbidden",
  "message": "Subscription missing entitlement",
  "errorCode": "feature_not_enabled"
}

I am currently using the free-tier. It sounds like this is not available on the free tier? Assuming so, how would I track down tier I need to get this feature?

Thanks!

[dawid.matuszczyk]

Hi @oe155

Welcome to the Auth0 Community!

Thank you for posting your question, unfortunatelly the refresh token managment via Auth0 Managment API is only available for the enterprise tier or trial tenants. Manage Refresh Tokens with Auth0 Management API. If the feature is only available in higher tiers there’s a notification in the Documentation at the top of the page.

If that is something that you need to use, I suggest contacting our Sales department at Contact Us - Auth0. Thanks

Dawid

[oe155]

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!