Okta API tokens

• gitleaks 8.30.1
• trufflehog 3.97.4
• Twin source SSWS authorization example · observed 2026-09-23 · the guide states "Authorization: SSWS 00QCjAl4MlV-WPXM...0HmjFx-vbGua", establishing the SSWS scheme and a value that begins with the literal 00. It backs a prefix twin only; the 40-byte body length and its alphabet stay tool-corroborated and the positive tier is unchanged

Okta's own "Create an API token" guide (developer.okta.com/docs/guides/create-an-api-token/main/, observed 2026-09-23) shows the token only in use — `Authorization: SSWS 00QCjAl4MlV-WPXM...0HmjFx-vbGua` — a provider-unique SSWS scheme and a value beginning 00, elided in the middle, with no stated length or alphabet. Both pinned tools pin the 00 prefix and a 40-byte body (42 bytes total): gitleaks 8.30.1's okta-access-token rule captures `00[\w=\-]{40}` after an okta keyword and an assignment operator, trufflehog 3.97.4's okta detector `\b00[a-zA-Z0-9_-]{40}\b` only when the same input also carries an Okta tenant domain (`*.okta.com`, `*.oktapreview.com`, `*.okta-emea.com`). They disagree only on "=" in the body; this contract, like the product, adopts trufflehog's narrower [A-Za-z0-9_-], so a body containing "=" is an intentional false negative and the family's alphabet twin records gitleaks's wider reading. A bare 00-prefixed value is not self-identifying: every positive here sits in one of the two contexts the product's gate recognizes — the SSWS authorization header (High) or a same-line okta keyword (Medium) — and a context-less value is an accepted product false negative not fixtured here. Tenant domains and OAuth client ids are the family's public-identifier control; Okta's JWT-shaped OAuth tokens belong to the jwt contract. redact-secret#315 (PR #681) froze the identical grammar on the product side.