Hello @nobe4 -- happy to take such a PR. Do note that we've disabled the "new" Vault 1.9.x format tokens by default in #298 -- SSCTs still exist but one has to manually opt in as the functionality isn't used without Vault Enterprise clustering that OpenBao lacks. (So only s., b., and r. tokens are to be expected.)

That said, IMO, I'd prefer tokens be treated as mostly opaque. Token size changed, so I think the regex may not match both short and long token formats, I'd expect a range operator or two explicit sizes based on types. My 2c., but I saw a lot of pain caused by adding SSCTs in system design that was too closely coupled to token size when perhaps being more forgiving would be better. :-)

Hi @cipherboy thanks for your swift answer!

So only s., b., and r. tokens are to be expected.

Gotcha, nice ⭐

I'd prefer tokens be treated as mostly opaque
being more forgiving would be better. :-)

I mostly agree with this. In the event that we want to "look for" OpenBao tokens on an automated basis, to prevent leaks, would a specific regexp work?

How about this more relaxed one? [sbr]\.[a-zA-Z0-9]{24,}

I think that should suffice. Note here: https://developer.hashicorp.com/vault/docs/faq/ssct#q-what-token-changes-does-the-server-side-consistent-tokens-feature-introduce

For the new token format (hv[sbr].) that could be above 95 characters. :-)

Amazing, where do you think this should be documented? I am happy to open a PR :)

I think your original location (https://openbao.org/docs/concepts/tokens/) is good :-) This repository has the same documentation structure as upstream so I think you'll find the patch should port somewhat cleanly :-)