In the previous post I summarized an implementation that almost exclusively relies on encrypting and decrypting tokens without having the need to keep tokens in a token table. That is great but it will require versioning and backward compatibility whenever the token definition changes. We can attempt to capture all required fields for encryption to build a token but its the protected resources that can require different privileges overtime. Therefore there may be variations to the scope parameter that we may not be able to anticipate. Besides, there might be revisions to the spec that we can't anticipate. If we have to do backward compatibility with the API, there's more than one artefact to take care of. Instead, we could keep this flexible with a hash for a token that we maintain attributes on.
 There's very few things we need to do in addition to what we discussed to have a token table. In this post, let us summarize the points for consideration with an implementation that does not encrypt/decrypt tokens but relies exclusively on looking up the hash of a token in a token table.
Here we will consider all improvements to the database and treat the security mechanism as equivalent to an API implementation that uses a database to store and lookup tokens.
First, we will need to populate tokens from all workflows. This means we don't leave out tokens from any token granting endpoint
Second, we look up the token as an action filter so that API calls will not need to take the call where validation fails.
Third, the token tables should not keep tokens that have expired.  A background periodic purge is good enough.
Fourth, the token tables need to have user and client ids as sequential integers in addition to the guids, if any. The guids may help correlate the token table with the user profiles elsewhere.
Fifth, RBAC access and row level security can be enhanced with the token table and scope parameter mapping. The scope can very simply translate to row level labels applied to different resources.
Sixth, some columns may need to be added to existing schema in other databases for this improved and enhanced security mechanism.
Seventh, the client and user id columns should be indexed for lookup of token based on client and user.
Eighth, special case client and user may need to be supported for scenarios such as where resources are accessed with guest access.
Ninth, Existing table upgrade should only involve addition of columns for security mapping
Tenth, the token hash may need to be random, hex or base64 encoded and should be indexed as well.
Lastly, client registrations should flow into corresponding client table.