The oauth gem implements OAuth 1.0a clients and servers for Ruby

The gem targets 1.0a while staying usable with 1.0 providers

OAuth 1.0a is the errata that became RFC 5849, and this library takes the 1.0a behaviour as its target while remaining compatible with providers that still behave like classic 1.0. That dual stance is stated plainly in the README, and it is the single most useful thing to know before choosing the gem.

The library covers both sides of the protocol. It is a RubyGem for implementing OAuth 1.0 or 1.0a clients and servers, so the same dependency serves an application that talks to a provider and an application that acts as one.

Where OAuth 2 is concerned, this is explicitly not the tool. The README points to the sibling oauth2 gem for OAuth 2.0, 2.1 and OIDC clients, and that sibling lives on a different host, GitLab, rather than in this repository. There is a second sibling, oauth-tty, which is the command line version of OAuth 1.0 and 1.0a.

The provenance matters too. The README notes that Ruby OAuth has been maintained by a number of people over the years, and that the primary maintainer since 2020 is Peter Boling. A protocol library that is going to sit between your application and a provider benefits from a long history of maintenance, and this one has both.

The specification references are given directly, the OAuth 1.0 core specification, RFC 5849 sections 5 to 7 and the 1.0a security errata, so the behaviour described in the README can be checked against the standard.

oauth_callback defaults to the out of band value

The first behavioural difference between 1.0 and 1.0a that the README documents is the callback.

In 1.0 the callback was optional in practice, and some providers accepted flows without one. In 1.0a the consumer should send oauth_callback when obtaining a request token, or explicitly use the out of band value, the string oob. This gem's rule is that if you do not pass oauth_callback, it defaults it to oob, and you can opt out by passing exclude_callback: true.

That default is a considered choice rather than an oversight. Many providers still work in a plain browser flow where the callback is returned to a URL the provider redirects to, and forcing one would break those providers against a library whose stated goal is compatibility with classic 1.0 behaviour. The opt-out flag exists for the opposite case, where a provider is strict about the callback being absent.

The practical guidance in the README is specific about the three legged flow: always supply oauth_callback when calling consumer.get_request_token, and include oauth_verifier when calling request_token.get_access_token. For command line or non-HTTP clients it recommends the out of band value as the callback and prompting the user to paste back the displayed verifier.

So a first integration in this library looks like building a consumer, calling get_request_token with an explicit callback where the provider demands one, and then exchanging the request token for an access token with the verifier in hand. The API surface is the classic OAuth object model: a consumer holds the credentials, a request token represents the pending authorization, and the access token is the result.

oauth_verifier is carried through helpers and request proxies

The second documented difference is the verifier. In 1.0 it did not exist. In 1.0a, after the user authorizes, the provider returns an oauth_verifier to the consumer, and the consumer must include it when exchanging the request token for an access token.

The gem supports the verifier across its request helpers and request proxies, and the README tells you to pass oauth_verifier to get_access_token in three legged flows. The important detail is that it is handled in the request layer rather than in one call site, so the parameter works whether you are calling the library's helpers directly or going through a proxy object.

The third difference is the one that is easy to get wrong. In 1.0a the service provider must return oauth_callback_confirmed=true with the request token response, which exists to mitigate session fixation. This gem parses token responses but does not include oauth_callback_confirmed in the signature base string, on the grounds that it is a response parameter rather than a signed request parameter. That is the correct reading of the specification, since a value that is only in the response cannot be part of a request signature, and the README explains the reasoning rather than leaving it as a quirk.

Together, these three behaviours are what separate a careful 1.0a implementation from a 1.0 implementation with a patch on top. A library that got them wrong would either fail against strict providers or sign parameters it should not.

Signed dependencies make a HighSecurity install possible

One line in the synopsis covers something most gem READMEs do not mention: all dependencies of this gem are signed, so it can be installed with a HighSecurity profile.

RubyGems has a mechanism for refusing to install gems that are not signed, and the practical value here is supply chain hygiene. An application that installs dependencies under a strict profile can adopt this library without relaxing that policy, which removes the usual objection to adding an older, widely depended-on gem to a locked down build.

The repository layout shows a project with that concern taken seriously beyond the gemspec. There is a certs/ directory and a checksums/ directory, a .gemrc file, an overcommit configuration, a pre-commit configuration, a RuboCop setup with a gradual lock file, a RuboCop configuration for RSpec, a Yard documentation lint configuration, and an Appraisal setup with multiple gemfiles for testing against dependency versions. The .github/ directory sits alongside a .gitlab-ci.yml, and there are structured merge and Kitchen Drift configuration directories, which suggests the project runs continuous integration on more than one forge.

For a reader evaluating the project, the takeaway is that the surrounding tooling is modern and the release process is automated, which matters more for a security-adjacent dependency than the feature list does.

Compatibility is checked across MRI, JRuby and Truffle Ruby

The README carries a compatibility matrix that spans three Ruby implementations, and the presence of dedicated CI entries for each is the useful part rather than the badges themselves.

For JRuby the matrix lists compatibility from 9.2 through 9.3, 9.4, 10.0, the current release and HEAD. For Truffle Ruby it lists 22.3, 23.0, 23.1, 24.2, 25.0, 33.0, the current release and HEAD. For MRI it lists the Ruby 3 series from 3.0 to 3.3, the current release and HEAD, and a separate row for MRI Ruby 4.

Running the suite against a current release and against HEAD of each implementation is a stronger statement than a version list, because it says the library is tested against the future of the runtime as well as its present. The CI list also includes separate jobs for runtime dependencies at HEAD, for style checks, for test coverage across several services, and a compatibility check against the Apache SkyWalking Eyes licence.

That last entry is unusual enough to note. A licence compatibility check in continuous integration is the sort of guardrail a project takes when it is used as a dependency inside other people's commercial products, where an incompatible licence in the tree would be a real problem.

For a team deciding whether to adopt, the practical reading is that this gem is not tied to one Ruby implementation and is checked against the leading edge of three, which reduces the risk of a runtime upgrade breaking an OAuth integration.

Examples show the consumer side against real services

The repository carries an examples/ directory with a handful of programs that show how the library is driven in practice: a Twitter client, a Tumblr command line tool, a YQL example and a scheme data importer. These are the shortest path to understanding the API, because a protocol library's README tells you what the options mean while an example shows the order of operations.

The examples also illustrate the range of provider types the library was written against. Twitter and Tumblr are both services that used OAuth 1.0a with callback URLs and verifier exchange, and the command line shape of the Tumblr example matches the README's guidance for non-HTTP clients, where the user is asked to paste back a verifier shown to them.

There is a docs/ directory, a CHANGELOG.md, a SECURITY.md, a CONTRIBUTING.md and a TODO file, plus a Rakefile and a Rake-driven test setup. The gem's own name is oauth, its namespace is ruby-oauth, and the gemspec at the root is oauth.gemspec.

The alternative to all of this is writing the signature base string and the HMAC-SHA1 exchange yourself, which is a few dozen lines of Ruby and a permanent liability, because the details are exactly the kind that providers disagree about. The gem's case is that it has absorbed those disagreements, including the callback and verifier nuances above, and that it keeps up with specification errata. The cost is that you take a dependency on a protocol that is dated and rarely chosen for new work.

Licence classification and release cadence need a direct look

Two practical notes sit outside the feature discussion.

The first is licensing. The repository listing classifies the licence as a custom one that GitHub cannot categorise, while the README badge states MIT and the repository root contains both a LICENSE.md and a separate MIT.md file, alongside a .licenserc.yaml configuration. That combination is common in projects that ship a general licence file plus a copy of the MIT text, but the discrepancy in how the licence is classified is worth resolving by reading the files rather than assuming. Any team planning to depend on this gem inside a product with its own licensing rules should start with LICENSE.md.

The second is release cadence and maintenance. The repository is not archived, the last push was on 2026-10-13, and the recent releases are v1.1.8 from 2026-07-15, v1.1.7 from 2026-06-15 and v1.1.6 from 2026-06-07. A version 1.1.x line with dated patch releases in recent months is a healthy signal for a library whose users depend on exact signature behaviour against third party providers.

The README also carries a section about how the project will approach the September 2025 hostile takeover of RubyGems, with a link to a blog post by the maintainer explaining the thinking. For anyone whose dependency policy includes questions about gem distribution governance, that post is the place where the maintainer's position is written down rather than implied.

Editorial conclusion

Adopt the oauth gem if you must speak OAuth 1.0 or 1.0a to a provider that never moved to OAuth 2, or if you need to run an OAuth 1.0 server in a Ruby application, since both roles ship in one gem. Do not adopt it for a new integration on the assumption that OAuth 1.0a is the right protocol, and note that the sibling oauth2 gem is the one to reach for otherwise. Verify first by checking the LICENSE.md and MIT.md files in the repository root directly, because the licence classification attached to the project is a custom one that GitHub cannot categorise, and then confirm that your provider's callback expectations match the default out of band behaviour.

Frequently asked questions

Official sources

1. Issues
2. Project website
3. README
4. Releases
5. ruby-oauth/oauth on GitHub