Loading
Add a validity check for npm access tokens
What does this MR do and why?
Adds a validity check for npm access tokens (npm_ + 36 alphanumerics, per the detection rule). The client and its spec are generated from the committed vendor definition by the verifier generator (#619508 (closed)); this is the first vendor produced with it.
Verification is a GET to https://registry.npmjs.org/-/whoami with the token as a bearer credential.
Status mapping evidence
| Code | Mapped | Evidence |
|---|---|---|
| 200 | active | live-verified 2026-10-01 with real granular tokens: read-only, bypass-2FA unchecked, and org-only-scoped tokens all return 200, so no live configuration can misreport |
| 401 | inactive | probed: garbage token and missing auth return 401; live-verified 2026-10-01: a revoked token returns 401 immediately |
| 429 | rate_limit | standard npm registry rate limiting |
| 500/502/503/504 | network_error | retryable service errors, matching the GitHub/Stripe clients |
| 403 | unmapped (unknown) | live-verified 2026-10-01: a live token with an IP allowlist excluding the caller returns 403, so restricted-but-live tokens degrade to unknown, never inactive |
Live verification completed 2026-10-01 (all test tokens revoked afterwards):
- A freshly created granular token matches the detection pattern
\Anpm_[A-Za-z0-9]{36}\z(length and character-class verified; npm removed legacy tokens 2025-11, so the rule covers current tokens). - Valid read-only token -> 200.
- Revoked token -> 401.
- Live token with an IP allowlist excluding the caller -> 403 (unmapped -> unknown; the mapping's never-false-inactive invariant holds).
- Live token without bypass-2FA -> 200 (OTP enforcement applies to publishing and account actions, not authenticated reads).
- Live token scoped to an organization only, with no package access -> 200.
Related to #631598 (closed).
MR acceptance checklist
I have evaluated this MR against the MR acceptance checklist.
Edited by Serena Fang