There are Access Tokens and Refresh Tokens.
The Access Token is typically short-lived (think 30 or 60 minutes), and there is no reason to persist it after it has expired. It has no use to anyone.
The Refresh Token is required to obtain a new Access Token, and is typically long-lived; at least as long as an active session.
If an attacker gains hold of a Refresh Token, they have all the access that the user would have if they had logged in with that token. However, they have access to session(s) for which that particular Refresh Token authorizes them. (Meaning that, if the token was granted for less than normal privilege for that user, the attacker would be at the same lowered privilege).
Also, since it's not a hashed password, they cannot derive the plaintext password from it with rainbow tables.
A Refresh Token can be retracted at any time, without requiring the user to change their password.
From a security point of view, using a Refresh Token instead of requiring the user to log in again protects against shoulder surfing. The drawback is that if the attacker has physical access to the device that contains the Refresh Token, they don't need to authenticate either.
Be careful when deleting the Refresh Tokens. An expired Refresh Token has no use to anyone, and can be safely deleted. But deleting an active Refresh Token requires users to log in again; causing them unnecessary inconvenience.
Make sure the database containing the active Refresh Tokens is properly secured. They are typically not hashed like passwords are.