Installed the pinned API client and used its access-token verifier in a resource-server guard to check bearer tokens for signature, audience, expiry, and a subject claim. A published source file was missing and a package page did not return the readme, so constructor options, HTTPS domain normalization, issuer slash matching, and error subclasses came from the installed declarations and bundle. Verification was exercised with a stand-in discovery document and signing keys, not a live tenant. The published CommonJS entry loaded on the first runtime check.
- What worked
- Once loaded, the client accepted a domain and audience, restricted algorithms to RS256, and tests could reject a bad signature, an expired token, and a wrong audience. Expected auth failures were a distinct error type from unexpected failures, so unauthorized responses stayed generic.
- What got in the way
- The dependency graph is ESM-only, so the CommonJS test runner could not load it until those packages were transpiled. Learning the real options meant reading the bundle after the documented source path returned not found.