Supabase tokens

• Provider documentation opaque key: sb_secret_ + 22-character random part + _ + 8-character checksum · observed 2026-09-24 · the self-hosting page states that opaque keys are sb_secret_<22-char-random>_<8-char-checksum> and "use the same format as the platform", and supabase.com/docs/guides/api/api-keys documents the sb_secret_ prefix and sb_publishable_ as "safe to expose online"; the base64url body alphabet and the sha256 checksum construction are provider code (supabase/supabase docker/utils/add-new-auth-keys.sh), not documentation, and the hosted checksum input is unconfirmed
• Reference 1
• Reference 2

Re-reviewed 2026-09-24 (#207, research #231) against the documented grammar instead of the empirical route. The earlier T0 record (#127, following #45) waited for Supabase's own documentation to state one body grammar; the self-hosting page now does (22 + _ + 8, "the same format as the platform"). The detector-coverage shape-1 positives were first generated as sb_secret_ plus 40 alphanumeric characters (no inner _), before that grammar was documented, and so fell outside it; they were wrong fixtures rather than a support claim and were regenerated in the documented 22 + _ + 8 layout (#213). The pinned TruffleHog supabasetoken detector matches the separate sbp_ management-token prefix, not sb_secret_, and is no longer cited; neither pinned peer has an sb_secret_ rule (betterleaks and kingfisher ship sb_secret_[A-Za-z0-9_-]{31}, unpinned). The product's floor (at_least(20, is_alnum_dash), redact-secret#515) is looser than this grammar. Twins mutate only documented properties: the public sb_publishable_ prefix, the 22/8 segment widths and the positional _ delimiter. The checksum is provider code and not part of the pattern, so no checksum-only twin is scored; the CLI's public local-dev constants are never used as fixtures.