rack-oauth2 and the case for implementing OAuth 2.0 in Ruby yourself

The specification is the API, and the library follows it closely

rack-oauth2 is an OAuth 2.0 server and client library, and the design reference is the specification itself. The project names two documents directly: The OAuth 2.0 Authorization Framework, RFC 6749, and The OAuth 2.0 Authorization Framework, Bearer Token Usage, RFC 6750.

That is the whole design philosophy in one fact. This is not a wrapper around a hosted identity provider, and it is not an opinionated framework with its own model of users, clients and tokens. It is an implementation of the specification, packaged as a Rack middleware and a client library, so that a Ruby application can be an OAuth 2.0 server or an OAuth 2.0 client without adopting somebody else's data model.

The token types are named in the description as well, with the repository description saying both Bearer and MAC token type are supported, and the project body saying both Bearer token type are supported, which reads as an editing slip but confirms Bearer as the primary path.

The MAC token type is the older of the two mechanisms, in which the client signs each request with a shared key rather than presenting a bearer token on every call. Supporting it alongside Bearer is a sign of the library's age, because MAC access tokens were never broadly deployed and the specification text around them has been largely abandoned.

The primary language is Ruby, the licence is MIT, and the default branch is main.

The five grants the client library covers

The sample client material in the project is listed by the request types it demonstrates, and that list is the clearest inventory of what the client side supports.

There is an authorization request, covering request_type of code and token. That is the authorization code grant and the implicit grant, the two flows a browser based client uses, and the difference between them is whether the token comes back in a redirect fragment or a redirect query parameter.

There is a token request, covering grant_type of client_credentials, password, authorization_code and refresh_token. The client credentials grant is for a client acting on its own behalf with no user involved. The password grant is the resource owner password credentials flow, which the specification describes as suitable only when there is a high degree of trust between the client and the resource owner. The authorization code grant is the flow almost everything uses, and the refresh token grant is what lets a client obtain a new access token without asking the user again.

There is a resource request, described as covering both a request for a resource owner resource and a request for a client resource, which is the difference between the access token acting on behalf of a user and acting on behalf of the client itself.

So the client library covers the full matrix of the classic specification, and the samples are split by flow rather than by method, which makes them readable in the order a developer would meet the flows.

Installing it, and a sample server to look at

Installation is a single gem command:

gem install rack-oauth2

The project also points at a sample server application, which is labelled as a Rails 3 sample, with the source on GitHub at a separate repository, rack-oauth2-sample. The example is under Bearer.

That label is a signal worth noting. A Rails 3 sample is a sample from the era when this library was written, which means it demonstrates the middleware mounting and the flow wiring rather than a current application structure. For a library whose whole value is showing you how the flows work, that is still useful, because the flow is the thing you want to copy.

The resources listed are the ordinary ones for a gem of this age: view source on GitHub, documentation on the GitHub wiki, and issue reporting on GitHub.

The project uses a documentation listing file, which is the RDoc convention for listing files to include in the generated documentation, a .rspec file for the RSpec defaults, a Rakefile, a Gemfile, a VERSION file and a rack-oauth2.gemspec. The lib/ directory holds the implementation and spec/ the tests, and there is a CHANGELOG.md.

The contribution rules reveal what the maintainer wanted

The note on patches and pull requests is short and it reads like a message from a specific period of Ruby development, and it is worth quoting in substance because it tells you what the project values.

Fork the project, make your feature addition or bug fix, and add tests for it, with the emphasis that this is important so the author does not break it in a future version unintentionally. Then commit, and do not mess with the Rakefile, the version or the history, with the parenthetical that if you want to have your own version that is fine, but bump the version in a commit by itself that can be ignored when the change is pulled. Finally send a pull request, with bonus points for topic branches.

The tests rule is the one that matters for anyone considering a contribution now. A library with a strict test requirement and a two-year gap between tagged releases is a library where the test suite is the specification, and where a pull request without tests will be harder to land than one with them.

The rule about not touching the version in a mixed commit is also about how the maintainer managed releases, and it connects to the release history. The tags are v2.2.0 from 2022-10-11, v2.2.1 from 2023-12-27 and v2.3.0 from 2025-11-05, so releases have become infrequent, and the last push to the repository was on 2026-09-15.

The copyright line reads Copyright (c) 2010 nov matake, with the licence details in the LICENSE file.

What has changed in the OAuth world since 2010

This is the part an evaluator has to think about, and it is the part a changelog would tell you about but the project description does not.

The two documents the project cites are from the period when OAuth 2.0 was settling. RFC 6749 dates from 2012 and RFC 6750 from 2012 as well, and the Bearer usage document is even listed against a draft of the IETF working group, which dates the reference to a moment before the specification was finalised.

A great deal has been added to the OAuth 2.0 family since then, and the library predates all of it. PKCE, the code challenge extension that binds an authorization code to the client that requested it, does not exist here. The token revocation and introspection endpoints do not exist here. The security best current practice document, which tightened a great many requirements around redirect URIs, implicit grants and client authentication, postdates the code by years. The device authorization grant and the pushed authorization request do not exist here either, and neither does JWT-secured client authentication, which is now the most common way a confidential client authenticates.

That matters more for the server side than the client side. A client library that speaks a subset of the specification is usually fine, because it talks to a server that implements the rest. A server implementation that is missing PKCE is a genuine gap, because the clients that connect to it include mobile applications that rely on the challenge to prevent an intercepted code from being replayed.

Where rack-oauth2 is the wrong choice

The first case is building a new OAuth 2.0 provider for public clients. Without PKCE, without the current security best practice, and with the implicit grant among the supported flows, a server built on this library would not satisfy what a modern client expects, and a security review would ask about it first.

The second is a project that needs an identity provider rather than a protocol implementation. OAuth 2.0 is not authentication, and the library does not pretend otherwise. If what you need is login, social sign-in, multi-factor, session management and user management, an identity provider library or a hosted service is the right shape, and this library will only ever be the lower layer of that stack.

The third is a team that wants the standard modern Ruby path. The ecosystem has moved on from a Rack middleware and a wiki to a world of gems with typed interfaces, generated documentation and security advisories, and adopting a library whose last tagged release is from 2025 means owning it.

The fourth is anyone who needs a maintained dependency. The project is not archived and there was a push in September 2026, so it is not dead, but a low-traffic library with a 2010 copyright line and infrequent releases is a dependency to think twice about. Where the library is genuinely strong is as a reference implementation: a small, readable, spec-shaped body of code that shows what the flows actually do.

Editorial conclusion

rack-oauth2 suits a Ruby team that wants to understand the OAuth 2.0 flows by reading working code, since the library maps the specification closely enough that you can follow the spec text against it. It does not suit a new production OAuth provider, because the code dates from 2010 and predates most of the security guidance published since, and it does not suit anyone who needs PKCE or a modern token format without adding it themselves. Before you build on it, read the changelog and the version history, because the project has only had two tagged releases since 2022, and note that the last push was on 2026-09-15 with the newest release v2.3.0 dated 2025-11-05.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. nov/rack-oauth2 on GitHub
4. README
5. Releases