I’ll try to summarize some of the reasons I built rodauth-oauth, which were also the reasons I didn’t go with just picking doorkeeper.
doorkeeper is rails-only; if your application is a rails monolith, then integrating doorkeeper will be easy. However, if you have separate services, where the OAuth provider is just another one, going with a Rails-app may be perceived as “overkill”.
rodauth-oauth can be deployed as a roda plugin, a rack middleware, a rails plugin (via rodauth-rails), an “authorization server” microservice, which makes it a very flexible tool as your product scales.
doorkeeper dev group aggregates other gems for handling JWT, OpenID, grant assertions, however not all of them seem to be actively maintained (doorkeper-openid-connect is looking for new maintainers); they’re incompatible with each other (there’s doorkeeper-jwt, but then doorkeeper-opennid_connect has its own JWT infrastructure); and when they’re incompatible, they’re lagging in support with the dependency upstream. This distribution of implementations via separate gems is something that the doorkeeper maintainers actively promote.
rodauth-oauth ships and tests all other features built on top of it, guaranteeing that their integration works across versions. Maintaining this setup is a 1000x cheaper than doorkeeper distributed gem graph.
rodauth-oauth ships more features out-of-the-box: as stated above, doorkeeper requires you to install other 3rd-party-gems to have OpenID or plain JWT access tokens. However, other features, such as using JWT-secured authorization requests, supporting encrypted JWT tokens, resource server mode or JWT and SAML assertions, aren’t (at the time of this answer) implemented by doorkeeper.
Although doorkeeper supports some security features such as the PKCE flow or hashing token columns, these have to be explicitly turned on.
Turning PKCE on requires enabling the oauth_pkce feature. Has for token and secret columns, rodauth-oauth hashes them by default.
Because it’s based on rodauth architecture, adding missing functionality or extending behaviour to rodauth-oauth is very easy, because the internals of each feature are approachable and contained in a single file. In fact, rodauth-oauth features usually implement one RFC.
Extending doorkeeper involves deeper understanding and extension of rails and its layers (some initialization glue and configuration, then models, then controllers, then helpers, then routes, then view…), making implementing these features a bit “all over the place”.
It will really come down to your requirements. jwt has a bigger community (at the time of this answer, 5x more contributors); json-jwt has been getting more updates and releases; json-jwt supports more signing algorithms;
jwt has no dependencies (json-jwt loads activesupport); json-jwt monkey-patches core classes; jwt requires separate jwe gem for encryption, json-jwt” already includes JWE; etc etc etc…
YMMV here. I prefer jwt.
As always, it’s best to read the manual in order to know what to do. Nevertheless, here’s the gist of it:
plugin :rodauth do
enable :login, :logout, :create_account, :oidc, :oauth_client_credentials_grant, :oauth_token_introspection, :oidc_dynamic_client_registration
# already by default:
oauth_grants_token_hash_column :token
oauth_grants_refresh_token_hash_column :refresh_token
oauth_response_mode "form_post"
end
If you’re using JWT access tokens (if you’re using the :oidc feature, you are), do consider your signing algorithms and pkey lengths. However, this discussion goes beyond this library.
The TL;DR: You can do that by building the “single button form” yourself.