We should create two SQL tables that together hold a record of all tokens generated by the service to allow us to audit any suspicious token and to report on various metrics associated with Tapis (e.g., total unique users who have generated a token).
We could combine into a single table, but that would increase the size of the table, close to doubling it, and the table size could be an issue long-term. It would also require the queries for various metrics (e.g., count all access tokens generated by a single user in a given tenant with a specific client) to be more complex because they would have to select only tokens of a specific type.
We should create two SQL tables that together hold a record of all tokens generated by the service to allow us to audit any suspicious token and to report on various metrics associated with Tapis (e.g., total unique users who have generated a token).
We could combine into a single table, but that would increase the size of the table, close to doubling it, and the table size could be an issue long-term. It would also require the queries for various metrics (e.g., count all access tokens generated by a single user in a given tenant with a specific client) to be more complex because they would have to select only tokens of a specific type.
AccessTokens table fields: token_jti (str) subject (str) username (str) tenant (str) client_id (str, FK) grant_type (str) with_refresh (T/F) -- whether a refresh token was generated create_time (time) revoked (T/F) revocation_time (time)
RefreshTokens table fields: same as AccessTokens table but without
with_refresh