am totally new to this Access Token and Refresh Token kindly correct me if am wrong in any place. To my knowledge Refresh Token Rotation means every time a user asks for AT (with valid RT) new pair of AT1 and RT1 will be given. So the next time user should use the new RT1 to renew the AT and will be given with new pair of AT2 and RT2.
My questions are:
To implement RT Rotation we need to store the RT in the database. So which RT do we need to store in the DB the older one or the newly issued RT. according to this, we need to store all the expired RT and need to check DB for every AT renewal request and if it is in the DB then we need to immediately invalidate the refresh token family. but if we do this we may need to store more amount of RTs in DB for a single user and this will be huge when considering all the users in a system. is it the correct way to implement RT Rotation if not what is the correct way to implement RT Rotation?
In this Documentation regarding the RT Rotation ( under Automatic Reuse Detection 4th point ), they mentioned like this immediately invalidates the refresh token family. So is this means every RT issued from initial authentication will have any same characteristics to identify them as one token family ( because it is mentioned as Refresh Token Family )
when a user logout from a system how we can invalidate the RT ?. I don't think simply removing RT from cookies is not the correct way, because for example if expire time of RT is one day and the user log out before its expire time still the RT is usable (unless we stored the previous RT in DB and check for the next renewal of AT) until its expiration time is reached. So how to solve this.
Ad.1. You can go either way - store the current RT in the DB and check if it's there, or store all the used RTs and check that the current RT is not there. Either will work. With the latter option you get that additional benefit of being able to revoke all RTs if you see someone trying to reuse an RT. On the other hand, as you pointed out, it may mean that the database will get substantially large. That's the kind of decisions you have to make when designing your system: I want to provide better RT security but I will need to spend more money on a larger DB.
Of course you don't have to keep all the tokens indefinitely. There is no added value in checking that someone reused a token from two years ago.
Ad. 2. Different systems can have different ways of deciding what is a "refresh token family", but I would say these are tokens issued for the given user and client. Maybe in some cases you could limit that to a given audience. In some Identity Server you will have some sort of consent object saved and tokens related to this consent object. This can also be a good candidate for identifying all the tokens you need to revoke.
Ad. 3. Access and refresh tokens are not meant to be used as a mechanism for session. The token just expires, there is no concept of a user logging out. If you really want this sort of feature you will have to keep information about tokens in the database together with an information whether the user has actively logged out. If so, then you can decline those tokens. It is a bit of a workaround, though, and usually using sessions will just be more straightforward in this case.