Store all token pairs you will be using in the database.
I think it’s unlikely this will change, but it might, and we’ll either find out when they tell us or 5 minutes after everything breaks.
Are you using this instead of storing the authentication session in a database? In that case, you cannot log out other sessions.
But if it’s more convenient for you to store the user’s OAuth tokens in their client-side token to save a database lookup, that isn’t wrong.
I guess you are assuming that expired tokens will remain expired unless you receive another request that requires them? In practice, you will frequently delete tokens from the database, only to re-add them later.
Huh? I don’t understand deleting the cookies from the database. The cookies are stored in the user’s browsers, so you can’t anyway, but what are you storing in the database? I thought the purpose of putting all that information in the cookie is to avoid a database lookup.
In the worst-case scenario, where your whole application is compromised, not storing refresh tokens may limit the damage to some extent. On the other hand, you are supposed to be able to revoke refresh tokens, which will revoke all associated access tokens. But the documentation implies that Twitch does not support that and I haven’t tested it.
Do what works for you. Since you are concerned about security, I recommend using flowcharts, tests, and as simple code as possible.
IIRC, the rate limit is along the lines of “try to be reasonable”.
On the other hand, it provides additional flexibility to do things in ways that work best for your application. For example, if it would work for you, it may be much easier to use a single token for most of your work and let the user log in with tokens you only use once (for verifying they are a Twitch user and who they are) and then discard.