Implementing OAuth Refresh Tokens that never expir

问题:

In the context of OAuth 2, how does one deal with refresh_token expiry, or lack thereof?

I'm using JSON Web Tokens (JWTs) as access_tokens with a short lifetime (expires after 20 minutes). From what I understand, this means I shouldn't have to store the access_token, only validate it (and consume the trusted information inside, like scopes).

However, I'm wondering how one implements refresh_tokens. In my research, I've seen that Google and others have refresh_tokens which are good forever, unless they are revoked, for any number of reasons. I assume this means the system must store all refresh tokens ever issued, so they can be marked as revoked.

Is this a problem when it comes to the storage of the tokens? It seems like you have a potentially infinite set of tokens which need to be stored and accessible forever.

Am I missing something? Are there best practices for implementing refresh tokens? Should they be (or NOT be) JWTs? Should the access_tokens also be stored, even when using JWTs? If so, is there any reason to keep them past their expiry time? What about JWT secrets changing over time?

回答1:

It was a good question, and refresh_tokens are in general wont expire, so that the application can generate new access token without asking the user to reauthenticate periodically,

But the application needs to enforce limitations for number of active refresh tokens allowed for a individual client, For eg:

Each OAuth client can have maximum of 20 active refresh_tokens only, if that limit reaches then the oldest token must be revoked and new one should be granted without rejecting the request.

And also if an refresh token is not consumed for a certain period say (6 months), then also the token needs to be revoked.

By this way, you can enforce limitation on refresh_token consumption, and here is the catch, this is how Google is also doing,

Refer Google OAuth2 Doc