That's something I've came across in a couple articles about OAuth 2: when it comes to persisting refresh tokens to database some authors prefer to store access token as well, or at least mention it as something you should do. And when it comes to granting access based on
refresh_token a ticket is being picked up from database, deserialized, updated and sent to the user with a new refresh token.
Here is an example of
RefreshTokens table, where
ProtectedTicket column keeps serialized
access_tokens issued to the user:
So far I can think of at least 3 reasons against this approach:
Isn't it a security threat when you are keeping user's access tickets, just waiting for someone to grab them, and reuse for unsuspicious resource server? One-way hash can't be used, since we need to deserialize, update and send it back to the user, and we don't want to keep valid access tokens as well.
For instance, you want to update encryption key used to serialize/deserialize your ticket once in a while just in case. If you don't want your users to be logged off once their
access_tokenexpires, you have to care about updating those persisted tickets.
You have to write a chunk of code depending on how concerned you are about #1 and #2. Maybe even you implement some dirty hacks around you OAuth framework as it might not provide extensibility points you will need.
So the questions is, why do you want to do all that? What kind of advantage that should give to really make it worth all the hassle? Isn't it easier, safer and more maintainable just to make a brand new ticket once you've verified