Guidance for backend Refresh Token management

[oe155]

Ready to post? First, try searching for your answer.
Hello,
In a previous post, I was asking about the /api/v2/users/{user_id}/refresh-tokens endpoint. I am still stuck on what the best practice should be, as alluded to in my follow up question.
As that post was closed, I’m migrating to a new post with the follow up. (previous post: API Subscription missing entitlement - feature_not_enabled - /api/v2/users/{user_id}/refresh-tokens)

@oe155

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!

Thanks for any assistance!

[nik.baleca]

Hi @oe155

Thank you for coming back to the Auth0 Community with an update to your initial post.

I am sorry about the late reply to your inquiry.

As you have mentioned in your initial post, my personal recommendation would be to implement Refresh Token Rotation. This is indeed a way in which you will be able to mitigate and take care of leaks in your refresh tokens since it has automatic detection when a refresh token is reused. This way, you will not need your own database to be the “middle man” between your application and Auth0. If you still wish to save this data in your data base, you should be able to store any provided refresh tokens that were used for rotation.

You can take a look at our blog related to Rotating Refresh Tokens as well in order to learn more about implementing them with your application.

If you have any other questions regarding the matter, feel free to leave a reply or post again on the community page!

Kind Regards,
Nik