oauth-1.0a

oauth-1.0a is a small, dependency-free JavaScript library that computes OAuth 1.0a Protocol Parameters (oauth_consumer_key, oauth_nonce, oauth_signature, oauth_timestamp, and friends) for a given request, so you can hand them to whichever HTTP client you already use — request, fetch, jQuery.ajax, or a raw XHR call. It doesn’t ship its own HTTP transport; it only builds the base string, signs it, and returns either a plain data object or a ready-to-use Authorization header.

Because OAuth 1.0a’s signing algorithm depends on cryptographic hashing but the library itself doesn’t hard-code a crypto implementation, hash_function (and optionally body_hash_function) is injected by the caller. That keeps the library usable in Node (via the built-in crypto module) and in the browser (via CryptoJS or any HMAC implementation), and lets consumers swap signature_method between PLAINTEXT (the default), HMAC-SHA1, and HMAC-SHA256 without touching the library’s internals.

It’s been maintained since 2014 and is explicitly tested against real-world OAuth 1.0a services — Twitter, Bitbucket, Flickr, and OpenBankProject — which is a meaningful signal given how finicky the spec’s percent-encoding and parameter-ordering rules are in practice.

What You Get

• A framework-agnostic .authorize(request, token) call that returns signed OAuth data as a plain object, ready to merge into query params, form data, or JSON
• A .toHeader() helper that converts signed OAuth data into a ready-to-send Authorization: OAuth ... header, including optional realm support
• Pluggable hash_function / body_hash_function so signing can use Node’s native crypto, CryptoJS in the browser, or any custom HMAC implementation
• Support for PLAINTEXT, HMAC-SHA1, and HMAC-SHA256 signature methods, plus configurable nonce length, parameter separator, and the last_ampersand quirk some providers require
• Optional oauth_body_hash generation for providers that require signing the request body itself, not just its parameters
• Bundled TypeScript type definitions (oauth-1.0a.d.ts) for typed consumers without needing @types/oauth-1.0a

Common Use Cases

• Signing requests to legacy OAuth 1.0a APIs (Twitter’s v1.1 API, Bitbucket’s OAuth 1.0a endpoints, Flickr, OpenBankProject) that never migrated to OAuth 2.0
• Building a lightweight OAuth 1.0a client on top of request, axios, fetch, or jQuery.ajax without pulling in a full OAuth client/consumer framework
• Server-to-server integrations where a service still requires the three-legged OAuth 1.0a handshake for request tokens, access tokens, and signed API calls
• Browser-side OAuth 1.0a signing for extension or gadget-style contexts (Chrome/Firefox extensions, Google Gadgets) where cross-domain XHR restrictions make a signed direct request the practical option
• Prototyping or maintaining integrations with older internal or partner APIs that were built against the original OAuth 1.0a spec

Under The Hood

Architecture The entire library is one ~380-line CommonJS/UMD-style module (oauth-1.0a.js) exposing a single OAuth constructor and a flat set of prototype methods. The design follows the OAuth 1.0a spec almost procedurally: authorize() assembles the base oauth_* parameters, getSignature()/getBaseString()/getParameterString() build and percent-encode the signing base string per RFC 5849, and getSigningKey() concatenates consumer and token secrets. There’s no internal state beyond the options passed at construction, no event system, and no abstraction layers — every method is a pure transformation of its inputs, which keeps the signing logic easy to audit line-by-line against the spec but means there’s no separation between “protocol logic” and “library surface”: they’re the same fourteen functions.

Tech Stack Runtime dependencies are zero — the package works in both Node.js and browsers by deliberately not importing crypto or any hashing library itself; callers inject hash_function/body_hash_function instead, which is how the same file runs unmodified in a <script> tag or a Node require(). Development tooling is dated but coherent for the library’s age: Mocha + Chai for tests, Istanbul for coverage, Coveralls for reporting, dotenv to load service credentials for integration-style tests, and a Makefile wrapping the whole cycle. TypeScript consumers get a hand-written .d.ts file shipped alongside the JS rather than a build step. There’s no bundler, no transpilation, and no CI configuration checked into the repo itself (the README’s CI badge points to an external Semaphore project).

Code Quality Testing is genuinely thorough for the library’s size: test/options/ exercises each configuration flag (nonce length, parameter separator, realm, last_ampersand, multiple query-string values) in isolation, test/services/ runs signature generation against real payloads captured from Twitter, Bitbucket, Flickr, and OpenBankProject, and test/oauth_body_hash.js covers the newer body-hash feature separately. Error handling is minimal but intentional — the constructor throws synchronously on missing consumer or hash_function rather than failing silently later. The code is written in pre-ES6 style (var, manual for loops, .bind(this) closures) with no linter or formatter configuration, and there are no type annotations in the implementation itself (typing is retrofitted via the separate .d.ts file for consumers only).

API Design The public surface is deliberately tiny — construct once with consumer + hash_function, then call .authorize(request, token) and optionally .toHeader() — which means most integrations need only a few lines of boilerplate. Options are all sensible-default, opt-in (signature method defaults to PLAINTEXT, nonce length to 32, last_ampersand to true), so simple cases stay simple while providers with unusual requirements (body hashing, custom realms, non-standard separators) are still reachable without forking the library. The README documents every option and includes copy-pasteable examples for both request and jQuery.ajax, which lowers the cost of the one non-obvious step: writing the hash_function callback yourself.