I think it’s deliberately undocumented to accomodate potential future changes.
It has already changed a couple of times in Vault history.
A long long time ago (like, back in the 0.x days) tokens were just UUIDs.
At some point they changed to have the
r. prefixes documented on the page you linked to, followed by 24 base62 characters.
But, if you’re using Vault Enterprise at these versions, and logging in to child namespaces, they get an additional
. and 5 more base62 characters of namespace ID added on the end.
Then Vault 1.10 came along and changed things again - the token prefixes gained an additional
hv, and all tokens except root tokens, got switched to a new format, in which the prefix is the same, but now everything after the prefix is base64 URL-safe variant without padding characters, encoding marshalled protobuf data. The changelog suggests the total length of such tokens will always be >= 95.
There is an environment variable feature flag, VAULT_DISABLE_SERVER_SIDE_CONSISTENT_TOKENS, to revert Vault 1.10 to the older token format.
But wait, there’s more… it’s deprecated and probably mostly forgotten, but still technically possible to create your own user-specified tokens as custom values!
For a newly implemented secret scanner, if you think you can assume most people will be using Vault 1.10 and not using VAULT_DISABLE_SERVER_SIDE_CONSISTENT_TOKENS, meaning you’d mostly be looking for
I left out recovery-mode tokens as they are inherently only useful during an interactive recovery session, so overwhelmingly unlikely to be committed whilst still valid.